Re: [tor-bugs] #21418 [Applications/Tor Browser]: New Tor Browser http response header, for high security websites

[Tor Bug Tracker & Wiki]

#21418: New Tor Browser http response header, for high security websites
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by micahlee):

 Tom, that's a very good point about how after the attacker hacks a web
 server they can change the response headers.

 It seems like, to accomplish this for SecureDrop servers, Tor Browser
 would have to bundle some sort of Tor-High-Security preload list of
 domains, similar to the HSTS preload list. And, of course, start
 maintaining that list.

--
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] #21436 [Obfuscation/FTE]: fteproxy does not work on Debian stretch / document fteproxy usage on Debian stretch

[Tor Bug Tracker & Wiki]

#21436: fteproxy does not work on Debian stretch / document fteproxy usage on
Debian stretch
-+
 Reporter:  adrelanos|  Owner:  kpdyer
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Using fteproxy on Debian stretch isn't straight easy. So far no luck.

 From {{{/lib/systemd/system/tor@default.service}}}, the AppArmor profile
 gets into the way.

 {{{
 AppArmorProfile=system_tor
 }}}

 Also the other systemd hardening results in.

 > {{{Could not launch managed proxy executable at '/usr/bin/fteproxy'
 ('Permission denied').}}}

 {{{
 NoNewPrivileges=yes
 PrivateTmp=yes
 PrivateDevices=yes
 ProtectHome=yes
 ProtectSystem=full
 ReadOnlyDirectories=/
 ReadWriteDirectories=-/proc
 ReadWriteDirectories=-/var/lib/tor
 ReadWriteDirectories=-/var/log/tor
 ReadWriteDirectories=-/var/run
 CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
 CAP_DAC_OVERRIDE
 }}}

 Even with all of that disabled, Tor does not successfully bootstrap.

 {{{
 Feb 11 06:26:01.000 [notice] Bootstrapped 5%: Connecting to directory
 server
 Feb 11 06:26:01.000 [notice] Bootstrapped 10%: Finishing handshake with
 directory server
 Feb 11 06:26:01.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing
 handshake with directory server. (DONE; DONE; count 6; recommendation
 warn; host redacted at IP:PORT)
 Feb 11 06:26:01.000 [warn] 6 connections have failed:
 }}}

 I guess my torrc config is fine. Copied that part over from TBB to system
 Tor /etc/tor/torrc.

 {{{
 UseBridges 1
 ClientTransportPlugin fte exec /usr/bin/fteproxy --managed
 Bridge fte IP:PORT redacted
 }}}

 Any hints what I am doing wrong? (Not in a censored area. TBB without
 bridges as well as fteproxy works for me. Debian stretch system Tor with
 Debian fteproxy packages does not work for me.)

 I am asking for Whonix integration purposes.

--
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] #13790 [Core Tor/Tor]: Refactor and add comments to new_route_len()

[Tor Bug Tracker & Wiki]

#13790: Refactor and add comments to new_route_len()
-+-
 Reporter:  dgoulet  |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  026-deferrable,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:12 dgoulet]:
 > I'm not aware of security risk of having long circuits like that but it
 definitely is very bad on the user experience and overall load of the
 network.

 For posterity: there actually is a subtle anonymity risk that using a
 longer-than-needed path can introduce. Let's say we have a choice between
 using 3-hop circuits in Tor and using 6-hop circuits in Tor, and we have
 an adversary who runs some relays and tries to learn what destinations
 each user goes to.

 For illustration, let's assume we don't use the entry guard design. The
 adversary's strategy is "if any of your relays are on a circuit, but you
 don't own the first and last relay on that circuit, then fail the circuit
 (and hope they try building a new one)." In just a passive attack, an
 adversary who runs 10% of the network has a .1*.1=0.01 chance of being
 able to learn your destinations, but with this strategy, it's better than
 .01 -- and the longer the path length, the more likely the adversary is to
 be in a position to tear down circuits he can't beat, so the bigger the
 success rate gets.

 See https://www.freehaven.net/anonbib/#ccs07-doa for details.

 Now, the entry guard design complicates the attack, because no matter how
 many times the attacker tears down the circuit, the user isn't going to
 budge from their guard. Maybe entry guards resolve the attack entirely,
 because either the attacker doesn't own the guard and they can't win, or
 they do own the guard, and then they're on the circuit no matter how many
 hops the circuit has?

 Actually, maybe using *one* entry guard resolves the attack, because if
 you have say three guards, then the attack still works, it's just much
 more limited? (If the attacker controls some but not all of your guards,
 then he can do the attack to shift your circuits more onto the guards he
 controls.)

 In any case, there's your potential anonymity implication to longer
 circuits. So it isn't *just* higher latency for users and more load on the
 network that makes us want to avoid them.

--
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] #21435 [Applications/Tor Browser]: Couldn't Load XPCOM tor 6.5

[Tor Bug Tracker & Wiki]

#21435: Couldn't Load XPCOM tor 6.5
--+--
 Reporter:  arron76   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arron76):

 I should add that I did disable AVG and also added tor to the exceptions
 list also in an attempt to resolve the 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] #21435 [Applications/Tor Browser]: Couldn't Load XPCOM tor 6.5

[Tor Bug Tracker & Wiki]

#21435: Couldn't Load XPCOM tor 6.5
--+--
 Reporter:  arron76   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I have windows ultimate 7 sp-1 tor has worked fine for months. Today it
 would not start and I have the Couldn't Load XPCOM error. I reverted back
 to 6.0.8, but still have the error. I am running AVG Fee edition and no
 other anti virus or spyware software.
 I recently set up a laptop with the exact same operating system and tor
 browser and it runs fine. Is there a particular file missing with this
 error? Oh yes I also installed the latest version of firefox and it runs
 fine.

--
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] #21206 [Core Tor/Tor]: Measure client up/down bandwidth for directory requests, split by type

[Tor Bug Tracker & Wiki]

#21206: Measure client up/down bandwidth for directory requests, split by type
--+
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:  #21205| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  merge_ready => needs_revision


Comment:

 Landed some changes to my branch that hasn't been reviewed yet. Changing
 to 'needs revision' before asking for another 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

Re: [tor-bugs] #19711 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )

[Tor Bug Tracker & Wiki]

#19711: circuit_package_relay_cell(): Bug: outgoing relay cell sent from
src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
-+-
 Reporter:  user100500   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, 029-backport, triage-  |  Actual Points:
  out-030-201612 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alecmuffett):

 I am hearing of this at a large installation. +subscribe

--
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] #18364 [Applications/Tor Browser]: Tor Browser in Gnu+Linux doesn't support Dingbats properly

[Tor Bug Tracker & Wiki]

#18364: Tor Browser in Gnu+Linux doesn't support Dingbats properly
--+--
 Reporter:  erchewin  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-fonts  |  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+--

Comment (by vegansalad):

 Can someone please respond to this ticket? Trac.torproject.org is broken.
 uBlock is broken. MANY SITES on the internet are broken. We really should
 talk about 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] #21414 [Metrics]: Should metrics web sites (metrics.tp.o, collector.tp.o, onionoo.tp.o) display currently running software version?

[Tor Bug Tracker & Wiki]

#21414: Should metrics web sites (metrics.tp.o, collector.tp.o, onionoo.tp.o)
display currently running software version?
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Yes, a footer with version is fine.

 Another topic:  shouldn't there be the word "mirror" somewhere to
 distinguish systems operated by other from the main Tor instances?

--
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] #21381 [Metrics/CollecTor]: CollecTor web-page should have new Metrics design

[Tor Bug Tracker & Wiki]

#21381: CollecTor web-page should have new Metrics design
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Joining the party a bit late here.  Nice prototype you have there!  That's
 already pretty close, I'd say.  Some suggestions and thoughts:

  - How about we take out the nav bar at the top and use a single side nav
 box with anchors for the entire page?  The main reason for taking out the
 nav bar is that we could keep that navigational element for navigating
 between pages as a consistent element on metrics-related pages.  And if a
 page consists only of a single, long page, then there's no need for a nav
 bar and we use a nav box instead.

  - Another advantage of not using a nav bar is that it will be easier to
 add new sections, without having to hunt for new icons.  (I'm also
 thinking of the other metrics-related sites here.)

  - Compared to the current side nav box, the box I have in mind would need
 two, or better three hierarchy levels, like:
- Available Descriptors
- Data Formats
  - Tor Relay Descriptors
- Relay Server Descriptors
- Relay Extra-info Descriptors
- ...

  - If possible, the text should float around the side nav box, so that it
 only reduces horizontal space on the first screen or so, not on the
 screens further down below.  No idea what CSS tricks that requires, if
 any.

  - Unrelated to navigation, I think we'll need to put a link to Tor
 Metrics somewhere as well as a link to the Tor website.  The latter also
 applies to the Tor Metrics website which still lacks a link to the Tor
 website.

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

Re: [tor-bugs] #21414 [Metrics]: Should metrics web sites (metrics.tp.o, collector.tp.o, onionoo.tp.o) display currently running software version?

[Tor Bug Tracker & Wiki]

#21414: Should metrics web sites (metrics.tp.o, collector.tp.o, onionoo.tp.o)
display currently running software version?
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I like the idea!  How about we place some version string in the page
 footer, in a way that doesn't look to awkward and technical to users?

--
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] #21419 [Metrics/Metrics website]: avoid spurious downturns and 'spamming' of top-10-censorship list

[Tor Bug Tracker & Wiki]

#21419: avoid spurious downturns and 'spamming' of top-10-censorship list
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Oh, very good catch!  Your fix above only removes false dots from graphs,
 but it doesn't reduce false table entries which is done in
 `website/rserve/tables.R`.  I extended your patch, cherry-picked it,
 merged it to master, and deployed it.  Closing.  Thanks!

--
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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

[Tor Bug Tracker & Wiki]

#21431: Clean-up system extensions shipped in Firefox 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by brade):

 Replying to [comment:1 gk]:
 > mcs, brade could you work on that ticket? The extensions highlighted in
 the description might even need updater related changes.

 Yes, we will take a look.

--
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] #21183 [User Experience]: Basic Usability Issues

[Tor Bug Tracker & Wiki]

#21183: Basic Usability Issues
+-
 Reporter:  ninavizz|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  User Experience |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX, UI, torbrowser  |  Actual Points:
Parent ID:  #20843  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by i139):

 * cc: i139 (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

[tor-bugs] #21434 [Metrics/Atlas]: Graphs overflow into their right border on smaller screens

[Tor Bug Tracker & Wiki]

#21434: Graphs overflow into their right border on smaller screens
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Currently the graphs use the span8 class which causes them to keep 4
 columns of distance from the right (because the entire width is divided
 into 12 columns). On smaller screens this causes the graphs to overflow
 into their borders.

 Using the span8 class makes it so graphs will always be underneath each
 other. Keeping this layout and solving the overflow issue is easy by just
 using the span12 class. This makes the graphs (and their borders) use the
 entire screen width.

--
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] #21433 [Applications/TorBirdy]: TorBirdy: Respect user preferences for header_type and message body type

[Tor Bug Tracker & Wiki]

#21433: TorBirdy: Respect user preferences for header_type and message body type
---+-
 Reporter:  jflory7|  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 = Summary =

 Whenever Thunderbird restarts, TorBirdy resets the values for header_type
 and what type format to view emails, irrespective of user preference.

 = Description =

 Something I noticed quickly after using TorBirdy is that it changes two
 settings forcibly whenever Thunderbird starts. The two settings I always
 change back after Thunderbird restarts are:

 * ''View > Message Body As… > Original HTML'': While I am aware there are
 potential security risks by enabling this, I prefer to view emails with
 the original HTML and subjectively choose to change this setting for a
 specific email as needed.
 * ''mailnews.reply_header_type'': After restarting, the value is adjusted
 to **1** from the default, **2**. I prefer to have the full reply header
 type when I reply to emails.

 While I respect the reasons the TorBirdy developers have for changing
 these settings, it's annoying for me as the user to have my preferences
 overruled every time Thunderbird restarts, and then I have to go and
 change this manually every time it restarts.

 = Implementation =

 1. Start Thunderbird
 2. User changes settings from default TorBirdy configuration, e.g. message
 body type and reply_header_type
 3. User closes Thunderbird
 4. User restarts Thunderbird, adjustments to settings preserved

--
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] #21240 [Applications/Tor Browser]: Create patches to fix mingw-w64 compilation of Firefox ESR 52

[Tor Bug Tracker & Wiki]

#21240: Create patches to fix mingw-w64 compilation of Firefox ESR 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  #21147  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by gk):

 Okay, here comes the accessibility related patch. we'll need an additional
 gitian patch if we don't want to ship the binary .tlb blob that is in the
 tree.

--
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] #21432 [Applications/Tor Browser]: Make a plan on how to deploy e10s in Tor Browser

[Tor Bug Tracker & Wiki]

#21432: Make a plan on how to deploy e10s in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff52-esr,
 Severity:  Normal   |  TorBrowserTeam201702
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Our current goal is to make Tor Browser based on ESR 52 ready for content
 sandboxing (e10s). While the work is done in different bugs we need to
 create a plan on how we want to deploy it. For that we need to investigate
 first how Mozilla is shipping it in Firefox 52 ESR. E.g. there is a system
 extension `e10srollout` and there is an e10s allow list and probably some
 other means that are regulating which users are getting which experience
 (i.e. having e10s and non-e10s) activated (Things like
 https://bugzilla.mozilla.org/show_bug.cgi?id=1329695 make me quite
 cautious).

 Once we know how this is going to work (mike conley had an idea in:
 https://groups.google.com/forum/#!topic/mozilla.dev.platform/TWE4VEbJOmM
 not sure if that's the final word or where we can find out more
 information) we can think about how we want to have it work in Tor Browser
 to have a stable yet more secure browsing experience.

--
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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

[Tor Bug Tracker & Wiki]

#21431: Clean-up system extensions shipped in Firefox 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 mcs, brade could you work on that ticket? The extensions highlighted in
 the description might even need updater related changes.

--
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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

[Tor Bug Tracker & Wiki]

#21431: Clean-up system extensions shipped in Firefox 52
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff52-esr,
 Severity:  Normal   |  TorBrowserTeam201702
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In addition to `pdfjs` there are 6 system add-ons shipped in Firefox 52
 looking at the current beta branch. (on `release` there are 5 right now).
 We should investigate whether we need all of them and if not make sure
 that they don't interfere with Tor Browser.

 Of particular interest are `aushelper` and `e10srollout` I guess.

--
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] #21396 [Applications/Tor Browser]: Torbutton breaks Session Manager addon

[Tor Bug Tracker & Wiki]

#21396: Torbutton breaks Session Manager addon
-+-
 Reporter:  HolD |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-6.5-regression,  |  Actual Points:
  TorBrowserTeam201702, GeorgKoppen201702|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Replying to [comment:9 gk]:
 > `moz-nullprincipal:{1f22744b-c4db-41b6-8d6e-3d06c176578e}`. Looking at
 the docs it seems like checking for that one would be okay. But this is
 not a solution that scales well. I wonder if we should just add a
 preference `extensions.torbutton_resource_and_chrome_uri_fingerprinting`
 and set that to `false` by default allowing users to override it and to
 disable the content policy hack. Maybe UX folks have an idea.

 An alternative approach would be to have a pref that changes the CSP
 behavior from being whitelist based to blacklist based so that it will
 still defend against say... loading torbutton resources.  The current
 behavior is more robust and more resilient against this particular
 fingerprinting method (since it protects all resources), so it should be
 the default regardless of how the actual pref ends up being implemented.

 Installing extra addons never has been something considered safe, or part
 of Tor Browser's threat model as far as I am aware, and people that chose
 to do so should be doing it with the understanding that it may open them
 up to various fingerprinting attacks.

 The real fix would be for upstream Firefox to plug the chrome/resource URI
 scheme issues correctly, naturally.

--
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] #21430 [Metrics/Atlas]: Graphs have empty paths when bandwidth data is unavailable

[Tor Bug Tracker & Wiki]

#21430: Graphs have empty paths when bandwidth data is unavailable
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #21274
   Points: |   Reviewer:
  Sponsor: |
---+
 For some relays Onionoo does not have bandwidth data for all time periods.
 For instance
 
[https://onionoo.torproject.org/bandwidth?lookup=B743BE28571D87AEFF9C409756644DB5C64A7C45
 B743BE28571D87AEFF9C409756644DB5C64A7C45] is missing its 5 years data.

 When data is unavailable the graphs are empty except for the legend.
 However the path elements are still created leading to W3C validator
 errors such as

 {{{
 Element path is missing required attribute d.
 }}}

 FWICT this issue was partially addressed by #19553 but was solved by
 removing more recent graphs instead of having Atlas detect and handle
 unavailable data.

--
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] #21429 [Metrics/Atlas]: Remove line breaks in graph data URIs

[Tor Bug Tracker & Wiki]

#21429: Remove line breaks in graph data URIs
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21274 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * status:  new => 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

Re: [tor-bugs] #21352 [Metrics/Atlas]: Legends in graphs seem to upset the W3C validator

[Tor Bug Tracker & Wiki]

#21352: Legends in graphs seem to upset the W3C validator
---+--
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21274 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * status:  new => needs_review


Comment:

 I've attached a patch that removes the aforementioned attributes.

--
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] #21429 [Metrics/Atlas]: Remove line breaks in graph data URIs

[Tor Bug Tracker & Wiki]

#21429: Remove line breaks in graph data URIs
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #21274
   Points: |   Reviewer:
  Sponsor: |
---+
 On the details page each `Save Graph` links to a data URI with a line
 break which is a bad value according to the W3C validator.

--
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] #21428 [Metrics/Atlas]: Move the styling of the graphs into a stylesheet

[Tor Bug Tracker & Wiki]

#21428: Move the styling of the graphs into a stylesheet
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 While working on #21352 I've noticed the styling of the graphs is injected
 with JavaScript. The `plot` function uses the `style` function on almost
 every graph element. IMO it would be better to separate the styling into a
 stylesheet and assigns classes to the SVG elements.

--
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] #21376 [Metrics]: add javadoc metrics style

[Tor Bug Tracker & Wiki]

#21376: add javadoc metrics style
-+--
 Reporter:  iwakeh   |  Owner:  RaBe
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => assigned
 * owner:  metrics-team => RaBe


Comment:

 RaBe, can you comment on the fonts question above?

--
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] #21352 [Metrics/Atlas]: Legends in graphs seem to upset the W3C validator

[Tor Bug Tracker & Wiki]

#21352: Legends in graphs seem to upset the W3C validator
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21274 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 This is a bug in Atlas. The [https://developer.mozilla.org/en-
 US/docs/Web/SVG/Element/g MDN documentation] of the `` tag doesn't
 indicate the `y` or `x` attributes are okay to use. Removing the
 attributes shows no difference.

 The validator also complains about the `height` and `width` attributes on
 the `text` tag. Once again the [https://developer.mozilla.org/en-
 US/docs/Web/SVG/Element/text MDN documentation] doesn't indicate these are
 okay to use and show no difference when removed.

 Patch is coming after some more testing.

--
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] #21412 [Metrics/Atlas]: Atlas incorrectly reporting MyFamily

[Tor Bug Tracker & Wiki]

#21412: Atlas incorrectly reporting MyFamily
---+---
 Reporter:  saint  |  Owner:  irl
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Minor  | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 I didn't look at the relay in question, but from the conversation above it
 seems like there's no bug in Atlas.  Please re-open if there is.

--
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] #21267 [Applications/Tor Browser]: e10s compatibility for Torbutton's content sizer

[Tor Bug Tracker & Wiki]

#21267: e10s compatibility for Torbutton's content sizer
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,ff52-esr,  |  Actual Points:
  TorBrowserTeam201702   |
Parent ID:  #21201   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Before we start spending a ton of work on a feature that is currently only
 in our alpha series (and there are no immediate plans to get it into
 stable shape): what about just backing it out for now? There have issues
 piled up in #14429 which we have not fixed which means we ship code in the
 alpha that is not even close to be stable code and it makes it harder
 branching off maintenance branches for the stable series: we need to
 always back out the feature or flip at least the preference accordingly.
 And: we want to have a fix for the underlying problem behind a pref in
 Firefox directly anyway.

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