Re: [tor-bugs] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by robgjansen):

 https://phantomtrain.robgjansen.com is now encrypted via a let's encrypt
 cert.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21951 [User Experience]: Tor Launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Tor Launcher improvements and automation
-+---
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mcs):

 * cc: brade (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21948 [Applications/Tor Browser]: Going back to about:tor page gives a "The address isn’t valid"-error

[Tor Bug Tracker & Wiki]

#21948: Going back to about:tor page gives a "The address isn’t valid"-error
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 e10s only.
 But mcs thinks it's OK ticket:18913#comment:5 :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18530 [Applications/Tor Browser]: Consider dropping support for Mac OS 10.6, 10.7, and 10.8

[Tor Bug Tracker & Wiki]

#18530: Consider dropping support for Mac OS 10.6, 10.7, and 10.8
-+-
 Reporter:  mcs  |  Owner:  boklm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704,  |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 https://gitweb.torproject.org/builders/tor-browser-
 bundle.git/commit/?id=64f2c7dd739a2f842a5aea5ed824683efc653aa4
 Not only March is gone, but 45.9esr too ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21953 [Core Tor/Tor]: Dealing with Tor hardening on Windows properly

[Tor Bug Tracker & Wiki]

#21953: Dealing with Tor hardening on Windows properly
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While gk is waiting (for something?) in #12426, Tor needs its security
 mitigations to be corrected according to
 https://blogs.microsoft.com/microsoftsecure/2009/08/06/setting-sdl-memory-
 related-requirements-before-your-application-starts/ before the release.
 So, adding
 {{{
   HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);
 }}}
 after
 https://gitweb.torproject.org/tor.git/tree/src/or/main.c?h=release-0.3.0#n3570
 and changing
 {{{
 if (setdeppolicy) setdeppolicy(1); /* PROCESS_DEP_ENABLE */
 }}}
 with
 {{{
 if (setdeppolicy) setdeppolicy(3); /* PROCESS_DEP_ENABLE |
 PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION */
 }}}
 will do the trick.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18002 [Archived/operations]: move away from OFTC to new functional, Tor-friendly IRC network

[Tor Bug Tracker & Wiki]

#18002: move away from OFTC to new functional, Tor-friendly IRC network
-+---
 Reporter:  adrelanos|  Owner:
 Type:  task | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Archived/operations  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  None
-+---
Changes (by ahf):

 * cc: ahf (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18002 [Archived/operations]: move away from OFTC to new functional, Tor-friendly IRC network

[Tor Bug Tracker & Wiki]

#18002: move away from OFTC to new functional, Tor-friendly IRC network
-+---
 Reporter:  adrelanos|  Owner:
 Type:  task | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Archived/operations  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  None
-+---
Changes (by arma):

 * cc: arma (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18002 [Archived/operations]: move away from OFTC to new functional, Tor-friendly IRC network

[Tor Bug Tracker & Wiki]

#18002: move away from OFTC to new functional, Tor-friendly IRC network
-+---
 Reporter:  adrelanos|  Owner:
 Type:  task | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Archived/operations  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  None
-+---

Comment (by arma):

 Two thoughts:

 A) OFTC has its issues but on the whole it's been quite pleasant compared
 to other irc networks. So I would worry about the case where we move
 somewhere, the new place turns out to not be able to handle all of our
 issues, and then we don't have anyplace to move back to because we burned
 our bridges. I think any move we might make should have a good answer for
 this concern.

 B) Longer term, I think we need somebody to build the irc proxy + nymble
 idea. That is, we need an irc proxy that can accept connections from Tor
 users, allow them to authenticate using some variant of the anonymous
 credentials idea, and then pass their connections (or their traffic, or
 however it works) to the main irc network. Then if they get blacklisted
 from the main irc network, the proxy notices and revokes their
 credentials.

 I guess item 'B' is one instance of the more general "irc needs to gain
 better abuse handling mechanisms" goal. I'd love for somebody to work on
 it, but so far it hasn't been something that Tor has developers for.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21951 [User Experience]: Tor Launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Tor Launcher improvements and automation
-+---
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by gk):

 * cc: gk (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by linda):

 Hey asn and dgoulet: I'd love to hear your thoughts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Description changed by linda:

Old description:

> ilf is experimenting with automatically redirecting Tor users to .onion
> versions of websites that they visit (because they want more people to
> visit onion sites and they will do so if it is painless to them). But
> when users were redirected automatically to an onion site, they freaked
> out about it because they didn't know what happened, didn't know what
> onion sites were, and the "https" was dropped.
>
> asn and dgoulet also were trying to find a solution to make onion sites
> more accessible to use. Specifically, onion addresses are quite long and
> random-ish, making them hard to remember and hard to type. There were
> many solutions discussed casually to try and resolve this, but none stood
> out as a clear winner.
>
> I like the idea of redirecting users to .onion sites automatically when
> they type in the websites non-onion address. This way, users don't need
> to remember anything else, need to type in anything long, or really even
> know what onion sites are.
>
> My suggestion is to follow the https design pattern, and create a similar
> indicator for .onion sites.
>

>
> The proposed solution would be this: when a user types in a website
> (pad.riseup.net), they would automatically be redirected to the onion
> site. When this happens, there would be an onion icon next to the address
> bar (replacing the https lock icon if there is one, or just being there
> an https lock icon would be if redirection from an http website), similar
> to that of the https lock icon. The address in the address bar can turned
> a different color or indicated in some way that this is an alias for the
> onion site.
>
> From my observation, people don't mind automatically being redirected to
> https sites from http sites, but freak out when redirected from an
> http/https site to an onion site. I don't think that this is because
> people know what https is and find the idea comforting (although this can
> help). I speculate that they don't mind because they don't notice, and
> the reason why users freaked out at the redirect to onion sites is that
> they saw the website address visibly change in the address bar.
>
> If we want to show users the address of the onion site, we can
> additionally have a feature to reveal the onion site when the user clicks
> in the address bar. But I don't know how I feel about this, since it may
> just be confusing, and just shock the user later. Users don't know that
> pad.riseup.net resolves to some numerical IP address, and that isn't
> displayed to users. So there could be an argument made for just
> indicating that the address is an alisas and not ever showing the .onion
> address, either. This will confuse way less of the general population.

New description:

 ilf is experimenting with automatically redirecting Tor users to .onion
 versions of websites that they visit (because they want more people to
 visit onion sites and they will do so if it is painless to them). But when
 users were redirected automatically to an onion site, they freaked out
 about it because they didn't know what happened, didn't know what onion
 sites were, and the "https" was dropped.

 asn and dgoulet also were trying to find a solution to make onion sites
 more accessible to use. Specifically, onion addresses are quite long and
 random-ish, making them hard to remember and hard to type. There were many
 solutions discussed casually to try and resolve this, but none stood out
 as a clear winner.

 I like the idea of redirecting users to .onion sites automatically when
 they type in the websites non-onion address. This way, users don't need to
 remember anything else, need to type in anything long, or really even know
 what onion sites are.

 My suggestion is to follow the https design pattern, and create a similar
 indicator for .onion sites.

 [[Image(onion-address-idea.png,600px)]]

 The proposed solution would be this: when a user types in a website
 (pad.riseup.net), they would automatically be redirected to the onion
 site. When this happens, there would be an onion icon next to the address
 bar (replacing the https lock icon if there is one, or just being there an
 https lock icon would be if redirection from an http website), similar to
 that of the https lock icon. The address in the address bar can turned a
 different color or indicated in some way that this is an alias f

[tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 ilf is experimenting with automatically redirecting Tor users to .onion
 versions of websites that they visit (because they want more people to
 visit onion sites and they will do so if it is painless to them). But when
 users were redirected automatically to an onion site, they freaked out
 about it because they didn't know what happened, didn't know what onion
 sites were, and the "https" was dropped.

 asn and dgoulet also were trying to find a solution to make onion sites
 more accessible to use. Specifically, onion addresses are quite long and
 random-ish, making them hard to remember and hard to type. There were many
 solutions discussed casually to try and resolve this, but none stood out
 as a clear winner.

 I like the idea of redirecting users to .onion sites automatically when
 they type in the websites non-onion address. This way, users don't need to
 remember anything else, need to type in anything long, or really even know
 what onion sites are.

 My suggestion is to follow the https design pattern, and create a similar
 indicator for .onion sites.



 The proposed solution would be this: when a user types in a website
 (pad.riseup.net), they would automatically be redirected to the onion
 site. When this happens, there would be an onion icon next to the address
 bar (replacing the https lock icon if there is one, or just being there an
 https lock icon would be if redirection from an http website), similar to
 that of the https lock icon. The address in the address bar can turned a
 different color or indicated in some way that this is an alias for the
 onion site.

 From my observation, people don't mind automatically being redirected to
 https sites from http sites, but freak out when redirected from an
 http/https site to an onion site. I don't think that this is because
 people know what https is and find the idea comforting (although this can
 help). I speculate that they don't mind because they don't notice, and the
 reason why users freaked out at the redirect to onion sites is that they
 saw the website address visibly change in the address bar.

 If we want to show users the address of the onion site, we can
 additionally have a feature to reveal the onion site when the user clicks
 in the address bar. But I don't know how I feel about this, since it may
 just be confusing, and just shock the user later. Users don't know that
 pad.riseup.net resolves to some numerical IP address, and that isn't
 displayed to users. So there could be an argument made for just indicating
 that the address is an alisas and not ever showing the .onion address,
 either. This will confuse way less of the general population.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21951 [User Experience]: Tor Launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Tor Launcher improvements and automation
-+---
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 To make it easier for users to connect to Tor, we're going to make some
 changes to Tor Launcher. Specifically:

 1. design changes: we're going to make interface-only changes that will
 help the users.
 1. naive automation: we're going to automate the connection process, by
 some sort of behavior. We haven't decided on what that behavior is yet,
 but there are multiple ways to do this. One way would be to try a bunch of
 relays/bridges in a specific order, and stop when one is reachable.
 Another way would be to try all the relays/bridges at the same time, and
 return one that works to the user.
 1. smart automation: this is a "make it work" button that people can
 relatively safely click, and it will work for people in most environments
 with minimized risk. We haven't decided on what that behavior is yet
 either, but one way to do this is to meek-front the connection, work with
 bridgeDB and/or some way to identify where the user is from, and give them
 a relay/bridge that works the first time.

 This ticket is more here so that we remember to do this. I (Linda) don't
 know when things are happening, or when specific proposals come in to fund
 each phase of this project.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21950 [User Experience/Website]: Organize, brainstorm and prioritize content to meet portal requirements

[Tor Bug Tracker & Wiki]

#21950: Organize, brainstorm and prioritize content to meet portal requirements
-+
 Reporter:  linda|  Owner:  linda
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #21222
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 Figure out what to keep, what to not keep, and what to add to
 torproject.org.

 = Definitions =

 * content means anything that goes on a website, including text that you
 want to display to users, graphical elements such as banners and pictures,
 to additional resources (manuals, videos, etc.).

 = Methodology =

 Linda will go talk to each of the stakeholders for each portal of the
 website, identify their needs, and figure out what content will best serve
 those needs.

 = Results =

 '' Linda will post the results of that here once she's done that.''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21222 [User Experience]: Redesigning torproject.org

[Tor Bug Tracker & Wiki]

#21222: Redesigning torproject.org
-+--
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  website  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Description changed by linda:

Old description:

> This is the master ticket that keeps track of all tasks for redesigning
> torproject.org.  (key: ~~done~~, '''in progress''', todo.)
>
> = Project phases =
>
> Research:
> * ~~sitemap current site~~
> * '''organize existing content'''
> * '''write user personas and stories'''
> * industry research
> * brainstorm new content requirements
>
> Design:
> * sitemap new site (navigational design)
> * organize content into new site structure (information architecting)
> * determine what we want users to do on each page  (interaction design)
> * prioritize important content on each page (interface design)
> * draw sketches of the various portals' pages (wireframing)
>
> Build:
> * branding, color, fonts (styling)
> * writing content
> * creating graphical content
> * choosing a framework
> * choosing which pages will be mirrored and which ones are not
> * start building the website (prototyping)
>
> Polish:
> * translate into different languages
> * localize layouts (right to left, for instance)
> * search engine optimization
> * debugging
> * testing
> * reviewing

New description:

 This is the master ticket that keeps track of all tasks for redesigning
 torproject.org.

 You can keep track of the project at its project page
 [https://trac.torproject.org/projects/tor/wiki/doc/UX/TorProjectWebsite
 here].

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21949 [User Experience/Website]: Identifying the requirements of the four torproject.org portals (was: Identifying the purpose and audience of the four torproject.org portals)

[Tor Bug Tracker & Wiki]

#21949: Identifying the requirements of the four torproject.org portals
-+--
 Reporter:  linda|  Owner:  linda
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by linda):

 * status:  new => assigned
 * owner:  hiro => linda


Old description:

> = Objective =
>
> Write user stories for all four portals.
>
> = Methodology =
>
> Talk with stakeholders of each portal, write user stories.
>
> = Results =
>
> '' Linda will post user stories after they are written.''

New description:

 = Objective =

 Write user stories for all four portals to define the content requirements
 for each page.

 = Definition =

 * A user story describes the type of user, what they want and why. A user
 story helps to create a simplified description of a requirement. It is a
 description of a software feature from an end-user perspective.

 = Methodology =

 Talk with stakeholders of each portal, write user stories.

 = Results =

 '' Linda will post user stories after they are written.''

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21949 [User Experience/Website]: Identifying the purpose and audience of the four torproject.org portals

[Tor Bug Tracker & Wiki]

#21949: Identifying the purpose and audience of the four torproject.org portals
-+
 Reporter:  linda|  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #21222
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 Write user stories for all four portals.

 = Methodology =

 Talk with stakeholders of each portal, write user stories.

 = Results =

 '' Linda will post user stories after they are written.''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21948 [Applications/Tor Browser]: Going back to about:tor page gives a "The address isn’t valid"-error

[Tor Bug Tracker & Wiki]

#21948: Going back to about:tor page gives a "The address isn’t valid"-error
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 After start-up the `about:tor` page is shown. If one enters a URL (e.g.
 www.torproject.org) and tries to go back to `about:tor` afterwards a "The
 address isn’t valid"-error is shown instead. This works 6.5.2 as expected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21947 [User Experience/Website]: Brainstorming, prioritizing, and organizing the content for the website and its portals

[Tor Bug Tracker & Wiki]

#21947: Brainstorming, prioritizing, and organizing the content for the website 
and
its portals
-+
 Reporter:  linda|  Owner:  hiro
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #21222
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 Figure out what to keep, what to not keep, and what to add to
 torproject.org.

 = Definitions =

 * content means anything that goes on a website, including text that you
 want to display to users, graphical elements such as banners and pictures,
 to additional resources (manuals, videos, etc.).

 = Methodology =

 Linda will go talk to each of the stakeholders for each portal of the
 website, identify their needs, and figure out what content will best serve
 those needs.

 = Results =

 '' Linda will post the results of that here once she's done that.''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21947 [User Experience/Website]: Brainstorming, prioritizing, and organizing the content for the website and its portals

[Tor Bug Tracker & Wiki]

#21947: Brainstorming, prioritizing, and organizing the content for the website 
and
its portals
-+--
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by linda):

 * status:  new => assigned
 * owner:  hiro => linda


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21946 [User Experience/Website]: Architecting a torproject.org with portals with the subsite design pattern

[Tor Bug Tracker & Wiki]

#21946: Architecting a torproject.org with portals with the subsite design 
pattern
-+--
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by linda):

 * type:  defect => task


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21946 [User Experience/Website]: Architecting a torproject.org with portals with the subsite design pattern

[Tor Bug Tracker & Wiki]

#21946: Architecting a torproject.org with portals with the subsite design 
pattern
-+--
 Reporter:  linda|  Owner:  linda
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by linda):

 * status:  new => assigned
 * owner:  hiro => linda


Old description:

> = Objective =
>
> To define the structure of the new website: specifically, to decide how
> many pages/subpages there will be, how the main site will interact with
> its portals/subsites, and deciding where to host content (prioritizing
> important things first, leaving lesser important things in harder-to-
> reach pages).
>
> = Definitions =
>
> * the subsite design pattern looks like this:
>

> This structure is good for organizations with lots of separate
> topics/responsibilities. This is one of many design patterns, which you
> can see [http://adellefrank.com/blog/review-information-architecture-
> patterns here].
>
> = Methodology =
>
> The website will be architected to have a main page (torproject.org) and
> three portals/subsites: 1) dev.torproject.org, 2) support.torproject.org,
> and 3) outreach.torproject.org. The purpose of the main site would be to
> redirect people to the appropriate portals, and the portals will host
> portal-specific content and will not cross-link.
>
> Once we have decided what content will need to be hosted on each page, we
> will architect the website to host the appropriate contents in this
> design pattern.
>
> = Results =
> ''Linda will update this after she's done architecting.''

New description:

 = Objective =

 To define the structure of the new website: specifically, to decide how
 many pages/subpages there will be, how the main site will interact with
 its portals/subsites, and deciding where to host content (prioritizing
 important things first, leaving lesser important things in harder-to-reach
 pages).

 = Definitions =

 * the subsite design pattern looks like this:

 [[Image(subsites-design-pattern.png, 400px)]]

 This structure is good for organizations with lots of separate
 topics/responsibilities. This is one of many design patterns, which you
 can see [http://adellefrank.com/blog/review-information-architecture-
 patterns here].

 = Methodology =

 The website will be architected to have a main page (torproject.org) and
 three portals/subsites: 1) dev.torproject.org, 2) support.torproject.org,
 and 3) outreach.torproject.org. The purpose of the main site would be to
 redirect people to the appropriate portals, and the portals will host
 portal-specific content and will not cross-link.

 Once we have decided what content will need to be hosted on each page, we
 will architect the website to host the appropriate contents in this design
 pattern.

 = Results =
 ''Linda will update this after she's done architecting.''

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21946 [User Experience/Website]: Architecting a torproject.org with portals with the subsite design pattern

[Tor Bug Tracker & Wiki]

#21946: Architecting a torproject.org with portals with the subsite design 
pattern
-+
 Reporter:  linda|  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #21222
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 To define the structure of the new website: specifically, to decide how
 many pages/subpages there will be, how the main site will interact with
 its portals/subsites, and deciding where to host content (prioritizing
 important things first, leaving lesser important things in harder-to-reach
 pages).

 = Definitions =

 * the subsite design pattern looks like this:


 This structure is good for organizations with lots of separate
 topics/responsibilities. This is one of many design patterns, which you
 can see [http://adellefrank.com/blog/review-information-architecture-
 patterns here].

 = Methodology =

 The website will be architected to have a main page (torproject.org) and
 three portals/subsites: 1) dev.torproject.org, 2) support.torproject.org,
 and 3) outreach.torproject.org. The purpose of the main site would be to
 redirect people to the appropriate portals, and the portals will host
 portal-specific content and will not cross-link.

 Once we have decided what content will need to be hosted on each page, we
 will architect the website to host the appropriate contents in this design
 pattern.

 = Results =
 ''Linda will update this after she's done architecting.''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21942 [User Experience/Website]: Sitemapping the current site layout

[Tor Bug Tracker & Wiki]

#21942: Sitemapping the current site layout
-+
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by linda:

Old description:

> = Objective =
> * generate a digraph representation of the current sitemap of
> www.torproject.org.
>
> We are doing this to visualize how the website is currently laid out,
> analyze the pros and cons of the layout, and to see user paths throughout
> the website.
>
> = Definitions =
> * a ''sitemap'' is a list of pages of a web site accessible to crawlers
> or users, typically organized in hierarchical fashion. It can be a
> document in any form used as a planning tool for Web design.
> * a ''directed graph (or digraph)'' is a graph with a set of vertices
> connected by edges, where the edges have a direction associated with
> them.
>
> = Methodology =
>
> To generate the sitemap digraph, one person (linda) manually visited the
> website and manually wrote the code for generating the visualization. The
> manual crawl began by visiting all the pages reachable with one click
> from the front page, then visiting all the pages reachable with two
> clicks from the front page, and so on. This continued until there were no
> additional pages to visit.
>
> External pages (any site that wasn't www.torproject.org/stuff, so
> donations.torproject.org would be considered an external link) and
> duplicate paths (if one page was reachable from the header, and also from
> the footer, for instance) were noted along the way.
>
> There was existing work done to sitemap the website (#10591), and this
> was taken into consideration. The previous work was used to check that
> there were not any sites that were not accounted for, but since the
> digraphs were not generated in the same way (the old method did add nodes
> for external links, whereas this digraph does, for instance), they do not
> look identical.
>
> = Results and observations=
> * a digraph sitemap of www.torproject.org (key: black = webpage, grey =
> external webpage, pink = duplicate link to a webpage).
>
> [[Image(tpo-digraph-before.png, 600px)]]
>
> The three main observations about the structure were that it was
> abnormally structured, too flat, and messily interlinked. More details
> about this below:
>
> 1. The current structure of the website does not follow any of the
> standard design patterns:
>
> [[Image(an-example-hierarchy.png, 400px)]]
> An example of a hierarchy pattern, additional ones are
> [http://adellefrank.com/blog/review-information-architecture-patternsh
> here].
>
> Currently, the website structure is asymmetrical, and of various depths.
> This can be irritating to users where some pages just "end" whereas other
> pages require 2-3 clicks to find the information that they need.
>
> 2. the website structure is very flat.
>
> [[Image(flat-vs-deep.png, 600px)]]
> This conveys the same amount of pages, but in a flat vs deep hierarchy.
>
> Content is more discoverable when it's not buried under multiple
> intervening layers. Users can become overwhelmed with cluttered menus.
> Hierarchies can be helpful if categories are specific and do not overlap,
> which I do think is the case for many of the content in torproject.org.
>
> 3. there is a lot of inter-linking and duplicate links to various pages.
>
> You can get to to a pages' subpage from another page's subpage. There are
> links with different text ("learn more" and "about tor" both lead to the
> same place) that lead to the same place. On one page, there are multiple
> ways to get to the same page (you can get to the donate page from the
> header, subheader, and footer, and occasionally a side bar tip). All of
> these things are confusing, and we should find out where the best
> placement for something is, and keep it there.

New description:

 = Objective =
 * generate a digraph representation of the current sitemap of
 www.torproject.org.

 We are doing this to visualize how the website is currently laid out,
 analyze the pros and cons of the layout, and to see user paths throughout
 the website.

 = Definitions =
 * a ''sitemap'' is a list of pages of a web site accessible to crawlers or
 users, typically organized in hierarchical fashion. It can be a document
 in any form used as a planning tool for Web design.
 * a ''directed graph (or digraph)'' is a graph with a set of vertices
 connected by edges, where the edges have a direction associated with them.

 = Methodology =

 To generate the sitemap digraph, one pe

Re: [tor-bugs] #21942 [User Experience/Website]: Sitemapping the current site layout

[Tor Bug Tracker & Wiki]

#21942: Sitemapping the current site layout
-+
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #21222   | Points:
 Reviewer:   |Sponsor:
-+

Old description:

> = Objective =
> * generate a digraph representation of the current sitemap of
> www.torproject.org.
>
> We are doing this to visualize how the website is currently laid out,
> analyze the pros and cons of the layout, and to see user paths throughout
> the website.
>
> = Definitions =
> * a ''sitemap'' is a list of pages of a web site accessible to crawlers
> or users, typically organized in hierarchical fashion. It can be a
> document in any form used as a planning tool for Web design.
> * a ''directed graph (or digraph)'' is a graph with a set of vertices
> connected by edges, where the edges have a direction associated with
> them.
>
> = Methodology =
>
> To generate the sitemap digraph, one person (linda) manually visited the
> website and manually wrote the code for generating the visualization. The
> manual crawl began by visiting all the pages reachable with one click
> from the front page, then visiting all the pages reachable with two
> clicks from the front page, and so on. This continued until there were no
> additional pages to visit.
>
> External pages (any site that wasn't www.torproject.org/stuff, so
> donations.torproject.org would be considered an external link) and
> duplicate paths (if one page was reachable from the header, and also from
> the footer, for instance) were noted along the way.
>
> There was existing work done to sitemap the website (#10591), and this
> was taken into consideration. The previous work was used to check that
> there were not any sites that were not accounted for, but since the
> digraphs were not generated in the same way (the old method did add nodes
> for external links, whereas this digraph does, for instance), they do not
> look identical.
>
> = Results =
> * a digraph sitemap of www.torproject.org
>
> [[Image(tpo-digraph-before.png, 600px)]]
>
> * observations about site structure along the way:
>  - 38 links on the front page, which leads to 30+ pages--that's a bit too
> much.
>  - 3-4 ways to get to one page (header, footer, inline, from a subpage),
> sometimes with different text ('volunteer' and 'get involved' lead to the
> same page).
>  - there are site headers, subheaders, AND side headers, which compete
> for attention.
>  - the header, subheader, and footer stay the same throughout the site,
> and are visible everywhere.
>  - the side headers sometimes appear, and also are different depending on
> which page you are on
> (https://www.torproject.org/docs/documentation.html.en vs
> https://www.torproject.org/about/overview.html.en).
>
> * ideas about structure for the new www.torproject.org
>  - keep it simple: nothing more than sub-sub-sub pages (3 clicks away)
>  - less is more: reduce the different amount of content on each page, and
> expand on the select few topics that remain on each page.
>  - consistency: use the same phrasing to refer to the same pages and
> topics throughout.
>  - minimize: use only a header and footer.
>  - put things in the footer that are not as important, and link to a leaf
> page. The current footer links to pages linked to by the header, which is
> kind of confusing.
>  - organize by target audience: a lot of the existing content can be
> organized into the developer, support, and outreach portals. (for
> instance, the manuals, project pages, wiki, can all be in the developer
> portal.)

New description:

 = Objective =
 * generate a digraph representation of the current sitemap of
 www.torproject.org.

 We are doing this to visualize how the website is currently laid out,
 analyze the pros and cons of the layout, and to see user paths throughout
 the website.

 = Definitions =
 * a ''sitemap'' is a list of pages of a web site accessible to crawlers or
 users, typically organized in hierarchical fashion. It can be a document
 in any form used as a planning tool for Web design.
 * a ''directed graph (or digraph)'' is a graph with a set of vertices
 connected by edges, where the edges have a direction associated with them.

 = Methodology =

 To generate the sitemap digraph, one person (linda) manually visited the
 website and manually wrote the code for generating the visualization. The
 manual crawl began by visiting all the pages reachable with one click from
 the front page, then visiting all the pages reachable with two clicks from
 the front page, and so on. This continue

Re: [tor-bugs] #21222 [User Experience]: Redesigning torproject.org

[Tor Bug Tracker & Wiki]

#21222: Redesigning torproject.org
-+--
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  website  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> This is the master ticket that keeps track of all tasks for redesigning
> torproject.org.  (key: ~~done~~, '''in progress''', todo.)
>
> = Project phases =
>
> Research:
> * ~~sitemap current site~~
> * '''organize existing content'''
> * '''industry research'''
> * '''write user personas and stories'''
> * '''brainstorm new content requirements'''
>
> Design:
> * sitemap new site (navigational design)
> * organize content into new site structure (information architecting)
> * determine what we want users to do on each page  (interaction design)
> * prioritize important content on each page (interface design)
> * draw sketches of the various portals' pages (wireframing)
>
> Build:
> * branding, color, fonts (styling)
> * writing content
> * creating graphical content
> * choosing a framework
> * choosing which pages will be mirrored and which ones are not
> * start building the website (prototyping)
>
> Polish:
> * translate into different languages
> * localize layouts (right to left, for instance)
> * search engine optimization
> * debugging
> * testing
> * reviewing

New description:

 This is the master ticket that keeps track of all tasks for redesigning
 torproject.org.  (key: ~~done~~, '''in progress''', todo.)

 = Project phases =

 Research:
 * ~~sitemap current site~~
 * '''organize existing content'''
 * '''write user personas and stories'''
 * industry research
 * brainstorm new content requirements

 Design:
 * sitemap new site (navigational design)
 * organize content into new site structure (information architecting)
 * determine what we want users to do on each page  (interaction design)
 * prioritize important content on each page (interface design)
 * draw sketches of the various portals' pages (wireframing)

 Build:
 * branding, color, fonts (styling)
 * writing content
 * creating graphical content
 * choosing a framework
 * choosing which pages will be mirrored and which ones are not
 * start building the website (prototyping)

 Polish:
 * translate into different languages
 * localize layouts (right to left, for instance)
 * search engine optimization
 * debugging
 * testing
 * reviewing

--

Comment (by linda):

 Currently working on organizing the information on the website and
 thinking of how to best present it for various people that may visit the
 website.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20905 [Applications/Tor Browser]: Tor Browser window does not get resized to the same sizes as before 6.5a4 anymore

[Tor Bug Tracker & Wiki]

#20905: Tor Browser window does not get resized to the same sizes as before 
6.5a4
anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-6.5-regression, tbb-usability,   |  Actual Points:
  tbb-fingerprinting-resolution, |
  TorBrowserTeam201704, ff52-esr-will-have   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 This is fully fixed on Windows and Mac, but may still occasionally be
 noticeable on Linux, depending on the screen size and the size of
 toolbars, etc. Unfortunately a true fix for Linux is tricky because GTK is
 unable to report the height of a window's title bar before it is shown on
 screen. I opened #21945 to keep this problem in mind.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21945 [Applications/Tor Browser]: Fix initial window size on Linux

[Tor Bug Tracker & Wiki]

#21945: Fix initial window size on Linux
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Mozilla uplifted our window sizing patch, and it works very well on Mac
 and Windows, but on Linux windows are still sometimes smaller than they
 need to be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #3246 [Applications/Tor Browser]: Isolate HTTP cookies according to first and third party domain contexts

[Tor Bug Tracker & Wiki]

#3246: Isolate HTTP cookies according to first and third party domain contexts
-+-
 Reporter:  mikeperry|  Owner:  michael
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  backport-to-mozilla, tbb-|  Actual Points:
  linkability, tbb-usability-website, tbb-   |
  bounty, tbb-firefox-patch, ff52-esr-will-have  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 This will ship in 7.0a3 when we switch to ESR52.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #14057, #14059, #14061, #14062, ...

[Tor Bug Tracker & Wiki]

Batch modification to #14057, #14059, #14061, #14062, #14083, #14707, #14081 by 
gk:


Action: resolve

Comment:
No need for those tickets on our side anymore as Mozilla implemented 
double-keying of cookies which we ship in 7.0a3 when we switch to ESR 52.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #8842, #16886, #19192, #19955, ...

[Tor Bug Tracker & Wiki]

Batch modification to #8842, #16886, #19192, #19955, #20005, #20755, #21896 by 
gk:


Action: resolve

Comment:
This will be fixed in 7.0a3 which is based on Firefox 52 ESR.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #14085 [Applications/Tor Browser]: HTTP redirects can leak third-party state (cookies, etc)

[Tor Bug Tracker & Wiki]

#14085: HTTP redirects can leak third-party state (cookies, etc)
--+--
 Reporter:  michael   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:  #3246 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20905 [Applications/Tor Browser]: Tor Browser window does not get resized to the same sizes as before 6.5a4 anymore

[Tor Bug Tracker & Wiki]

#20905: Tor Browser window does not get resized to the same sizes as before 
6.5a4
anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-6.5-regression, tbb-usability,   |  Actual Points:
  tbb-fingerprinting-resolution, |
  TorBrowserTeam201704, ff52-esr-will-have   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-6.5-regression, tbb-usability, tbb-fingerprinting-resolution,
 TorBrowserTeam201704
 =>
 tbb-6.5-regression, tbb-usability, tbb-fingerprinting-resolution,
 TorBrowserTeam201704, ff52-esr-will-have
 * status:  needs_revision => closed
 * resolution:   => fixed


Comment:

 This seems to be fixed for me with the switch to ESR52. Please reopen if
 that is not the case on other machines/systems. This will make it into
 7.0a3.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18530 [Applications/Tor Browser]: Consider dropping support for Mac OS 10.6, 10.7, and 10.8

[Tor Bug Tracker & Wiki]

#18530: Consider dropping support for Mac OS 10.6, 10.7, and 10.8
-+-
 Reporter:  mcs  |  Owner:  boklm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704,  |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * keywords:  ff52-esr, TorBrowserTeam201704R, tbb-7.0-must-alpha =>
 ff52-esr, TorBrowserTeam201704, tbb-7.0-must-alpha
 * status:  needs_review => needs_information


Comment:

 Looks good to me. I'll update the `config.yml` accordingly. It seems we
 need (to check) two further things in this bug:

 1) A proper text explaining what's going on for OS X users < 10.9. Should
 we link to some Mozilla article? I looked a bit at
 https://support.mozilla.org/t5/Install-and-Update/Firefox-support-has-
 ended-for-Mac-OS-X-10-6-10-7-and-10-8/ta-p/32725 but that might not be
 that helpful in our context.

 2) Do we need to do anything to notify OS X users on < 10.9 that Tor
 Browser won't work? IIRC Firefox won't extract from the DMG on an
 unsupported system anymore. Having such a mechanism would probably be best
 (in addition to change the text on the website saying the min supported
 version is 10.9)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20426 [Applications/Tor Browser]: Getting rbm-based Tor Browser builds reproducible for all platforms

[Tor Bug Tracker & Wiki]

#20426: Getting rbm-based Tor Browser builds reproducible for all platforms
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:14 boklm]:
 > Replying to [comment:13 cypherpunks]:
 > > OK. So, direct question: why don't you use
 https://bugzilla.redhat.com/show_bug.cgi?id=1124342?
 >
 > We are building binutils with `--enable-deterministic-archives`:
 > https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/projects/binutils/config
 Hmm, seems overlooked since https://gitweb.torproject.org/builders/tor-
 browser-bundle.git/tree/gitian/descriptors/linux/gitian-utils.yml#n70 :(
 About `omni.ja`: https://gitweb.torproject.org/builders/tor-browser-
 bundle.git/tree/gitian/descriptors/windows/gitian-firefox.yml#n109 seems
 `# Crappy deterministic zip repackager` ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21943 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall getpid)

[Tor Bug Tracker & Wiki]

#21943: (Sandbox) Caught a bad syscall attempt (syscall getpid)
-+
 Reporter:  ageisp0lis   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  sandbox seccomp2 getpid  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:  sandbox => sandbox seccomp2 getpid
 * milestone:   => Tor: 0.3.1.x-final


Comment:

 What version of OpenSSL were you using?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20426 [Applications/Tor Browser]: Getting rbm-based Tor Browser builds reproducible for all platforms

[Tor Bug Tracker & Wiki]

#20426: Getting rbm-based Tor Browser builds reproducible for all platforms
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:13 cypherpunks]:
 > OK. So, direct question: why don't you use
 https://bugzilla.redhat.com/show_bug.cgi?id=1124342?

 We are building binutils with `--enable-deterministic-archives`:
 https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/projects/binutils/config

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+--
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201704R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201704 => TorBrowserTeam201704R
 * status:  needs_revision => needs_review


Comment:

 Thanks for your review! Here is an updated patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20761-04&id=1781f041f00f8f18a05b49d848d50fad0a6be40d

 We added comments to clarify the handling of comments within continued
 lines. It is counterintuitive, but tor essentially ignores comments within
 continued line sequences and does not interrupt the continued line. See
 the definition of `ContinuedVal` within
 https://gitweb.torproject.org/tor.git/tree/doc/torrc_format.txt. Also, we
 did not attempt to preserve the comment in that case because it is
 difficult to do so. Of course tor does not preserve comments when it
 rewrites torrc in response to a SAVECONF command anyway, which will happen
 if Tor Launcher's Network Settings dialog is ever used.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20426 [Applications/Tor Browser]: Getting rbm-based Tor Browser builds reproducible for all platforms

[Tor Bug Tracker & Wiki]

#20426: Getting rbm-based Tor Browser builds reproducible for all platforms
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 OK. So, direct question: why don't you use
 https://bugzilla.redhat.com/show_bug.cgi?id=1124342?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20426 [Applications/Tor Browser]: Getting rbm-based Tor Browser builds reproducible for all platforms

[Tor Bug Tracker & Wiki]

#20426: Getting rbm-based Tor Browser builds reproducible for all platforms
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 The diff in `libevent-2.0.5.dylib` should be fixed by commit
 d2c018a26ec61f85a2fa7a0f9a7360025ff0fb24 (using faketime to build it).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21222 [User Experience]: Redesigning torproject.org

[Tor Bug Tracker & Wiki]

#21222: Redesigning torproject.org
-+--
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  website  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-

Comment (by Jigsaw52):

 Some changes on the master branch introduced merge conflicts on my branch.
 Here is a branch with a currently merge-able version:
 https://github.com/Jigsaw52/tor/tree/torrc-dir-fix-1922_20170414

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by Jigsaw52):

 * status:  needs_revision => needs_review


Comment:

 I tried to fix this on this branch: https://github.com/Jigsaw52/tor/tree
 /my-family-list-fix-4498

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #21944 [Applications/Tor Browser]: Makeing all TBB users into middle nodes to make website traffic fingerprinting attacks much harder for a attacker

[Tor Bug Tracker & Wiki]

#21944: Makeing all TBB users into middle nodes to make website traffic
fingerprinting attacks much harder for a attacker
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Making every user that uses tor into a middle node would increase the
 overall network bandwidth and have a constant flow of data entering and
 leaving each users network. This could make a website traffic
 fingerprinting attack much harder for a observer watching the traffic on
 the users end. When the user starts Tor Browser bundle it could randomize
 the advertised bandwidth to prevent a attacker from subtracting the max
 bandwidth from the users network and get a estimation on how much the user
 and not the middle node is using. This could also make it much harder for
 a time correlation attack to be preformed on users because of the constant
 traffic flow entering and leaving the users network.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs