Re: [tor-bugs] #18788 [Core Tor/Tor]: Make the copyright license clear for torspec and proposals

[Tor Bug Tracker & Wiki]

#18788: Make the copyright license clear for torspec and proposals
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  license copyright nickm- |  Actual Points:
  deferred-20160905  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Speaking personally, I support placing the whole thing under the most
 permissive license possible, and I don't know anything more permissive
 than CC-0.  We still need to get a lawyer or three to sign off on us doing
 that. This looks like it's gonna take some time.

 (I hereby license 100% of the text that _I_ wrote in the tor-spec
 repository under the CC-0 license, to the extent that I am able to do so.)

--
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] #20318 [Applications/Torbutton]: Remove help-desk email address from aboutTor.dtd

[Tor Bug Tracker & Wiki]

#20318: Remove help-desk email address from aboutTor.dtd
+-
 Reporter:  phoul   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 aboutTor.dtd[1] still uses h...@rt.torproject.org, this should be removed
 until the help-desk is reopened.

 
 
 

 [1]:
 
https://gitweb.torproject.org/torbutton.git/tree/src/chrome/locale/en/aboutTor.dtd

--
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] #17965 [Applications/Tor Browser]: Isolate HPKP and HSTS to url bar domain

[Tor Bug Tracker & Wiki]

#17965: Isolate HPKP and HSTS to url bar domain
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201603   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 See also discussion in #6458.

--
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] #6458 [Applications/Tor Browser]: Double-key HSTS for third party content

[Tor Bug Tracker & Wiki]

#6458: Double-key HSTS for third party content
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-bounty, tbb-|  duplicate
  firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Resolving this bug is a duplicate of #17965, because HSTS and HPKP work
 pretty much the same way and a single patch can solve both.

--
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] #6458 [Applications/Tor Browser]: Double-key HSTS for third party content

[Tor Bug Tracker & Wiki]

#6458: Double-key HSTS for third party content
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-bounty, tbb-|  duplicate
  firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  new => closed
 * resolution:   => duplicate


--
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] #17965 [Applications/Tor Browser]: Isolate HPKP and HSTS to url bar domain

[Tor Bug Tracker & Wiki]

#17965: Isolate HPKP and HSTS to url bar domain
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201603   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 See also https://bugzilla.mozilla.org/show_bug.cgi?id=1253006

--
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] #17965 [Applications/Tor Browser]: Isolate HPKP and HSTS to url bar domain (was: Isolate HPKP pinning to url bar domain)

[Tor Bug Tracker & Wiki]

#17965: Isolate HPKP and HSTS to url bar domain
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201603   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

--
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] #20317 [Applications/Tor Browser]: Key permissions by first-party domain instead of origin (proposal)

[Tor Bug Tracker & Wiki]

#20317: Key permissions by first-party domain instead of origin (proposal)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Corresponding Mozilla bug at
 https://bugzilla.mozilla.org/show_bug.cgi?id=1308607

--
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] #20315 [Applications/Tor Launcher]: Tor launcher doesn't respect ReachableAddresses

[Tor Bug Tracker & Wiki]

#20315: Tor launcher doesn't respect ReachableAddresses
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  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] #20308 [Applications/Tor Browser]: TOR Browser crashes and dumps its core into my logs

[Tor Bug Tracker & Wiki]

#20308: TOR Browser crashes and dumps its core into my logs
--+
 Reporter:  LtL0zF48kDJaGn3aYg6LTLXGaCPnLUVv  |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by LtL0zF48kDJaGn3aYg6LTLXGaCPnLUVv):

 I haven't found out how to reproduce it. I started up TOR Browser, and
 dragged it over to my second screen, and suddenly, the window disappeared.
 This is the current version of TOR Browser Bundle, x64 Linux.

--
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] #20317 [Applications/Tor Browser]: Key permissions by first-party domain instead of origin (proposal)

[Tor Bug Tracker & Wiki]

#20317: Key permissions by first-party domain instead of origin (proposal)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Here's a demo that works on Firefox (not Tor Browser, because we don't
 have navigator.geolocation exposed).

 First visit
 https://torpat.ch/geolocate.html
 And choose "Always Share Location" for torpat.ch.

 Now visit
 https://arthuredelstein.github.io/tordemos/geolocate.html
 The iframe runs the same torpat.ch page to obtain location, and then uses
 postMessage to send the location to the parent page, at
 arthuredelstein.github.io.

 (When you are done, be sure to revoke permissions to torpat.ch! :))

--
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] #20317 [Applications/Tor Browser]: Key permissions by first-party domain instead of origin (proposal)

[Tor Bug Tracker & Wiki]

#20317: Key permissions by first-party domain instead of origin (proposal)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> In Firefox (and current Tor Browser), permissions are keyed by origin.
> That is a tracking vector -- for example, on Google maps, if click on the
> "Show your Location" button,
>
> [[Image(location.png)]]
>
> The browser asks "www.google.com: Would you like to Share your Location
> with this site?" If we choose "Always Share Location", then this
> permission is stored, keyed to www.google.com.
>
> [[Image(permission.png)]]
>
> Now the UI says "this site", which is, to my ear, synonymous with "first
> party domain". But now on other sites, any third-party object from
> www.google.com" (such as a Google Analytics script or a Google+ button)
> can know our location. And, further, it can expose a function call that
> any other script on the same page could call to obtain our location. So
> in practice, we have given permission for numerous domains to obtain our
> location. And the very existence of the unusual permission setting, or
> any other, helps to track us.
>
> So I would like to propose that we key every permission by first-party
> domain instead of origin domain. That means that the Permissions UI
> doesn't need to change much at all. We are still assigning each
> permission to a single domain. But this way, granting a permission to
> google.com would not leak to every other site.
>
> And I would argue that this is already the perception of most users when
> they see a permission requested for "this site". Most users are not
> knowledgeable about the subtleties of third-party scripts -- they expect
> a permission to apply to the site they are visiting (the first party).
>
> I would suggest we should write this patch for ESR52, which means using
> Origin Attributes and the pref "privacy.firstparty.isolate". Then we can
> hopefully uplift to Mozilla.

New description:

 In Firefox (and current Tor Browser), permissions are keyed by origin.
 That is a tracking vector -- for example, on Google maps, if click on the
 "Show your Location" button,

 [[Image(location.png)]]

 The browser asks "www.google.com: Would you like to Share your Location
 with this site?" If we choose "Always Share Location", then this
 permission is stored, keyed to www.google.com.

 [[Image(permission.png)]]

 Now the UI says "this site", which is, to my ear, synonymous with "first
 party domain". But now on other sites, any third-party iframe from
 www.google.com (such as created by a Google Analytics script or a Google+
 button) can know our location. And, further, it can expose a function call
 (using iframe postMessage tricks) that any other script on the same page
 could call to obtain our location. So in practice, we have given
 permission for numerous domains to obtain our location. And the very
 existence of the unusual permission setting, or any other, helps to track
 us.

 So I would like to propose that we key every permission by first-party
 domain instead of origin domain. That means that the Permissions UI
 doesn't need to change much at all. We are still assigning each permission
 to a single domain. But this way, granting a permission to google.com
 would not leak to every other site.

 And I would argue that this is already the perception of most users when
 they see a permission requested for "this site". Most users are not
 knowledgeable about the subtleties of third-party scripts -- they expect a
 permission to apply to the site they are visiting (the first party).

 I would suggest we should write this patch for ESR52, which means using
 Origin Attributes and the pref "privacy.firstparty.isolate". Then we can
 hopefully uplift to Mozilla.

--

--
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] #20317 [Applications/Tor Browser]: Key permissions by first-party domain instead of origin (proposal)

[Tor Bug Tracker & Wiki]

#20317: Key permissions by first-party domain instead of origin (proposal)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> In Firefox (and current Tor Browser), permissions are keyed by origin.
> That is a tracking vector -- for example, on Google maps, if click on the
> "Show your Location" button,
>

>
> The browser asks "www.google.com: Would you like to Share your Location
> with this site?" If we choose "Always Share Location", then this
> permission is stored, keyed to www.google.com.
>
> Now on other sites, any third-party object from www.google.com" (such as
> a Google Analytics script or a Google+ button) can know our location.
> Worse, it can expose a function call that any other script on the same
> page could call to obtain our location. So in practice, we have given
> permission for numerous domains to obtain our location. And the very
> existence of the permission setting, or any other, helps to distinguish
> us, and keying by origin doesn't help very much at all.
>
> So I would like to propose that we key every permission by first-party
> domain instead of origin domain. That means that the Permissions UI
> doesn't need to change much at all. We are still assigning each
> permission to a single domain. But this way, granting a permission to
> google.com would not leak to every other site.
>
> And I would argue that this is already the perception of most users when
> they see a permission requested. Most users are not knowledgeable about
> the subtleties of third-party scripts -- they expect a permission to
> apply to the site they are visiting in the URL bar.
>
> I would suggest we should write this patch for ESR52, which means using
> Origin Attributes and the pref "privacy.firstparty.isolate". Then we can
> hopefully uplift to Mozilla.

New description:

 In Firefox (and current Tor Browser), permissions are keyed by origin.
 That is a tracking vector -- for example, on Google maps, if click on the
 "Show your Location" button,

 [[Image(location.png)]]

 The browser asks "www.google.com: Would you like to Share your Location
 with this site?" If we choose "Always Share Location", then this
 permission is stored, keyed to www.google.com.

 [[Image(permission.png)]]

 Now the UI says "this site", which is, to my ear, synonymous with "first
 party domain". But now on other sites, any third-party object from
 www.google.com" (such as a Google Analytics script or a Google+ button)
 can know our location. And, further, it can expose a function call that
 any other script on the same page could call to obtain our location. So in
 practice, we have given permission for numerous domains to obtain our
 location. And the very existence of the unusual permission setting, or any
 other, helps to track us.

 So I would like to propose that we key every permission by first-party
 domain instead of origin domain. That means that the Permissions UI
 doesn't need to change much at all. We are still assigning each permission
 to a single domain. But this way, granting a permission to google.com
 would not leak to every other site.

 And I would argue that this is already the perception of most users when
 they see a permission requested for "this site". Most users are not
 knowledgeable about the subtleties of third-party scripts -- they expect a
 permission to apply to the site they are visiting (the first party).

 I would suggest we should write this patch for ESR52, which means using
 Origin Attributes and the pref "privacy.firstparty.isolate". Then we can
 hopefully uplift to Mozilla.

--

--
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] #20317 [Applications/Tor Browser]: Key permissions by first-party domain instead of origin (proposal)

[Tor Bug Tracker & Wiki]

#20317: Key permissions by first-party domain instead of origin (proposal)
--+-
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-linkability
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In Firefox (and current Tor Browser), permissions are keyed by origin.
 That is a tracking vector -- for example, on Google maps, if click on the
 "Show your Location" button,



 The browser asks "www.google.com: Would you like to Share your Location
 with this site?" If we choose "Always Share Location", then this
 permission is stored, keyed to www.google.com.

 Now on other sites, any third-party object from www.google.com" (such as a
 Google Analytics script or a Google+ button) can know our location. Worse,
 it can expose a function call that any other script on the same page could
 call to obtain our location. So in practice, we have given permission for
 numerous domains to obtain our location. And the very existence of the
 permission setting, or any other, helps to distinguish us, and keying by
 origin doesn't help very much at all.

 So I would like to propose that we key every permission by first-party
 domain instead of origin domain. That means that the Permissions UI
 doesn't need to change much at all. We are still assigning each permission
 to a single domain. But this way, granting a permission to google.com
 would not leak to every other site.

 And I would argue that this is already the perception of most users when
 they see a permission requested. Most users are not knowledgeable about
 the subtleties of third-party scripts -- they expect a permission to apply
 to the site they are visiting in the URL bar.

 I would suggest we should write this patch for ESR52, which means using
 Origin Attributes and the pref "privacy.firstparty.isolate". Then we can
 hopefully uplift to Mozilla.

--
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] #18788 [Core Tor/Tor]: Make the copyright license clear for torspec and proposals

[Tor Bug Tracker & Wiki]

#18788: Make the copyright license clear for torspec and proposals
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  license copyright nickm- |  Actual Points:
  deferred-20160905  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by twim):

 Please consider licensing specs under public domain. CC-0 seems to be the
 most portable solution.
 Though public domain may not run on some state architectures.

--
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] #20264 [Applications/Tor Browser]: Reduce number of security slider states from 4 to 3 (proposed)

[Tor Bug Tracker & Wiki]

#20264: Reduce number of security slider states from 4 to 3 (proposed)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:6 arthuredelstein]:
 > Replying to [comment:5 bugzilla]:
 > > > Also I think the current Medium-High is probably the best compromise
 for most users who are sophisticated enough to adjust the security slider.
 > > You think correctly, but it shows that TBB is still a compromise :(.
 > There is an inherent tension between security and usability in any
 browser -- a compromise is unavoidable. The slider is there to give the
 user some choice in the compromise they wish to make. If there were no
 tension, there would be no slider.
 Compromise is that the user wants to set High, but has to use Medium-High,
 because of e.g. #20314 and #17637.

--
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] #20297 [Applications/Tor Messenger]: OTR query messages with|without HTML formatting (was: Tor Messenger: error messages with|without HTML formatting)

[Tor Bug Tracker & Wiki]

#20297: OTR query messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

 * priority:  Medium => Low


--
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] #20298 [Applications/Tor Messenger]: Tor Messenger: OTR not working with macOS Sierra

[Tor Bug Tracker & Wiki]

#20298: Tor Messenger: OTR not working with macOS Sierra
+
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  otr |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Unfortunately, there isn't really any actionable information 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] #20264 [Applications/Tor Browser]: Reduce number of security slider states from 4 to 3 (proposed)

[Tor Bug Tracker & Wiki]

#20264: Reduce number of security slider states from 4 to 3 (proposed)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:5 bugzilla]:
 > > Also I think the current Medium-High is probably the best compromise
 for most users who are sophisticated enough to adjust the security slider.
 > You think correctly, but it shows that TBB is still a compromise :(.
 There is an inherent tension between security and usability in any browser
 -- a compromise is unavoidable. The slider is there to give the user some
 choice in the compromise they wish to make. If there were no tension,
 there would be no slider.

--
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] #3528 [Applications/Torbutton]: Torbutton menu does not appear when navigation bar is disabled.

[Tor Bug Tracker & Wiki]

#3528: Torbutton menu does not appear when navigation bar is disabled.
-+--
 Reporter:  cowsarenotevil   |  Owner:  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Torbutton   |Version:  Torbutton: 1.4.0
 Severity:  Normal   | Resolution:  duplicate
 Keywords:  navigation toolbar menu  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by bugzilla):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 Closed as a duplicate of #3637.

--
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] #9607 [Applications/Tor Browser]: torbutton popup menu doesn't appear

[Tor Bug Tracker & Wiki]

#9607: torbutton popup menu doesn't appear
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 Closed as a duplicate of #3528.

--
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] #20316 [Applications/Tor Messenger]: Update OS X toolchain

[Tor Bug Tracker & Wiki]

#20316: Update OS X toolchain
+---
 Reporter:  arlolra |  Owner:  boklm
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 Port the changes in #18331 to rbm

 Started on this in,
 https://github.com/TheTorProject/tor-messenger-
 build/commit/65d9353d2e083ec2aef4fe4616a3c80d4390dc68

 but boklm agree to takeover.

 (At the same time, it might be worth switching the Windows distribution to
 Debian-7.11 so that all platforms are building on 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] #4758 [Applications/Torbutton]: TorButton 1.4.5.1 requires Navigation Bar

[Tor Bug Tracker & Wiki]

#4758: TorButton 1.4.5.1 requires Navigation Bar
+---
 Reporter:  4c35238b|  Owner:  mikeperry
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by bugzilla):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 Closed as a duplicate of #3637.

--
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] #786 [Applications/Tor Browser]: file urls cannot be re-enabled after being disabled

[Tor Bug Tracker & Wiki]

#786: file urls cannot be re-enabled after being disabled
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  None
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => assigned
 * severity:   => Normal
 * component:  Applications/Torbutton => Applications/Tor Browser
 * owner:   => tbb-team
 * version:  1.2.0rc5 =>
 * keywords:   => tbb-usability


Comment:

 > This new, "good" tab can happily co-exist with the old, "bad" tab, which
 stays bad
 This behavior still appears sometimes.

--
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] #7220 [Applications/Tor Browser]: Tabs do not close on TorBundle

[Tor Bug Tracker & Wiki]

#7220: Tabs do not close on TorBundle
--+--
 Reporter:  wedding13347  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  user disappeared
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  assigned => closed
 * keywords:  needs-triage => tbb-usability
 * resolution:   => user disappeared
 * severity:   => Normal


--
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] #19767 [Core Tor/Tor]: Solaris, compile warning: "_FILE_OFFSET_BITS" redefined and core dump

[Tor Bug Tracker & Wiki]

#19767: Solaris, compile warning: "_FILE_OFFSET_BITS" redefined and core dump
-+-
 Reporter:  RainerSchmidt|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.5-rc
 Severity:  Major| Resolution:  fixed
 Keywords:  Solaris, regression, crash,  |  Actual Points:  .3
  028-backport   |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 No 0.2.8 backport planned; too big.

--
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] #20241 [Core Tor/Tor]: Fix compilation on osx sierra (10.12)

[Tor Bug Tracker & Wiki]

#20241: Fix compilation on osx sierra (10.12)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  osx TorCoreTeam201609 review-|  Actual Points:  .1
  group-10   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  osx TorCoreTeam201609 => osx TorCoreTeam201609 review-group-10


Comment:

 This is merged in 0.2.9, but I'm calling it review-group-10 for 0.2.8.  If
 you like it, we should leave it in merge_ready until we know whether we're
 putting another 0.2.8 out before 0.2.9 is stable.

--
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] #7164 [Core Tor/Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1

[Tor Bug Tracker & Wiki]

#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still 
referenced
1 node(s); held_by_nodes == 1
-+-
 Reporter:  jaj123   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-backport, nickm- |  Actual Points:
  should-review, TorCoreTeam201609   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 tor-client, 025-backport, nickm-should-review, TorCoreTeam201609,
 review-group-10
 => tor-client, 025-backport, nickm-should-review, TorCoreTeam201609
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.x-final


Comment:

 If this is so pervasive, we should expect the fix to be destabilizing, and
 aim it for 0.3.0. :/

--
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] #20315 [Applications/Tor Launcher]: Tor launcher doesn't respect ReachableAddresses

[Tor Bug Tracker & Wiki]

#20315: Tor launcher doesn't respect ReachableAddresses
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 I have a situation where my guard should NOT be on *:80 or *:443. It can
 be anything else.

 I added these 2 lines before starting, but the tor launcher would remove
 them.

 ReachableAddresses reject *:80
 ReachableAddresses reject *:443

--
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] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

[Tor Bug Tracker & Wiki]

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:14 bugzilla]:
 > Replying to [comment:3 arthuredelstein]:
 > > Thanks for discovering and reporting this issue, bugzilla.
 > Really? I'm pleased :)

 Absolutely -- you are making valuable contributions.

 > @gk too:
 > What about comment:2?

 If something in content could change a pref, that's would obviously be a
 very serious bug. If you can find an reproducible example, by all means
 open a ticket.

 It sounds much more likely to me that the
 "dom.workers.sharedWorkers.enabled" pref had a user value set in your
 profile (probably by torbutton), carried over from a previous version of
 TBB.

 > Would it be addressed or buried in the closed tickets as many other
 issues?

 If you find an issue that is lost, please open a ticket! It's much easier
 to deal with if there is a single issue per ticket. But please also
 understand we have to prioritize. And that everyone here is trying to do
 the right thing.

--
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] #17879 [Applications/Tor Browser]: Activating the Flash Player is not working anymore since Tor Browser 5.0.5

[Tor Bug Tracker & Wiki]

#17879: Activating the Flash Player is not working anymore since Tor Browser 
5.0.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-usability-website,   |  Actual Points:
  TorBrowserTeam201512   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

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


Comment:

 What else is needed to be written in order to make you realize that you
 are
 > using Mozilla's broken "Ask to Activate".
 since #9867?

--
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] #20315 [Applications/Tor Launcher]: Tor launcher doesn't respect ReachableAddresses

[Tor Bug Tracker & Wiki]

#20315: Tor launcher doesn't respect ReachableAddresses
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 On a fresh copy of tor browser, any included ReachableAddresses rules are
 removed when the torrc file is overwritten by the tor launcher.

--
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] #17262 [Core Tor/Tor]: Experimental simulation prototype for guard selection algorithm

[Tor Bug Tracker & Wiki]

#17262: Experimental simulation prototype for guard selection algorithm
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, TorCoreTeam201606,   |  Actual Points:
  prop259, tor-guard, tor-guards-revamp, nickm-  |
  deferred-20161005  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by asn):

 * owner:  asn =>
 * status:  needs_revision => assigned


--
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] #14337 [Applications/Tor Browser]: Tabs Not All Shown in Normal View - no button to list rest

[Tor Bug Tracker & Wiki]

#14337: Tabs Not All Shown in Normal View - no button to list rest
--+---
 Reporter:  plmlbn|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

 * keywords:   => tbb-usability
 * status:  new => needs_information
 * severity:   => Normal


Comment:

 Is this still an issue?

--
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: #19043, #19142, #19661, #20273, ...

[Tor Bug Tracker & Wiki]

Batch modification to #19043, #19142, #19661, #20273, #14881 by nickm:
keywords to review-group-10

Comment:
Add 0.3.0 needs_review items (and ones that haven't been in needs_revision for 
very long) to review-group-10.

--
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] #20267 [Core Tor/Tor]: Use -DOPENSSL_SYS_WIN32 on Windows

[Tor Bug Tracker & Wiki]

#20267: Use -DOPENSSL_SYS_WIN32 on Windows
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, windows  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  new => needs_information


Comment:

 Since we dropped OpenSSL 1.0.0 support, is this still an issue (with
 >=1.0.1)?

--
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: #12595, #12600, #19287, #19290, ...

[Tor Bug Tracker & Wiki]

Batch modification to #12595, #12600, #19287, #19290, #19291, #19292, #19293 by 
nickm:
keywords to TorCoreTeam201610
milestone to Tor: 0.3.0.x-final

Comment:
Defer target for these doc fixes to 0.3.0 (though of course they can go into 
0.2.9 if they're done on time.)

--
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] #20314 [Applications/Tor Browser]: Make SVG click-to-play

[Tor Bug Tracker & Wiki]

#20314: Make SVG click-to-play
--+
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  noscript, tbb-
  |  usability
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently TBB uses the worst option: entirely disabled. Even no white
 rectangle on a white background. It's not fair that videos have CTP, but
 images haven't. NoScript is most suitable now for this feature.

--
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: #19999, #18357, #19167, #20176, ...

[Tor Bug Tracker & Wiki]

Batch modification to #1, #18357, #19167, #20176, #19223, #20269 by nickm:
keywords to review-group-10

Comment:
Add needs_review 0.2.9 tickets, plus ones that have been in needs_revision for 
less than a week, to review-group-10.

--
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] #13827 [Core Tor/Tor]: Cell handling code duplication in channel.c

[Tor Bug Tracker & Wiki]

#13827: Cell handling code duplication in channel.c
---+
 Reporter:  rl1987 |  Owner:  pingl
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  refactoring, easy  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  dgoulet, nickm |Sponsor:
---+
Changes (by nickm):

 * keywords:  refactoring, easy, review-group-9 => refactoring, easy
 * reviewer:  dgoulet => dgoulet, nickm
 * status:  needs_review => merge_ready


Comment:

 Nice!  This can go in once 0.3.0 is forked.

--
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: #17238, #14881, #18320, #19024, ...

[Tor Bug Tracker & Wiki]

Batch modification to #17238, #14881, #18320, #19024, #19487, #19552, #20004 by 
nickm:


Comment:
These have sat in needs_revision for a few weeks at least. Removing from 
review-group-9, not adding to review-group-10.

--
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] #13827 [Core Tor/Tor]: Cell handling code duplication in channel.c

[Tor Bug Tracker & Wiki]

#13827: Cell handling code duplication in channel.c
---+---
 Reporter:  rl1987 |  Owner:  pingl
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  refactoring, easy, review-group-9  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by nickm):

 * status:  needs_revision => needs_review


--
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: #15055, #7164, #18988, #20070

[Tor Bug Tracker & Wiki]

Batch modification to #15055, #7164, #18988, #20070 by nickm:
keywords to review-group-10

Comment:
Moving not-reviewed-by-me tickets in review-group-9, and for-0.2.9/0.2.8 
tickets, to review-group-10.

--
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] #10180 [Applications/Tor Browser]: Vidalia connects to Tor, but doesn't launch Firefox

[Tor Bug Tracker & Wiki]

#10180: Vidalia connects to Tor, but doesn't launch Firefox
--+--
 Reporter:  GuillermoLamas|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => closed
 * severity:   => Normal
 * version:  Tor: 0.2.3.25 =>
 * milestone:  TorBrowserBundle 2.3.x-stable =>
 * keywords:  tbb-firefox-patch =>
 * resolution:   => wontfix


Comment:

 Vidalia is dead.

--
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] #17637 [Applications/Tor Browser]: NoScript in Tor-Browser allows all third party domains

[Tor Bug Tracker & Wiki]

#17637: NoScript in Tor-Browser allows all third party domains
--+--
 Reporter:  ctbu  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  NoScript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:  Tor-Browser NoScript => NoScript
 * status:  closed => reopened
 * resolution:  worksforme =>


Comment:

 Hmm, OP described the problem and closed the ticket...
 Good conclusions are in comment:3. This setting in High when enabling JS
 leads to worse security than in Medium-High...

--
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] #20313 [Applications/Tor Browser]: Usual and hardened browser version get confused by GNOME

[Tor Bug Tracker & Wiki]

#20313: Usual and hardened browser version get confused by GNOME
--+--
 Reporter:  rugk  |  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:|
--+--
 When you have the "usual" and the hardened version of Tor Browser
 installation installed "side by side" (= on the same machine) GNOME often
 confuses them (and displays the wrong title, ...) and the UX is pretty bad
 as one cannot really be sure what version is executed right now.

 Fortunately the way to solve this is easy: The hardened Tor Browser
 version should use a different class than the usual one. So just change
 these classes in "start-tor-browser" (and of course all `StartupWMClass`es
 too).

 Similar issues:
 * https://unix.stackexchange.com/questions/314338/gnome-confuses-names-of-
 multiple-different-firefox-installations/314833
 * http://unix.stackexchange.com/questions/313151/gnome-shell-favorites-
 how-running-software-is-determined/314828#314828

--
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] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-torbutton, tbb-security, TorBrowserTeam201610 => tbb-
 torbutton, tbb-security, tbb-sandboxing, TorBrowserTeam201610R
 * status:  needs_revision => needs_review


Comment:

 Here are revised patches for Tor Launcher and Torbutton:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20111-03&id=6ac80cecfc53371791c5b492b22e280abb8ca181

 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug20111-02&id=6d36b290c8064b19eb9b931f137131bc9cc47529

 We had to include a copy of Tor Launcher's string unescape code in
 Torbutton, which is a little annoying but seems like the best alternative
 for now (eventually, we should make it so everything uses Arthur's tor-
 control-port.js module or its successor).

 #20261 is still an outstanding problem.

--
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] #5456 [Core Tor/Tor]: Defend against path bias and tagging attacks

[Tor Bug Tracker & Wiki]

#5456: Defend against path bias and tagging attacks
-+-
 Reporter:  mikeperry|  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  SponsorZ-large needs-proposal tor-   |  Actual Points:
  client |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Mikeperry probably has the best handle on the status of this.

--
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] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

[Tor Bug Tracker & Wiki]

#20307: [warn] Remote server sent bogus reason code 65021
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (edited above comment because of my omissions and errors.)

--
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] #20146 [Applications/Tor Browser]: Firefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning bypass for addons.mozilla.org and other built-in sites (was: Tor browser certific

[Tor Bug Tracker & Wiki]

#20146: Firefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning 
bypass
for addons.mozilla.org and other built-in sites
--+--
 Reporter:  mancha|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:  CVE-2016-5284 => tbb-security
 * status:  new => needs_review


Comment:

 Where does the actual security discussion take place?

 As OP provides a patch, it's not polite to leave this ticket as new.

 @TBB Team, for the record:
 It wasn't
 > irresponsible disclosure
 because
 https://twitter.com/EisMC2/status/775440744202981376
 > @dexterdyne @movrcx @torproject nah they actively have ignored serious 0
 days before, submit by good people who know wth theyre talkin about

 https://twitter.com/movrcx/status/776800848752078848
 > @jrmithdobbs @matthew_d_green @torproject @ioerror No.I attempted
 responsible disclosure and was ridiculed. So I dropped public Full Disclsr

--
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] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

[Tor Bug Tracker & Wiki]

#20307: [warn] Remote server sent bogus reason code 65021
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Oh darn, you said 65021, not 65012.  That makes the target
 -END_STREAM_REASON_CONNECTFAILED.

 This warning should only be possible if you're running a controller, since
 it only appears in circuit_end_reason_to_control_string , and only
 control_event_circuit_status calls that...

 Negative circuit close reason codes can come from at least these:
  * pathbias_count_build_attempt.
  * pathbias_check_probe_response, inconsistently.
  * circuit_handle_first_hop
  * circuit_send_next_onion_skin
  * circuit_finish_handshake



 Wait.  This is wrong:
 {{{
 src/or/control.c:  circuit_mark_for_close(TO_CIRCUIT(circ),
 -END_CIRC_REASON_CONNECTFAILED);
 }}}

 That looks quite suggestive.

--
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] #9101 [Applications/Tor Browser]: about:home search is broken

[Tor Bug Tracker & Wiki]

#9101: about:home search is broken
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => closed
 * keywords:  tbb-firefox-patch => tbb-usability
 * resolution:   => fixed
 * severity:   => Normal


Comment:

 Fixed in ESR45 or earlier.

--
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] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

[Tor Bug Tracker & Wiki]

#20307: [warn] Remote server sent bogus reason code 65021
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 err no, not END_STREAM_REASON_NOSUCHSERVICE. END_CIRC_REASON_NOSUCHSERVICE
 .

--
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] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

[Tor Bug Tracker & Wiki]

#20307: [warn] Remote server sent bogus reason code 65021
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Maybe we're using negative numbers to indicate failure, and forgetting to
 turn them positive somewhere?  Because if we interpreted
 -END_STREAM_REASON_NOSUCHSERVICE as a negative 16 bit integer, we'd get
 0xfff4.  And if we mask ou END_CIRC_REASON_FLAG_REMOTE (512), we get
 0xfdf4 == 65012.

--
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] #7854 [Applications/Tor Browser]: Tell user why we exit() the browser

[Tor Bug Tracker & Wiki]

#7854: Tell user why we exit() the browser
--+--
 Reporter:  ben   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => closed
 * keywords:  tbb-usability, tbb-firefox-patch => tbb-usability
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 Vidalia is dead.

--
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] #7130 [Applications/Tor Browser]: Canvas image data is blocked from chrome (such as NoScript's ClearClick)

[Tor Bug Tracker & Wiki]

#7130: Canvas image data is blocked from chrome (such as NoScript's ClearClick)
--+---
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

 * status:  new => needs_information
 * keywords:  tbb-firefox-patch => noscript
 * severity:   => Normal


Comment:

 Giorgio, what do you think about 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] #19520 [Applications/Tor Browser]: Investigate "No last modified time (bug 1000338)" entries visible in about:cache

[Tor Bug Tracker & Wiki]

#19520: Investigate "No last modified time (bug 1000338)" entries visible in
about:cache
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Why do you think they are not isolated?
 There are a lot of such entries in a cache, e.g.:
 {{{
 Key Data size   Fetch count Last ModifedExpires
 Pinning
 https://pinning-test.badssl.com/0 bytes 1   No last
 modified time (bug 1000338) No expiration time
 }}}
 and if you click on it, you'll get
 {{{
 Cache entry information
 The cache entry you selected is not available.
 }}}
 So it's not a bug when entry which isn't available has no metadata,
 including "last modified time". But its presence in a cache list seems to
 be a bug.

--
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] #20214 [Applications/Tor Browser]: Sonic Cross Device Tracking techniques could be used to launch deanonymization attacks against some users (was: Ultrasound Cross Device Tracking techn

[Tor Bug Tracker & Wiki]

#20214: Sonic Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--+--
 Reporter:  VasiliosMavroudis |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-proxy-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:   => tbb-proxy-bypass
 * version:  Tor: unspecified =>


Comment:

 At a first glance it looks like OP came here with a tinfoil hat,
 especially as most 44.1/48 kHz formats are not ultrasound capable. But, in
 general, there is some chance to become deanonymized during playback of
 watermarked media (e.g. from YouTube) in a range where compromised devices
 can record the differences in sound.
 > The prompt would only serve as an annoyance that the user would learn to
 ignore.
 Warning as for maximization should be enough.

--
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] #13827 [Core Tor/Tor]: Cell handling code duplication in channel.c

[Tor Bug Tracker & Wiki]

#13827: Cell handling code duplication in channel.c
---+---
 Reporter:  rl1987 |  Owner:  pingl
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  refactoring, easy, review-group-9  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  dgoulet|Sponsor:
---+---

Comment (by pingl):

 Obviously `relay.c` and `test_channel.c` don't need any patch now.

--
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] #19301 [Core Tor/Tor]: Accept Ed25519 identities in EXTEND2 cells

[Tor Bug Tracker & Wiki]

#19301: Accept Ed25519 identities in EXTEND2 cells
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop220, ed25519, tor-crypto-|  Actual Points:
  identity, tor-ed25519-proto,   |
  TorCoreTeam201609, nickm-deferred-20161005 |
Parent ID:  #15056   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by nickm):

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


Comment:

 This did get implemented on the #15056_wip branch in september.

--
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] #19302 [Core Tor/Tor]: Send ed25519 IDs in EXTEND2 cells

[Tor Bug Tracker & Wiki]

#19302: Send ed25519 IDs in EXTEND2 cells
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop220, ed25519, tor-crypto-|  implemented
  identity, tor-ed25519-proto,   |  Actual Points:
  TorCoreTeam201609, nickm-deferred-20161005 |
Parent ID:  #15056   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by nickm):

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


Comment:

 This did get implemented on the #15056_wip branch in september.

--
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] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-sandboxing, tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  tbb-sandbox, tbb-torbutton, TorBrowserTeam201609R => tbb-
 sandboxing, tbb-torbutton, TorBrowserTeam201609R


--
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] #19750 [Applications/Tor Browser]: Sandboxing in Tor Browser

[Tor Bug Tracker & Wiki]

#19750: Sandboxing in Tor Browser
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Replying to [comment:11 bugzilla]:
 > (@mcs/brade: the main ticket uses `tbb-sandboxing`, so `tbb-sandbox`
 looks confusing.)

 Thanks. Fixed in #20304.

--
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] #20304 [Applications/Tor Browser]: SOCKS socket does not support spaces and other special characters

[Tor Bug Tracker & Wiki]

#20304: SOCKS socket does not support spaces and other special characters
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * keywords:  tbb-sandbox, TorBrowserTeam201610R => tbb-sandboxing,
 TorBrowserTeam201610R


--
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] #20184 [Applications/Tor Browser]: OS X builds are still not reproducible on some machines

[Tor Bug Tracker & Wiki]

#20184: OS X builds are still not reproducible on some machines
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-gitian, GeorgKoppen201610,   |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Seems using the 10.6 SDK works. \o/

--
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] #20302 [Obfuscation/FTE]: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0

[Tor Bug Tracker & Wiki]

#20302: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0
---+---
 Reporter:  gk |  Owner:  kpdyer
 Type:  defect | Status:
   |  needs_review
 Priority:  Very High  |  Milestone:
Component:  Obfuscation/FTE|Version:
 Severity:  Blocker| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-gitian => tbb-gitian, TorBrowserTeam201610R


Comment:

 bug_20302 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20302&id=8d47b8e5bd03239b3c4d4918102369ba2615f7b0)
 in my public tor-browser-bundle repo has a fix for this for review:

 kpdyer: It would be neat if you could look over the patch to `setup.py`
 and merge it upstream if you think this is okay. In this case we'd just
 bump the `libfte` tag.

 It seems that FTE is not working, though. It gets stuck at "Establishing
 an encrypted directory connection". That's probably a separate issue. Any
 ideas on how to debug this one?

--
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] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610R   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by bugzilla):

 Do you want to see the truth?

--
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] #13464 [Applications/Tor Browser]: NoScript blocks right-click searching of text

[Tor Bug Tracker & Wiki]

#13464: NoScript blocks right-click searching of text
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript, tbb-usability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:   => noscript, tbb-usability


Comment:

 https://search.disconnect.me/ right-click searching of text works, so most
 users are not affected.

--
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] #13827 [Core Tor/Tor]: Cell handling code duplication in channel.c

[Tor Bug Tracker & Wiki]

#13827: Cell handling code duplication in channel.c
---+---
 Reporter:  rl1987 |  Owner:  pingl
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  refactoring, easy, review-group-9  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  dgoulet|Sponsor:
---+---

Comment (by pingl):

 Ok, that makes sense. I didn't want to swap the order of the check on
 `CHANNEL_IS_CLOSING(chan)` and `q.type = ...`
 This makes everything easier. Just fix that and I'll commit the new
 version.

--
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] #19200 [Applications/Tor Browser]: HTML5 video not blocked with placeholder, plays automatically

[Tor Bug Tracker & Wiki]

#19200: HTML5 video not blocked with placeholder, plays automatically
-+-
 Reporter:  potato   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security-slider, |  Actual Points:
  tbb-6.0-issues, GeorgKoppen201610, |
  TorBrowserTeam201610, noscript |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:
 tbb-security-slider, tbb-6.0-issues, GeorgKoppen201610,
 TorBrowserTeam201610
 =>
 tbb-security-slider, tbb-6.0-issues, GeorgKoppen201610,
 TorBrowserTeam201610, noscript


Comment:

 Replying to [comment:16 ma1]:
 Giorgio, gk asked you about the security hole 3 mo ago. Do you think it's
 not about NoScript or it shouldn't be addressed in a timely fashion?
 > The only partial work around I can think of is to implement a "special
 case" ClickToPlay for MSE, activating all the elements of a certain page
 if any placeholder gets clicked (the key would be page's URL, rather than
 the non-existent "media URL", and a page reload would occur). Would that
 work for you?
 It looks like TBB shouldn't expose MSE availability to sites for which JS
 is disabled (to make HTML5 A/V visible). But for JS-enabled sites your
 "ClickToPlay for MSE" feature looks good.

--
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] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: teor (added)


Comment:

 Here's what git bisect says:
 {{{
 There are only 'skip'ped commits left to test.
 The first bad commit could be any of:
 268608c0a0605e596d1a884ee35d432c88bac38b
 2d33d192fc4dd0da2a2e038dd87b277f8e9b90de
 e72cbf7a4e346f0d379961520db8bea7e9249f88
 We cannot bisect more!
 }}}

 I think I blame 2d33d192fc4dd0da2a2e038dd87b277f8e9b90de, since that's the
 one that introduces the warning in the first place.

--
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] #19210 [Applications/Tor Browser]: NoScript places WebM videos too late behind click-to-play in higher security levels

[Tor Bug Tracker & Wiki]

#19210: NoScript places WebM videos too late behind click-to-play in higher
security levels
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-regression, tbb-security-|  Actual Points:
  slider, tbb-6.0-issues, noscript   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  tbb-regression, tbb-security-slider, tbb-6.0-issues => tbb-
 regression, tbb-security-slider, tbb-6.0-issues, noscript


Comment:

 Replying to [comment:10 ma1]:
 > Yes, please, the more the reproducible cases I can test against, the
 better.
 > Thank you.
 Maybe, some fixes to test the current case which bugzilla reported in
 TBB's blog
 > as on 5.5.5 (based on ESR38) e.g. the video is not blocked at all for
 some reason. Which makes me nervous.

--
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] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Looks like this bug also exists in 0.2.8.

--
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] #19888 [Core Tor/Tor]: New guard plan - separate state instances when EntryNodes/ExcludeNodes/etc are used

[Tor Bug Tracker & Wiki]

#19888: New guard plan - separate state instances when 
EntryNodes/ExcludeNodes/etc
are used
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, nickm-deferred-20161005 |
Parent ID:  #19877   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by andrea):

 * status:  new => assigned
 * owner:   => nickm


Comment:

 Reassigning some prop 271 tickets to nickm for parallel work in Oct.

 (We're also going to need to change how we serialize/deserialize guard
 selection contexts about 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] #19881 [Core Tor/Tor]: New guard plan - guard selection for circuits

[Tor Bug Tracker & Wiki]

#19881: New guard plan - guard selection for circuits
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, nickm-deferred-20161005 |
Parent ID:  #19877   | Points:  5
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by andrea):

 * status:  new => assigned
 * owner:   => nickm


Comment:

 Reassigning some prop 271 tickets to nickm for parallel work in Oct.

--
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] #19882 [Core Tor/Tor]: New guard plan - update guard state when a circuit fails/succeeds

[Tor Bug Tracker & Wiki]

#19882: New guard plan - update guard state when a circuit fails/succeeds
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, nickm-deferred-20161005 |
Parent ID:  #19877   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by andrea):

 * owner:   => nickm
 * status:  new => assigned


Comment:

 Reassigning some prop 271 tickets to nickm for parallel work in Oct.

--
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] #19879 [Core Tor/Tor]: Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS per new guard plan

[Tor Bug Tracker & Wiki]

#19879: Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS per 
new
guard plan
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, nickm-deferred-20161005 |
Parent ID:  #19877   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by andrea):

 * status:  new => assigned
 * owner:   => nickm


Comment:

 Reassigning some prop 271 tickets to nickm for parallel work in Oct.

--
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] #20264 [Applications/Tor Browser]: Reduce number of security slider states from 4 to 3 (proposed)

[Tor Bug Tracker & Wiki]

#20264: Reduce number of security slider states from 4 to 3 (proposed)
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [ticket:20264 arthuredelstein]:
 > Something we talked about at the Seattle meeting is the possibility of
 having only 3 allowed security slider states: Low, Medium and High.
 Lo-Mid-Hi, let's make security as easy as consumer-grade electronics :)
 (No, it will never be as easy, it's just a false sense of security.)
 > We would migrate users at Medium-Low to Medium-High and rename the
 latter to Medium. It seems such a change would improve usability and
 security.
 Usability - by removing two-word names :), security - by removing one JS-
 MitM-enabled position, and privacy - by reducing fingerprinting.
 > Also I think the current Medium-High is probably the best compromise for
 most users who are sophisticated enough to adjust the security slider.
 You think correctly, but it shows that TBB is still a compromise :(. Every
 higher setting should include everything from previous (including
 flexibility) and shouldn't degrade in security options (I'll file separate
 tickets for those issues).
 > Discuss! :)
 The other teams prohibit to use bugtracker for discussions, but TBB Team
 encourages :)
 (It's good when no forum, but could be bad when no moderation.)

--
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] #20312 [Internal Services/Service - trac]: Extend the file size for HTML preview to at least 1 megabyte

[Tor Bug Tracker & Wiki]

#20312: Extend the file size for HTML preview to at least 1 megabyte
--+-
 Reporter:  bugzilla  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 For a lot of files on Trac "HTML preview not available, since the file
 size exceeds 262144 bytes."
 e.g.
 
https://trac.torproject.org/projects/tor/attachment/wiki/Linda/oct-2016-goals.JPG
 and others from https://trac.torproject.org/projects/tor/wiki/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] #19750 [Applications/Tor Browser]: Sandboxing in Tor Browser

[Tor Bug Tracker & Wiki]

#19750: Sandboxing in Tor Browser
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by bugzilla):

 Replying to [comment:7 bugzilla]:
 > In or Of TBB? (Content or App?)
 For "Of" effort on Windows: CIS (Comodo Internet Security suite) sandbox
 could be recommended (free).
 https://help.comodo.com/topic-72-1-623-7754-The-Sandbox---An-Overview.html

 (@mcs/brade: the main ticket uses `tbb-sandboxing`, so `tbb-sandbox` looks
 confusing.)

--
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] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

[Tor Bug Tracker & Wiki]

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:3 arthuredelstein]:
 > Thanks for discovering and reporting this issue, bugzilla.
 Really? I'm pleased :)

 @gk too:
 What about comment:2? Would it be addressed or buried in the closed
 tickets as many other issues?

--
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] #20195 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere's SSL Observatory code doesn't honor domain isolation.

[Tor Bug Tracker & Wiki]

#20195: HTTPS Everywhere's SSL Observatory code doesn't honor domain isolation.
-+-
 Reporter:  yawning  |  Owner:  legind
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:10 gk]:
 > > {{{
 > > [09-22 08:31:02] Torbutton WARN: no SOCKS credentials found for
 current document.
 > > }}}
 TBB has a lot of places with this warning, e.g. while fetching
 `RecommendedTBBVersions`, so what?
 > Alright, so here is what is going on. First, do you see the weird
 floating point number thing appended to the `#` in the
 `check.torproject.org` URL?
 FP with two dots? He-he.
 > Torbutton does not do such things.
 But it looked like yours :)
 > It is visible there that the request does not go over the catch-all
 circuit but rather is put on one without any username/password isolation
 at all.
 If `getinfo circuit-status` doesn't lie, the request does go over the
 catch-all circuit, even though without any username/password isolation at
 all.

 This is another one recent crap from HTTPSE: it look like it was developed
 as a virus or without security audit at all. Is it suitable for TBB?

 (Also it is doing 3 requests in a row to `check.torproject.org`, on
 `NEWNYM` 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

Re: [tor-bugs] #20311 [Metrics/Metrics website]: Remove redirects and update error page

[Tor Bug Tracker & Wiki]

#20311: Remove redirects and update error page
-+--
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 https://gitweb.torproject.org/karsten/metrics-web.git/log/?h=task-20311

--
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] #20311 [Metrics/Metrics website]: Remove redirects and update error page

[Tor Bug Tracker & Wiki]

#20311: Remove redirects and update error page
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We briefly discussed this at the metrics team meeting yesterday.  There
 are still some quite old redirects in place on Tor Metrics.  We concluded
 that we should turn them into "manual redirects" where we only display the
 link rather than redirecting users automatically, forcing them to notice
 and update their bookmarks accordingly.  However, I read today that using
 301 status codes is just fine for redirecting.

 Now I wonder if the manual redirect idea might be a step backwards,
 because then there will be "content" again for search engines to index,
 which seems wrong.  Maybe we can simply remove these redirects after 9
 months.  Users should notice that the URL has changed, shouldn't they?

 While looking at the code I also found that our error page contains an
 outdated sitemap with many links that would need to be redirected.  We
 should simply remove those links.

 I'll attach a branch in a minute once I have a ticket number.

--
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] #20244 [Applications/Tor Browser]: Move privacy checkboxes to about:preferences#privacy (proposed)

[Tor Bug Tracker & Wiki]

#20244: Move privacy checkboxes to about:preferences#privacy (proposed)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:2 arthuredelstein]:
 > I've written patches for this, because it's going to make the problems I
 encountered in #18093 much easier to solve.
 yay :)
 > There are 6 patches here (in which I remove checkboxes one by one and
 then clean up the UI):
 > https://github.com/arthuredelstein/torbutton/commits/20244
 And rename "Privacy and Security Settings..." menu item?
 > and 2 patches here (where I add two checkboxes to the
 about:preferences#privacy page):
 > https://github.com/arthuredelstein/tor-browser/commits/20244
 "Restrict third party..." has "strange" relations with FF's "Third party
 cookies" option, so the layout should reflect the dependencies.
 > Note that the last torbutton patch adds an overlay so that the our
 translated checkbox labels can be temporarily applied to the
 about:preferences page. If Mozilla uplifts these to Firefox and translates
 the labels themselves, then we won't need this overlay any more.
 It's good to get this upsteamed while Mozilla is in `mozilla52`: behind a
 pref as resistFingerprinting and first-party isolation, but also
 Mozillians could make suggestions about naming, layout, hints, etc in the
 FF's UI.

--
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] #18797 [Metrics/metrics-lib]: create a DescriptorGenerator?

[Tor Bug Tracker & Wiki]

#18797: create a DescriptorGenerator?
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by CurtisSalazar):

 ==  ==
 The following solution can be: The XML has to be generated easy, utilizing
 the !JavaBean contracts as well as creating an element for each and every
 property that will figure in generator. It is better to build generator on
 Java's reflection mechanisms which is where properties are the only things
 that matter here. Look, I found the code at [http://essaydune.com/ college
 essay writing services] :!

  !
 

 I hope this helps...Let me know if some troubles..

--
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] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

[Tor Bug Tracker & Wiki]

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201610R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by bugzilla):

 Replying to [comment:13 arthuredelstein]:
 It's really great to see how you've started to go step by step into the
 right direction of redesigning UI, so that it's now a real "Torbutton UI
 flow improvement"!
 > uncheck the "Custom Values" box.
 Hint: it's better to replace this checkbox with a new Security Slider
 position "Expert" above High, especially for mobile UX, which will have
 the same settings as High for the first time (so text to the right will be
 the same), and text will disappear when custom settings will have been
 made (and this position will preserve (!) custom settings while switching
 back and forth from other positions!)
 > (b) if the code changes are correct.
 It depends on whether all settings you want could be restored without
 "Restore Defaults".

--
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] #20274 [Applications/Tor Browser]: Strange loading and browsing activity on www.hitrecord.org

[Tor Bug Tracker & Wiki]

#20274: Strange loading and browsing activity on www.hitrecord.org
--+
 Reporter:  empresspyra   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by bugzilla):

 Replying to [comment:3 gk]:
 > If NoScript is forgetting permissions, please file a bug for it. This
 bug becomes unactionable otherwise.
 Tickets without STR lay for years here, so they are "unactionable" too. OP
 described the symptoms, and bugzilla added the findings what it could be.
 `noscript` was added, because ma1 could take a look at it (he wrote). But
 don't worry, bugzilla is tired to go through your minetracker and is going
 to go retired.

--
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] #20083 [Applications/Tor Browser]: `app.update.enabled` should remove updater UI elements when set to false.

[Tor Bug Tracker & Wiki]

#20083: `app.update.enabled` should remove updater UI elements when set to 
false.
---+--
 Reporter:  yawning|  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-sandboxing, tbb-usability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by bugzilla):

 Replying to [comment:4 yawning]:
 > Replying to [comment:3 bugzilla]:
 > > Replying to [ticket:20083 yawning]:
 > > > If the updater is disabled, the UI elements associated with it
 should be hidden.
 > > `app.update.enabled` is about "update", not "updater", so everything
 is fine with it.
 >
 > I don't care what the pref is called, or if it's a separate pref, env
 var, or whatever, as long as it's possible.
 You don't care about Mozilla's prefs, they don't care about your needs ;)
 > > Why do you want to disable auto-updates? Mozilla even made a
 `MozillaMaintananceService` to circumvent different "sandboxes" in order
 to update "sandboxed" browser.
 >
 > Because a sandbox that lets the sandboxed app re-write itself is
 terrible.
 Not itself: browser asks the updater, updater asks for permissions,
 service or user grant them, and updater updates sandboxed browser. (Oh,
 what you've written is even more funny: every polymorphic virus re-writes
 itself in a sandbox :)
 > > And you just want to go back to manual updates.
 >
 > No.
 Phew.
 > > Or do you have something better?
 >
 > Yes.
 Another one updater?
 > ps: *plonk*
 P.S.: cheap wine of inferior quality? ;)

--
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] #20274 [Applications/Tor Browser]: Strange loading and browsing activity on www.hitrecord.org

[Tor Bug Tracker & Wiki]

#20274: Strange loading and browsing activity on www.hitrecord.org
--+
 Reporter:  empresspyra   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  reopened => closed
 * keywords:  tbb-usability-website, noscript => tbb-usability-website
 * resolution:   => worksforme


Comment:

 Replying to [comment:2 bugzilla]:
 > The description is vague, but it's similar to what's going on sometimes
 when using TBB on Medium-High settings: after a long period of time,
 probably, NoScript "forgets" about permissions for JS and blocks
 everything on some tabs. (TBB: all, reproducible: n/a)

 If NoScript is forgetting permissions, please file a bug for it. This bug
 becomes unactionable otherwise. It is not even clear whether the user had
 Tor Browser on Medium-High.

--
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] #20083 [Applications/Tor Browser]: `app.update.enabled` should remove updater UI elements when set to false.

[Tor Bug Tracker & Wiki]

#20083: `app.update.enabled` should remove updater UI elements when set to 
false.
---+--
 Reporter:  yawning|  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-sandboxing, tbb-usability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yawning):

 Replying to [comment:3 bugzilla]:
 > Replying to [ticket:20083 yawning]:
 > > If the updater is disabled, the UI elements associated with it should
 be hidden.
 > `app.update.enabled` is about "update", not "updater", so everything is
 fine with it.

 I don't care what the pref is called, or if it's a separate pref, env var,
 or whatever, as long as it's possible.

 > Why do you want to disable auto-updates? Mozilla even made a
 `MozillaMaintananceService` to circumvent different "sandboxes" in order
 to update "sandboxed" browser.

 Because a sandbox that lets the sandboxed app re-write itself is terrible.

 > And you just want to go back to manual updates.

 No.

 > Or do you have something better?

 Yes.

 ps: *plonk*

--
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] #20274 [Applications/Tor Browser]: Strange loading and browsing activity on www.hitrecord.org

[Tor Bug Tracker & Wiki]

#20274: Strange loading and browsing activity on www.hitrecord.org
-+--
 Reporter:  empresspyra  |  Owner:
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, noscript  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by bugzilla):

 * status:  closed => reopened
 * keywords:  tbb-usability-website => tbb-usability-website, noscript
 * resolution:  worksforme =>


Comment:

 The description is vague, but it's similar to what's going on sometimes
 when using TBB on Medium-High settings: after a long period of time,
 probably, NoScript "forgets" about permissions for JS and blocks
 everything on some tabs. (TBB: all, reproducible: n/a)

--
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] #20083 [Applications/Tor Browser]: `app.update.enabled` should remove updater UI elements when set to false.

[Tor Bug Tracker & Wiki]

#20083: `app.update.enabled` should remove updater UI elements when set to 
false.
---+--
 Reporter:  yawning|  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-sandboxing, tbb-usability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by bugzilla):

 * keywords:  tbb-sandboxing => tbb-sandboxing, tbb-usability


Comment:

 Replying to [ticket:20083 yawning]:
 > If the updater is disabled, the UI elements associated with it should be
 hidden.
 `app.update.enabled` is about "update", not "updater", so everything is
 fine with it.
 Why do you want to disable auto-updates? Mozilla even made a
 `MozillaMaintananceService` to circumvent different "sandboxes" in order
 to update "sandboxed" browser. And you just want to go back to manual
 updates. Or do you have something better?

--
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] #20308 [Applications/Tor Browser]: TOR Browser crashes and dumps its core into my logs

[Tor Bug Tracker & Wiki]

#20308: TOR Browser crashes and dumps its core into my logs
--+--
 Reporter:  LtL0zF48kDJaGn3aYg6LTLXGaCPnLUVv  |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:   => tbb-team
 * status:  needs_information => assigned


--
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] #20308 [Applications/Tor Browser]: TOR Browser crashes and dumps its core into my logs

[Tor Bug Tracker & Wiki]

#20308: TOR Browser crashes and dumps its core into my logs
--+
 Reporter:  LtL0zF48kDJaGn3aYg6LTLXGaCPnLUVv  |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  assigned => needs_information


--
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] #20308 [Applications/Tor Browser]: TOR Browser crashes and dumps its core into my logs

[Tor Bug Tracker & Wiki]

#20308: TOR Browser crashes and dumps its core into my logs
--+
 Reporter:  LtL0zF48kDJaGn3aYg6LTLXGaCPnLUVv  |  Owner:
 Type:  defect| Status:
  |  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * priority:  Medium => High
 * keywords:  TOR Browser crash coredump dum systemd-coredump => tbb-crash
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Browser
 * version:  Tor: unspecified =>


Comment:

 Is this reproducible? If so, how? Which Tor Browser are 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] #20300 [Applications/Tor Browser]: Unable to launch Tor browser

[Tor Bug Tracker & Wiki]

#20300: Unable to launch Tor browser
--+
 Reporter:  grobin|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  needs_information => closed
 * resolution:   => worksforme


Comment:

 I guess this is fixed.

--
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] #20299 [Applications/Tor Browser]: Tried to update now tor wont start

[Tor Bug Tracker & Wiki]

#20299: Tried to update now tor wont start
--+---
 Reporter:  lfresh|  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * cc: mcs, brade (added)


Comment:

 Replying to [comment:2 lfresh]:
 > Unfortunately i'm not certain what the previous version was i downloaded
 in July if that helps.
 >
 > I use OS El Capitan

 Where do you have Tor Browser installed? In your /Applications directory?
 If so can you make a copy of your `TorBrowser-Data` folder (you can find
 it with the help shown in comment:8:ticket:20300) for further
 inspection/bookmark backups? If you have done so, removing that folder
 while Tor Browser is shut down and restarting it might solve your issue.
 It would probably be super helpful if you could follow the steps in
 comment:11:ticket:20300 and report that output back. We see at a glance
 what is wrong with your Tor Browser then.

--
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] #20310 [Applications/Tor Browser]: Requests for certificates in Certificate Viewer are sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#20310: Requests for certificates in Certificate Viewer are sent over the 
catch-all
circuit
--+-
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-linkability
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Each request made to fetch a certificate in a certificate chain is sent
 over the catch-all circuit.
 {{{
 Torbutton INFO: tor SOCKS isolation catchall:
 http://ocsp.int-x3.letsencrypt.org/ via --unknown--:88
 }}}

--
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] #15569 [Applications/Tor Browser]: Web Notification API icons get no first party

[Tor Bug Tracker & Wiki]

#15569: Web Notification API icons get no first party
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Good ticket to add to Mozilla's first-party isolation tickets.
 {{{
 Torbutton INFO: tor SOCKS: https://www.torproject.org/images/onion.jpg via
 --NoFirstPartyHost-chrome-alert.xul--:0
 Torbutton INFO: tor SOCKS: http://ocsp.digicert.com/ via
 --nofirstpartyhost-chrome-alert.xul--:0
 }}}

--
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