Tor Bug Tracker & Wiki: Ticket Queryhttps://trac.torproject.org/projects/tor/query?status=!closed&reporter=arthuredelstein&order=priority
The Tor Project: anonymity onlineen-USTor Bug Tracker & Wiki/images/tor-logo.pnghttps://trac.torproject.org/projects/tor/query?status=!closed&reporter=arthuredelstein&order=priority
Trac 1.2https://trac.torproject.org/projects/tor/ticket/15563
https://trac.torproject.org/projects/tor/ticket/15563#15563: ServiceWorkers violate first party isolation, probablyThu, 02 Apr 2015 21:58:52 GMTarthuredelstein<p>
I haven't looked at ServiceWorkers (starting Firefox 33) closely, but I think they likely violate first party isolation. A brief look at some code in mozilla-central suggests that we may be able to use the same code to isolate SharedWorkers and ServiceWorkers by first party domain.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/15563#changeloghttps://trac.torproject.org/projects/tor/ticket/21762
https://trac.torproject.org/projects/tor/ticket/21762#21762: Check new Firefox favicon code for first-party isolationFri, 17 Mar 2017 00:15:45 GMTarthuredelstein<p>
mcs and brade noticed some new favicon patches in Firefox that we should check for first-party isolation, and patch if FPI is violated:
</p>
<blockquote>
<p>
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=530999"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=530999</a>
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1184739"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1184739</a>
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1206560"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1206560</a>
</p>
</blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/21762#changeloghttps://trac.torproject.org/projects/tor/ticket/23424
https://trac.torproject.org/projects/tor/ticket/23424#23424: Stop exposing the moz-icon URL scheme to the webThu, 07 Sep 2017 00:40:59 GMTarthuredelstein<p>
We should do this if Mozilla doesn't get to it.
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1222924"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1222924</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23424#changeloghttps://trac.torproject.org/projects/tor/ticket/12740
https://trac.torproject.org/projects/tor/ticket/12740#12740: TorButton menu items should be clearer in the UIWed, 30 Jul 2014 05:01:27 GMTarthuredelstein<p>
Points from AdamShostack regarding TorButton
</p>
<blockquote class="citation">
<ol start="2"><li>What does "cookie protection" do?
</li><li>Are those "Torbutton preferences..." or something else? (Same question for "network settings"..is that computer network settings or torbutton settings; in fact, if torbutton network settings, maybe combine network &amp; preferences?)
</li></ol></blockquote>
<p>
Each of these menu items could use a tooltip explaining its purpose. In addition, it does seem that network settings and preferences could be combined. Also, I would propose merging "About TorButton" and "About TorBrowser" somehow.
</p>
<p>
The cookie preferences window, at least on Mac, looks weird and doesn't have a title bar.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/12740#changeloghttps://trac.torproject.org/projects/tor/ticket/12999
https://trac.torproject.org/projects/tor/ticket/12999#12999: Use one clock skew per URL bar domainFri, 29 Aug 2014 23:22:44 GMTarthuredelstein<p>
When <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3455" title="#3455: enhancement: Tor Browser should set SOCKS username for a request based on first ... (closed: fixed)">#3455</a> lands, Tor Browser will have a separate Identity (i.e., circuit) for each URL bar domain. JavaScript clock skew fingerprinting is one way attackers can try to link Identities. Tor Browser could counter this by maintaining a separate clock skew for each URL bar domain.
</p>
<p>
When the user browses to a new URL bar domain, Tor Browser would
</p>
<ol><li>Create a new circuit
</li><li>Request clock time from exit node (already tied to Identity)
</li><li>Store clock skew in a one-to-one mapping of skews-&gt;URL bar domains
</li><li>Apply clock skew to any JS clock requests under that domain
</li></ol>Resultshttps://trac.torproject.org/projects/tor/ticket/12999#changeloghttps://trac.torproject.org/projects/tor/ticket/13012
https://trac.torproject.org/projects/tor/ticket/13012#13012: Reviewing Bug #3229: Make content pref service memory-only + clearableMon, 01 Sep 2014 06:12:17 GMTarthuredelstein<p>
I noticed that nsContentPrefService.js can be expected to store prefs in memory, providing that any provided "loading context" has "usePrivateBrowsing" set to true, an assumption that may or may not hold for Firefox's Private Browsing (PB) mode. The patch for <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3229" title="#3229: defect: Make content pref service memory-only + clearable (closed: fixed)">#3229</a> in addition applies to non-PB mode. Since Tor Browser uses PB mode by default, it's not entirely clear whether or not <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3229" title="#3229: defect: Make content pref service memory-only + clearable (closed: fixed)">#3229</a> is needed.
</p>
<p>
To complicate matters, nsContentPrefService.js has been deprecated in favor of <a class="ext-link" href="http://dxr.mozilla.org/mozilla-central/source/toolkit/components/contentprefs/ContentPrefService2.jsm"><span class="icon">​</span>ContentPrefService2.jsm</a>, at least in ESR31. In this new implementation, it looks like PB mode will also use an in-memory store, provided we make the same possibly dangerous assumption that loading contexts will always have "usePrivateBrowsing" set to true.
</p>
<p>
So my question is: should we drop the <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3229" title="#3229: defect: Make content pref service memory-only + clearable (closed: fixed)">#3229</a> patch (assuming Firefox gets the loading contexts right), or should we be extra defensive and write a similar patch to apply to ContentPrefService2.jsm? Perhaps Mike has some insight here.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/13012#changeloghttps://trac.torproject.org/projects/tor/ticket/13198
https://trac.torproject.org/projects/tor/ticket/13198#13198: clean up torbutton use of Mozilla servicesSat, 20 Sep 2014 00:15:26 GMTarthuredelstein<p>
Most of the invocations to <code>Cc...getService</code> in the torbutton JS code are unnecessary. Writing a patch to clean it up.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/13198#changeloghttps://trac.torproject.org/projects/tor/ticket/13236
https://trac.torproject.org/projects/tor/ticket/13236#13236: investigate Firefox SSL for things that might allow user trackingWed, 24 Sep 2014 22:52:51 GMTarthuredelstein<p>
From a <a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=967977#c8"><span class="icon">​</span>comment by Patrick McManus</a>:
</p>
<blockquote class="citation">
<p>
(In reply to David Keeler (:keeler) [use needinfo?] from comment <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5" title="#5: defect: Can't start new server-- get fatal exception while configuring server (closed: Fixed)">#5</a>)
</p>
<blockquote class="citation">
<p>
mcmanus, are there other TLS features that are enabled by default that would
allow tracking users? (The aim of this bug is to add an option that would
prevent that sort of thing.)
</p>
</blockquote>
<p>
sure - at various levels of granularity. None as extreme as session tickets.
Anything that keeps state, right?
</p>
<p>
some that come to mind:
</p>
<ul><li>the version intolerance cache
</li><li>our false start behavior involves "have I seen this algorithm before"
</li><li>the hsts database
</li></ul></blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/13236#changeloghttps://trac.torproject.org/projects/tor/ticket/13669
https://trac.torproject.org/projects/tor/ticket/13669#13669: disable "retry DNS on new circuit" for web contentWed, 05 Nov 2014 04:48:14 GMTarthuredelstein<p>
From mikeperry's comment on <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5752#comment:7" title="#5752: project: Isolate browser streams by url bar domain rather than by time interval (closed: fixed)">ticket:5752#comment:7</a>
</p>
<blockquote class="citation">
<p>
isis just noted in #tor-dev that Tor retries failed DNS queries on other circuits. It appears that we do this for failed stream attempts too. I agree that's a bad property because it allows a web adversary to cause your browser to keep making new circuits until you pick one that uses its middle node.
</p>
<p>
We should ensure we disable this "retry on new circuit" behavior for content elements of a given URL bar, so that at least content elements don't get to cause you to create tons of circuits. Once a circuit can load a top-level url correctly, it should be considered reliable enough not to abandon if a DNS or other stream times out. This might actually require a new Tor child ticket and patch, though...
</p>
<p>
It's not clear what (if anything) we should change about the initial URL bar load behavior, though. Perhaps it is safe to remain unchanged, because Tor would at least rate limit that properly before failing the page load.
</p>
</blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/13669#changeloghttps://trac.torproject.org/projects/tor/ticket/14429
https://trac.torproject.org/projects/tor/ticket/14429#14429: Automated rounding of content window dimensionsWed, 28 Jan 2015 05:55:11 GMTarthuredelstein<p>
I've written a small patch for torbutton that forces the content ("gBrowser") to have dimensions be a multiple of 200x200. In other words, window.innerWidth and window.innerHeight, and similar calls, always return a rounded number.
</p>
<p>
This should at least provide some protection to users who resize or maximize their Tor Browser window with JS activated.
</p>
<p>
I haven't dealt with the zooming issue here, but that would be an interesting next step.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/14429#changeloghttps://trac.torproject.org/projects/tor/ticket/14633
https://trac.torproject.org/projects/tor/ticket/14633#14633: Default NoScript settings says "Allow Scripts Globally" is "dangerous"Sun, 01 Feb 2015 22:27:58 GMTarthuredelstein<p>
This is confusing to users, as observed in the UX sprint. Should we change the message here? On the other hand, JavaScript is dangerous!
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/14633#changeloghttps://trac.torproject.org/projects/tor/ticket/14936
https://trac.torproject.org/projects/tor/ticket/14936#14936: about:license should show be adapted for Tor BrowserWed, 18 Feb 2015 07:13:17 GMTarthuredelstein<p>
Right now it is unchanged from the Mozilla Firefox version
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/14936#changeloghttps://trac.torproject.org/projects/tor/ticket/14939
https://trac.torproject.org/projects/tor/ticket/14939#14939: Support ipv6 addresses in Tor Circuit DIsplayWed, 18 Feb 2015 08:15:46 GMTarthuredelstein<p>
Bridges and other nodes may have ipv6 addresses, and we need to fix the tor circuit display so that it handles these correctly.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/14939#changeloghttps://trac.torproject.org/projects/tor/ticket/15239
https://trac.torproject.org/projects/tor/ticket/15239#15239: Add hyperlinks in tor circuit display to show "more info" about relaysWed, 11 Mar 2015 21:19:25 GMTarthuredelstein<p>
Adapted from ticket <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/15169" title="#15169: defect: Window with circuit information is too small (closed: fixed)">#15169</a>:
</p>
<p>
I'm considering the idea of turning the IP address for each relay in the circuit display into a hyperlink that when clicked, opens a tab in the browser showing more information about that relay. Alternatives include:
</p>
<ol><li> Showing the atlas.torproject.org page or globe.torproject.org page for that relay. Of course, this might have privacy implications, so perhaps only the exit node IP address should be shown/hyperlinked? Both atlas and globe require JavaScript, so it can be awkward if content JavaScript is disabled in Tor Browser.
</li></ol><ol start="2"><li>Extract the relay information from the control port and display it in a locally-generated tab. This would avoid requiring content JS, but would lack the pretty graphs of atlas and globe. Mike points out that if we were going to display our locally-generated tab in Tor Browser, we would need to sanitize any descriptor text to avoid XSS attacks. I see there is an ​HTML sanitizer utility built into Firefox.
</li></ol>Resultshttps://trac.torproject.org/projects/tor/ticket/15239#changeloghttps://trac.torproject.org/projects/tor/ticket/15299
https://trac.torproject.org/projects/tor/ticket/15299#15299: Regression tests for #5926 patchMon, 16 Mar 2015 16:51:36 GMTarthuredelstein<p>
This regression test should cover all problems reported in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5926" title="#5926: defect: language info leaked by JS Date methods in Windows and Linux (closed: duplicate)">#5926</a>, <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10284" title="#10284: defect: Locale-dependent JS methods may leak language info to content window (closed: duplicate)">#10284</a>, and <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13019" title="#13019: defect: New locale fingerprinting capabilities in FF31ESR (closed: fixed)">#13019</a>.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/15299#changeloghttps://trac.torproject.org/projects/tor/ticket/15473
https://trac.torproject.org/projects/tor/ticket/15473#15473: JS Date object reveals OS typeThu, 26 Mar 2015 18:14:31 GMTarthuredelstein<p>
Calls like new Date().toLocaleFormat() produce different Date formatting, depending on the platform.
</p>
<p>
Results from mcs, calling <code>[new Date().toLocaleFormat(), new Date().toLocaleString()]</code>:
</p>
<blockquote class="citation">
<p>
Ubuntu:
<code>Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ]</code>
OSX:
<code>Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ]</code>
Windows 7:
<code>Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]</code>
</p>
</blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/15473#changeloghttps://trac.torproject.org/projects/tor/ticket/15474
https://trac.torproject.org/projects/tor/ticket/15474#15474: Quantize innerWidth/Height when pages are zoomedThu, 26 Mar 2015 21:02:37 GMTarthuredelstein<p>
Follow up to <a class="needs_revision ticket" href="https://trac.torproject.org/projects/tor/ticket/14429" title="#14429: defect: Automated rounding of content window dimensions (needs_revision)">#14429</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/15474#changeloghttps://trac.torproject.org/projects/tor/ticket/15569
https://trac.torproject.org/projects/tor/ticket/15569#15569: Web Notification API icons get no first partyFri, 03 Apr 2015 05:14:54 GMTarthuredelstein<p>
See this demo:
<a class="ext-link" href="https://arthuredelstein.github.io/tordemos/web-notification-demo.html"><span class="icon">​</span>https://arthuredelstein.github.io/tordemos/web-notification-demo.html</a>
</p>
<p>
This seems like a fairly minor issue given that users have to give their permission to show notifications.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/15569#changeloghttps://trac.torproject.org/projects/tor/ticket/15943
https://trac.torproject.org/projects/tor/ticket/15943#15943: Unit tests to confirm content pref service doesn't write to disk in PBMThu, 07 May 2015 00:41:52 GMTarthuredelstein<p>
If we can confirm that the Content Pref Service doesn't write to disk in private browsing mode, then we can drop our patch for <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3229" title="#3229: defect: Make content pref service memory-only + clearable (closed: fixed)">#3229</a>. See the discussion at <a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=967809"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=967809</a>
</p>
<p>
Probably the most secure way to do this is to write unit tests.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/15943#changeloghttps://trac.torproject.org/projects/tor/ticket/16312
https://trac.torproject.org/projects/tor/ticket/16312#16312: Limit font queries per URL bar domainMon, 08 Jun 2015 18:20:18 GMTarthuredelstein<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a>, we introduced a patch to restrict the fonts allowed to be loaded in Tor Browser. But different versions of the same font could still be used to distinguish users. We could potentially limit the damage by introducing a second patch that restricts the number of allowed font requests per URL bar domain.
</p>
<p>
Previously we had a patch for <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/2872" title="#2872: enhancement: Limit the fonts available in TorBrowser (closed: fixed)">#2872</a> that worked something like this, although it wasn't tied to URL bar domain.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16312#changeloghttps://trac.torproject.org/projects/tor/ticket/16465
https://trac.torproject.org/projects/tor/ticket/16465#16465: windows get resized when not desiredTue, 30 Jun 2015 23:42:30 GMTarthuredelstein<p>
Diapolo has reported a strange behavior, where the Tor Browser window is getting resized even with most resizing prefs turned off.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16465#changeloghttps://trac.torproject.org/projects/tor/ticket/16577
https://trac.torproject.org/projects/tor/ticket/16577#16577: Verify that Tor Browser patch reverts cause test failuresTue, 14 Jul 2015 06:08:28 GMTarthuredelstein<p>
We should verify that if we revert any of our Tor Browser patches that have a corresponding regression test, then the test will fail.
</p>
<p>
We have regression tests for the following patches:
</p>
<ul><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5856" title="#5856: defect: Patch Firefox to alter window.screen directly (closed: fixed)">#5856</a>: Do not expose physical screen info via window &amp; window.screen.
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/2875" title="#2875: enhancement: Spoof Desktop Resolution in TorBrowser (closed: fixed)">#2875</a>: Limit device and system specific CSS Media Queries.
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/2950" title="#2950: defect: Make Permissions-Manager memory-only in TorBrowser (closed: fixed)">#2950</a>: Make Permissions Manager memory-only
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/4755" title="#4755: defect: Spoof screen coordinates on DOM MouseEvent (closed: fixed)">#4755</a>: Return client window coordinates for mouse event screenX/Y (for dragend, 0,0 is returned).
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/2874" title="#2874: enhancement: Block access to Components.interfaces from content script (closed: fixed)">#2874</a>: Block Components.interfaces from content
</li></ul><p>
Additionally the tests in
</p>
<ul><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13749" title="#13749: task: Write tests for privacy.thirdparty.isolate (closed: fixed)">#13749</a>.1: regression tests for first party isolation of localStorage
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13749" title="#13749: task: Write tests for privacy.thirdparty.isolate (closed: fixed)">#13749</a>.2: Regression tests for first-party isolation of cache
</li></ul><p>
cover patches
</p>
<ul><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/6564" title="#6564: enhancement: Enable DOM Storage and isolate it to url bar domain (closed: fixed)">#6564</a>: Isolate DOM storage to first party URI.
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/6539" title="#6539: defect: Image cache isolation causes assert crash in debug builds (and other ... (closed: fixed)">#6539</a>: Isolate the Image Cache per url bar domain.
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13742" title="#13742: defect: Isolating the cache to the URL bar domain is broken in Tor Browser 4.x (closed: fixed)">#13742</a>: Isolate cache to URL bar domain.
</li><li>Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10819" title="#10819: enhancement: Create preference for DOM storage isolation and image cache isolation (closed: fixed)">#10819</a>: Add a pref, "privacy.thirdparty.isolate", to allow the activation or deactivation of isolating DOM storage and image caching by first party URI.
</li></ul><p>
There are also a couple of regression test patches that I think may be broken:
</p>
<ul><li>TB4: Tor Browser's Firefox preference overrides.
</li><li>Omnibox: Add DDG, Startpage, Disconnect, Youtube, Twitter; remove Amazon, eBay, bing
</li></ul>Resultshttps://trac.torproject.org/projects/tor/ticket/16577#changeloghttps://trac.torproject.org/projects/tor/ticket/16672
https://trac.torproject.org/projects/tor/ticket/16672#16672: Text rendering allows font fingerprintingMon, 27 Jul 2015 04:35:48 GMTarthuredelstein<p>
Using dcf's font fingerprinting demo,
</p>
<p>
<a class="ext-link" href="https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo"><span class="icon">​</span>https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo</a>
</p>
<p>
gk <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313#comment:24" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">observed</a> that different operating systems render glyphs in the *same* font differently:
</p>
<blockquote class="citation">
<p>
I just tested that on two 32bit Linux systems (one Ubuntu 12.04 and one Debian testing) and even there are differeces visible with bundled fonts (the diff is attached). I guess this means shipping the alpha with it is fine (it can't get worse wrt to the status quo :) ) but we might want to have an estimation about what the current solution really helps us for the stable series before we ship it there.
</p>
</blockquote>
<p>
So I wonder whether it's possible to force Firefox/Tor Browser to use a cross-platform method for rendering fonts.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16672#changeloghttps://trac.torproject.org/projects/tor/ticket/16678
https://trac.torproject.org/projects/tor/ticket/16678#16678: Enhance KeyboardEvent fingerprinting protection for unusual charactersTue, 28 Jul 2015 01:18:25 GMTarthuredelstein<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/15646" title="#15646: defect: KeyboardEvent may allow fingerprinting of keyboard layout (closed: fixed)">#15646</a>, we introduced protection against KeyboardEvent-based fingerprinting of keyboard layout when characters normally found on a US-English keyboard are typed. Let's extend that protection to all characters one might expect from various Latin keyboards, such as German, French, Polish, etc.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16678#changeloghttps://trac.torproject.org/projects/tor/ticket/16686
https://trac.torproject.org/projects/tor/ticket/16686#16686: Migrate all font fingerprinting patches to tor-browser.gitWed, 29 Jul 2015 00:41:54 GMTarthuredelstein<p>
Right now, our font fingerprinting patches are divided between tor-browser.git and tor-browser-bundle.git. We'd like to move all patches to tor-browser.git.
</p>
<blockquote>
<p>
From our discussion at <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313#comment:25" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">ticket:13313#comment:25</a>:
</p>
</blockquote>
<p>
arthuredelstein:
</p>
<blockquote class="citation">
<p>
[We could] add the Noto fonts directly to the tor-browser.git repo, and add something in the Mozilla build scripts to install them in the directory where fonts are bundled. That would avoid modifying tor-browser-bundle.git altogether.
</p>
</blockquote>
<p>
gk:
</p>
<blockquote class="citation">
<p>
I think this makes sense. Another thing that bothers me with the currently proposed solution is that it makes bisecting quite error-prone. Although this is not documented yet the fastest approach is to just take an existing Tor Browser bundle and just bisect the tor-browser parts copying the result over the respective bundle parts with each iteration. This is not working anymore with having so many parts in tor-browser-bundle.git. Having everything in tor-browser could help us debug issues due to font updates easier as well.
</p>
</blockquote>
<p>
One issue is whether we want to use hinted or unhinted Noto fonts. If some OSs are incapable of making use of hinting, then we may decide to turn off hinting on all platforms. In that case we could bundle just unhinted fonts. OTOH, hinting maybe looks nicer, and it may be difficult to prevent fingerprinting Windows vs Linux vs Mac, so it's worth thinking about the tradeoff.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16686#changeloghttps://trac.torproject.org/projects/tor/ticket/16739
https://trac.torproject.org/projects/tor/ticket/16739#16739: Whitelist fonts by filename rather than font nameThu, 06 Aug 2015 08:09:15 GMTarthuredelstein<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a> we whitelisted fonts by file name. But as dcf points out, it would be ideal to whitelist bundled fonts only, using the font file path. As far as I can tell this will need to be implemented separately for Windows, Mac, and Linux.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16739#changeloghttps://trac.torproject.org/projects/tor/ticket/16936
https://trac.torproject.org/projects/tor/ticket/16936#16936: Circuit display should show original circuit for each tabMon, 31 Aug 2015 19:17:44 GMTarthuredelstein<p>
Instead of storing circuits per credentials, let's store them per-tab and then display the original circuit for each tab, even if that circuit has since closed and been replaced under the same credentials.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/16936#changeloghttps://trac.torproject.org/projects/tor/ticket/17023
https://trac.torproject.org/projects/tor/ticket/17023#17023: Investigate fingerprinting of mouse/pointing eventsWed, 09 Sep 2015 03:51:43 GMTarthuredelstein<p>
MouseEvent, WheelEvent, and DragEvent may reveal properties of the connected pointing device. Let's examine if we can suppress some of this fingerprintability.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17023#changeloghttps://trac.torproject.org/projects/tor/ticket/17140
https://trac.torproject.org/projects/tor/ticket/17140#17140: When Tor Browser updater runs, prefs don't get updatedWed, 23 Sep 2015 21:44:26 GMTarthuredelstein<p>
mrphs discovered that the font whitelist after the updater ran didn't get properly applied until restarting Tor Browser.
</p>
<p>
I also saw another pref not update this morning (I think it was "dom.event.highrestimestamp.enabled") when my TBB updated. (Though I may be misremembering.)
</p>
<p>
So it would be useful to figure out if prefs are not getting fully applied until the browser restarts after an update. Is this a Firefox problem or just TBB? It could potentially be a significant security/privacy flaw.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17140#changeloghttps://trac.torproject.org/projects/tor/ticket/17208
https://trac.torproject.org/projects/tor/ticket/17208#17208: New reported disk leaks in Tor BrowserFri, 02 Oct 2015 05:46:06 GMTarthuredelstein<p>
This document is interesting:
</p>
<p>
<a class="ext-link" href="http://www.dfrws.org/2015eu/proceedings/DFRWS-EU-2015-short-presentation-1.pdf"><span class="icon">​</span>http://www.dfrws.org/2015eu/proceedings/DFRWS-EU-2015-short-presentation-1.pdf</a>
</p>
<p>
We should investigate if these disk leaks can be fixed.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17208#changeloghttps://trac.torproject.org/projects/tor/ticket/17244
https://trac.torproject.org/projects/tor/ticket/17244#17244: Low entropy PRNG usage in Tor Browser?Mon, 05 Oct 2015 20:02:51 GMTarthuredelstein<p>
We should look for places where Tor Browser may leak the state of a low-entropy PRNG, thus linking a user across sites. <code>Math.random()</code> is a possibility. (I haven't investigated yet.)
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17244#changeloghttps://trac.torproject.org/projects/tor/ticket/17313
https://trac.torproject.org/projects/tor/ticket/17313#17313: Crash in Canvas patch seen on OS X Tor BrowserSat, 10 Oct 2015 00:58:08 GMTarthuredelstein<p>
I built tor-browser.git on OS X (non cross-compiled), and added torbutton and NoScript. Then if I go to theguardian.com, I get a crash. Here's the stack trace:
</p>
<pre class="wiki">On http://www.theguardian.com/international: blocked access to canvas image data from document http://www.theguardian.com/international, script from http://www.theguardian.com/international:223
Hit MOZ_CRASH([AutoAssertOnGC] possible GC in GC-unsafe region) at /projects/torproject/tor-browser31/js/src/jsgc.cpp:6919
Process 58004 stopped
* thread #1: tid = 0x227cad, 0x0000000106ef03e0 XUL`JS::AutoAssertOnGC::VerifyIsSafeToGC(rt=0x0000000111d59000) + 80 at jsgc.cpp:6919, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000106ef03e0 XUL`JS::AutoAssertOnGC::VerifyIsSafeToGC(rt=0x0000000111d59000) + 80 at jsgc.cpp:6919
6916 JS::AutoAssertOnGC::VerifyIsSafeToGC(JSRuntime* rt)
6917 {
6918 if (rt-&gt;gc.isInsideUnsafeRegion())
-&gt; 6919 MOZ_CRASH("[AutoAssertOnGC] possible GC in GC-unsafe region");
6920 }
6921
6922 JS::AutoAssertNoAlloc::AutoAssertNoAlloc(JSRuntime* rt)
(lldb) bt
* thread #1: tid = 0x227cad, 0x0000000106ef03e0 XUL`JS::AutoAssertOnGC::VerifyIsSafeToGC(rt=0x0000000111d59000) + 80 at jsgc.cpp:6919, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000106ef03e0 XUL`JS::AutoAssertOnGC::VerifyIsSafeToGC(rt=0x0000000111d59000) + 80 at jsgc.cpp:6919
frame #1: 0x0000000106f41f81 XUL`bool js::gc::CheckAllocatorState&lt;(cx=0x000000011696b790, kind=FINALIZE_STRING)1&gt;(js::ExclusiveContext*, js::gc::AllocKind) + 513 at jsgcinlines.h:473
frame #2: 0x0000000106faeece XUL`JSString* js::gc::AllocateNonObject&lt;JSString, (cx=0x000000011696b790)1&gt;(js::ExclusiveContext*) + 142 at jsgcinlines.h:562
frame #3: 0x0000000106faed75 XUL`JSString* js::NewGCString&lt;(cx=0x000000011696b790)1&gt;(js::ExclusiveContext*) + 21 at jsgcinlines.h:651
frame #4: 0x00000001069063a7 XUL`JSFlatString* JSFlatString::new_&lt;(cx=0x000000011696b790, chars=0x000000011eb8efc0, length=25)1, unsigned char&gt;(js::ExclusiveContext*, unsigned char const*, unsigned long) + 167 at String-inl.h:239
frame #5: 0x0000000106906d99 XUL`JSFlatString* js::NewStringCopyNDontDeflate&lt;(cx=0x000000011696b790, s=0x00000001072e296f, n=25)1, unsigned char&gt;(js::ExclusiveContext*, unsigned char const*, unsigned long) + 361 at String.cpp:1020
frame #6: 0x00000001069070d5 XUL`JSFlatString* js::NewStringCopyN&lt;(cx=0x000000011696b790, s=0x00000001072e296f, n=25)1, unsigned char&gt;(js::ExclusiveContext*, unsigned char const*, unsigned long) + 37 at String.h:1047
frame #7: 0x0000000106888ac5 XUL`JSFlatString* js::NewStringCopyN&lt;(cx=0x000000011696b790, s=0x00000001072e296f, n=25)1&gt;(js::ExclusiveContext*, char const*, unsigned long) + 37 at String.h:1140
frame #8: 0x0000000106888a0c XUL`JSFlatString* js::NewStringCopyZ&lt;(cx=0x000000011696b790, s=0x00000001072e296f)1&gt;(js::ExclusiveContext*, char const*) + 60 at String.h:1160
frame #9: 0x0000000106e3c581 XUL`JS_NewStringCopyZ(cx=0x000000011696b790, s=0x00000001072e296f) + 113 at jsapi.cpp:4352
frame #10: 0x000000010237b48b XUL`XPCConvert::NativeData2JS(d=JS::MutableHandleValue at 0x00007fff5fbf6e08, s=0x00007fff5fbf7aa8, type=0x00007fff5fbf74b0, iid=0x00007fff5fbf7920, pErr=0x0000000000000000) + 1755 at XPCConvert.cpp:232
frame #11: 0x00000001023e2b97 XUL`nsXPCWrappedJSClass::CallMethod(this=0x0000000113593470, wrapper=0x0000000115e86080, methodIndex=3, info_=0x0000000111d3a338, nativeParams=0x00007fff5fbf7aa0) + 4087 at XPCWrappedJSClass.cpp:1119
frame #12: 0x00000001023e1b89 XUL`nsXPCWrappedJS::CallMethod(this=0x0000000115e86080, methodIndex=3, info=0x0000000111d3a338, params=0x00007fff5fbf7aa0) + 185 at XPCWrappedJS.cpp:532
frame #13: 0x00000001017246f9 XUL`PrepareAndDispatch(self=0x0000000119ced600, methodIndex=3, args=0x00007fff5fbf7c00, gpregs=0x00007fff5fbf7b80, fpregs=0x00007fff5fbf7bb0) + 1577 at xptcstubs_x86_64_darwin.cpp:122
frame #14: 0x000000010172315b XUL`SharedStub + 91
frame #15: 0x00000001016701c9 XUL`nsObserverList::NotifyObservers(this=0x00000001169c5bd0, aSubject=0x0000000119d0d420, aTopic=0x00000001072e296f, someData=0x0000000108224ece) + 137 at nsObserverList.cpp:100
frame #16: 0x0000000101671f72 XUL`nsObserverService::NotifyObservers(this=0x00000001116aa5b0, aSubject=0x0000000119d0d420, aTopic=0x00000001072e296f, aSomeData=0x0000000108224ece) + 338 at nsObserverService.cpp:329
frame #17: 0x0000000103ba7da2 XUL`mozilla::CanvasUtils::IsImageExtractionAllowed(aDocument=0x0000000115e43800, aCx=0x00000001161e2430) + 2194 at CanvasUtils.cpp:134
frame #18: 0x0000000103baca11 XUL`mozilla::dom::CanvasRenderingContext2D::GetImageDataArray(this=0x000000011b930000, aCx=0x00000001161e2430, aX=0, aY=0, aWidth=1, aHeight=1, aRetval=0x00007fff5fbf82b8) + 1633 at CanvasRenderingContext2D.cpp:5017
frame #19: 0x0000000103bac1d5 XUL`mozilla::dom::CanvasRenderingContext2D::GetImageData(this=0x000000011b930000, aCx=0x00000001161e2430, aSx=0, aSy=0, aSw=1, aSh=1, error=0x00007fff5fbf83f0) + 1221 at CanvasRenderingContext2D.cpp:4932
frame #20: 0x00000001035b1c48 XUL`mozilla::dom::CanvasRenderingContext2DBinding::getImageData(cx=0x00000001161e2430, obj=Handle&lt;JSObject *&gt; at 0x00007fff5fbf8478, self=0x000000011b930000, args=0x00007fff5fbf84f0) + 744 at CanvasRenderingContext2DBinding.cpp:4416
frame #21: 0x0000000103b85260 XUL`mozilla::dom::GenericBindingMethod(cx=0x00000001161e2430, argc=4, vp=0x00000001134b8208) + 656 at BindingUtils.cpp:2537
frame #22: 0x00000001067ee4e9 XUL`js::CallJSNative(cx=0x00000001161e2430, native=0x0000000103b84fd0, args=0x00007fff5fbf8b80)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&amp;) + 185 at jscntxtinlines.h:226
frame #23: 0x0000000106772471 XUL`js::Invoke(cx=0x00000001161e2430, args=CallArgs at 0x00007fff5fbf8b80, construct=NO_CONSTRUCT) + 1137 at Interpreter.cpp:498
frame #24: 0x000000010678cc85 XUL`Interpret(cx=0x00000001161e2430, state=0x00007fff5fbfb938) + 51269 at Interpreter.cpp:2602
frame #25: 0x0000000106780357 XUL`js::RunScript(cx=0x00000001161e2430, state=0x00007fff5fbfb938) + 583 at Interpreter.cpp:448
frame #26: 0x0000000106798938 XUL`js::ExecuteKernel(cx=0x00000001161e2430, script=JS::HandleScript at 0x00007fff5fbfba20, scopeChainArg=0x000000011dbf5060, thisv=0x00007fff5fbfbaa0, type=EXECUTE_GLOBAL, evalInFrame=AbstractFramePtr at 0x00007fff5fbfba00, result=0x0000000000000000) + 904 at Interpreter.cpp:654
frame #27: 0x0000000106798c2a XUL`js::Execute(cx=0x00000001161e2430, script=JS::HandleScript at 0x00007fff5fbfbb08, scopeChainArg=0x000000011dbf5060, rval=0x0000000000000000) + 666 at Interpreter.cpp:690
</pre><p>
I haven't observed this on the cross-compiled alpha, so perhaps it is peculiar to the way I was building. Still it seems worth checking out in case we have some incorrect code.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17313#changeloghttps://trac.torproject.org/projects/tor/ticket/17355
https://trac.torproject.org/projects/tor/ticket/17355#17355: Investigate whether we should re-implement methods of JS Date to avoid fingerprintingFri, 16 Oct 2015 00:32:41 GMTarthuredelstein<p>
With <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17329" title="#17329: defect: Can't type some special characters in text fields (closed: fixed)">#17329</a> we may have some Linux systems with "C.UTF-8" locale and others with "C". It's also possible, perhaps, that different systems may have different implementations of the "C" locale. We can investigate whether it would be possible to re-implement the JS Date object so that it is fully uniform across systems.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17355#changeloghttps://trac.torproject.org/projects/tor/ticket/17367
https://trac.torproject.org/projects/tor/ticket/17367#17367: Swap files can contain evidence of browsing historySat, 17 Oct 2015 05:48:26 GMTarthuredelstein<p>
Two forensic reports describe extracting Tor Browser browsing history from a Windows pagefile.sys and hiberfil.sys:
</p>
<p>
See
<a class="ext-link" href="http://computerforensicsblog.champlain.edu/wp-content/uploads/2014/06/One-User-Multiple-Devices-Cross-Platform-Recovery-and-Analysis...-Saliba-Landry-5-20-2014.pdf#33"><span class="icon">​</span>http://computerforensicsblog.champlain.edu/wp-content/uploads/2014/06/One-User-Multiple-Devices-Cross-Platform-Recovery-and-Analysis...-Saliba-Landry-5-20-2014.pdf#33</a>
and
<a class="ext-link" href="https://web.archive.org/web/20160403075329/http://dfrws.org/2015eu/proceedings/DFRWS-EU-2015-short-presentation-1.pdf#16"><span class="icon">​</span>https://web.archive.org/web/20160403075329/http://dfrws.org/2015eu/proceedings/DFRWS-EU-2015-short-presentation-1.pdf#16</a>
</p>
<p>
Is there any way we can programmatically clean up the pagefile on New Identity and/or browser exit? What about OS X and Linux?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17367#changeloghttps://trac.torproject.org/projects/tor/ticket/17394
https://trac.torproject.org/projects/tor/ticket/17394#17394: Consolidate ThirdPartyUtil patchesTue, 20 Oct 2015 21:22:57 GMTarthuredelstein<p>
Our ThirdPartyUtil.* changes are spread among various patches. It would be nice to move all those changes to a single patch to help with refactoring and upstreaming to Mozilla.
</p>
<p>
Patches include:
</p>
<ul><li><a class="ext-link" href="https://torpat.ch/5742"><span class="icon">​</span>https://torpat.ch/5742</a>
</li><li><a class="ext-link" href="https://torpat.ch/10819"><span class="icon">​</span>https://torpat.ch/10819</a>
</li><li><a class="ext-link" href="https://torpat.ch/13900"><span class="icon">​</span>https://torpat.ch/13900</a>
</li><li><a class="ext-link" href="https://torpat.ch/13670"><span class="icon">​</span>https://torpat.ch/13670</a>
</li><li><a class="ext-link" href="https://torpat.ch/15502"><span class="icon">​</span>https://torpat.ch/15502</a>
</li></ul>Resultshttps://trac.torproject.org/projects/tor/ticket/17394#changeloghttps://trac.torproject.org/projects/tor/ticket/17412
https://trac.torproject.org/projects/tor/ticket/17412#17412: High-precision timestamps in JSThu, 22 Oct 2015 23:17:23 GMTarthuredelstein<p>
Methods for high-precision timestamps in JavaScript are discussed here:
</p>
<p>
<a class="ext-link" href="https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/1"><span class="icon">​</span>https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/1</a>
</p>
<p>
What sort of countermeasures could we introduce? Perhaps we will need to disable SharedArrayBuffers in Tor Browser?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17412#changeloghttps://trac.torproject.org/projects/tor/ticket/17431
https://trac.torproject.org/projects/tor/ticket/17431#17431: Investigate attacks in fingerprinting paperTue, 27 Oct 2015 03:34:11 GMTarthuredelstein<p>
Here's a 2015 paper on hardware-targeted JS fingerprinting attacks. We should check if we need to add any protections:
</p>
<p>
<a class="ext-link" href="http://arxiv.org/pdf/1503.01408.pdf"><span class="icon">​</span>http://arxiv.org/pdf/1503.01408.pdf</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17431#changeloghttps://trac.torproject.org/projects/tor/ticket/17785
https://trac.torproject.org/projects/tor/ticket/17785#17785: Unit tests for font whitelisting patchTue, 08 Dec 2015 22:50:10 GMTarthuredelstein<p>
We need unit tests for the font whitelisting patch (<a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a>).
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/17785#changeloghttps://trac.torproject.org/projects/tor/ticket/18087
https://trac.torproject.org/projects/tor/ticket/18087#18087: security.nocertdb -> false breaks mochitest https pagesMon, 18 Jan 2016 06:44:33 GMTarthuredelstein<p>
When the <code>security.nocertdb</code> pref is enabled, mochitests that attempt to connect to <code>https://example.com</code> run into a "This connection is untrusted" error. We should try to fix this (and upstream to mozilla).
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18087#changeloghttps://trac.torproject.org/projects/tor/ticket/18097
https://trac.torproject.org/projects/tor/ticket/18097#18097: Font fingerprinting defenses roadmap (parent ticket)Tue, 19 Jan 2016 06:10:31 GMTarthuredelstein<p>
Defending against font fingerprinting is complex. We have to worry about distinguishing attacks via differing installed font sets, text rendering engine differences, and font variants. There are a variety of tickets involved. This ticket is to track our progress.
</p>
<p>
Here's an overview of our approach:
</p>
<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a>, we introduced a Tor Browser pref, "font.system.whitelist", which accepts a list of fonts and excludes all others from the browser. We introduced a separate whitelist for OS X, Windows, and Linux. (For the Linux Tor Browser bundle, we do not use the "font.system.whitelist" pref. Instead we bundle all fonts and use a <code>fonts.conf</code> file to restrict the browser to use only the bundled fonts.)
</p>
<p>
This whitelisting mechanism protects against font enumeration attacks, such as <a class="ext-link" href="http://www.lalit.org/lab/javascript-css-font-detect/"><span class="icon">​</span>http://www.lalit.org/lab/javascript-css-font-detect/</a>. Our whitelisting patch applies to CSS <code>font-family</code> and <code>src:local</code> (<a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17759" title="#17759: defect: font whitelist fails to stop local fonts in @font-face (closed: fixed)">#17759</a>) queries and also the Canvas <code>font</code> property. It does not prevent an attacker from identifying the operating system, nor from distinguishing two versions of an operating system by detecting different variants of the same font.
</p>
<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/16707" title="#16707: defect: Packaged fonts in Tor Browser make websites partly unreadable on OS X ... (closed: fixed)">#16707</a> we whitelisted a largish set of fonts for Windows and OS X that are shipped with the operating system by default. In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17220" title="#17220: defect: math symbols not supported by font whitelist (closed: fixed)">#17220</a> we added some standard Math fonts to the whitelist. And in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17250" title="#17250: defect: Japanese font(s) look ugly on websites (closed: fixed)">#17250</a> and <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17661" title="#17661: defect: Mac OS: whitelist the font .Helvetica Neue DeskInterface (closed: fixed)">#17661</a>, we expanded the font whitelist to include UI fonts found on some versions of Windows and OS X. See also <a class="new ticket" href="https://trac.torproject.org/projects/tor/ticket/17999" title="#17999: defect: Changed default GUI font might help fingerprinting JA Windows users (new)">#17999</a>.
</p>
<p>
David Fifield (dcf) wrote a script that fingerprints the user by measuring the bounding box of glyphs at certain code points. We found that different flavors of Linux render the same fonts differently and thus produce different fingerprints. We also expect different versions of Windows and Mac to also be distinguishable by font metrics. For the Linux case, we hope to adjust rendering settings and/or bundle rendering libraries to make the flavors indistinguishable: see <a class="assigned ticket" href="https://trac.torproject.org/projects/tor/ticket/16672" title="#16672: defect: Text rendering allows font fingerprinting (assigned)">#16672</a>.
</p>
<p>
We might also be able to reduce the effectiveness of fingerprinting attacks on all platforms by only allowed a limited number of font queries per URL bar domain: see <a class="needs_information ticket" href="https://trac.torproject.org/projects/tor/ticket/16312" title="#16312: defect: Limit font queries per URL bar domain (needs_information)">#16312</a>.
</p>
<p>
Our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a> patch whitelists fonts by name, so it likely allows a font installed on the system to supersede a font bundled with the browser if they have the same font name. So we would consider changing the patch to whitelisting by font filename or restricting allowed directories for font loading: see <a class="new ticket" href="https://trac.torproject.org/projects/tor/ticket/16739" title="#16739: enhancement: Whitelist fonts by filename rather than font name (new)">#16739</a>.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18097#changeloghttps://trac.torproject.org/projects/tor/ticket/18205
https://trac.torproject.org/projects/tor/ticket/18205#18205: Restrict font whitelist patch to apply only to non-chrome contexts?Mon, 01 Feb 2016 20:00:00 GMTarthuredelstein<p>
We have run into a number of difficulties where Tor-Browser's whitelist is preventing the browser's non-content UI (aka chrome) from rendering properly. It would be better if we could only apply the whitelist to content.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18205#changeloghttps://trac.torproject.org/projects/tor/ticket/18311
https://trac.torproject.org/projects/tor/ticket/18311#18311: Document first party isolation for Tor researchersFri, 12 Feb 2016 17:47:07 GMTarthuredelstein<p>
Academics researching tor may not be aware that Tor Browser is isolating by URL bar domain (aka first party isolation), as implemented in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3455" title="#3455: enhancement: Tor Browser should set SOCKS username for a request based on first ... (closed: fixed)">#3455</a>. We should note this somewhere in the tor documentation so this difference in behavior between default tor and default Tor Browser is not overlooked by researchers. See also <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5753" title="#5753: defect: When we isolate streams by domain, can a local observer guess how many ... (closed: wontfix)">#5753</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18311#changeloghttps://trac.torproject.org/projects/tor/ticket/18334
https://trac.torproject.org/projects/tor/ticket/18334#18334: Test cases for OCSP isolationThu, 18 Feb 2016 06:55:20 GMTarthuredelstein<p>
We need some sort of regression tests for OCSP isolation, which was implemented in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13670" title="#13670: defect: ensure OCSP requests respect URL bar domain isolation (closed: fixed)">#13670</a>.2.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18334#changeloghttps://trac.torproject.org/projects/tor/ticket/18376
https://trac.torproject.org/projects/tor/ticket/18376#18376: Accessibility APIs in FirefoxMon, 22 Feb 2016 23:20:21 GMTarthuredelstein<p>
Here's the homepage for Mozilla's accessibility functionality:
<a class="ext-link" href="https://developer.mozilla.org/en-US/docs/Web/Accessibility"><span class="icon">​</span>https://developer.mozilla.org/en-US/docs/Web/Accessibility</a>
</p>
<p>
We should check if any accessibility APIs are exposed to content in any way that would help attackers to fingerprint users.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18376#changeloghttps://trac.torproject.org/projects/tor/ticket/18903
https://trac.torproject.org/projects/tor/ticket/18903#18903: Regression tests for canvas image extraction promptTue, 26 Apr 2016 17:59:29 GMTarthuredelstein<p>
It would be nice to have regression tests for our Canvas Image Extraction patch (<a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/6253" title="#6253: defect: Prompt before allowing HTML5 Canvas image extraction (closed: fixed)">#6253</a>).
</p>
<p>
mcs and brade developed some tests here: <a class="ext-link" href="https://people.torproject.org/~brade/tests/canvasTest.html"><span class="icon">​</span>https://people.torproject.org/~brade/tests/canvasTest.html</a>. Perhaps we could port these to a mochitest.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/18903#changeloghttps://trac.torproject.org/projects/tor/ticket/19037
https://trac.torproject.org/projects/tor/ticket/19037#19037: Suppress content access to page visibility APIWed, 11 May 2016 22:38:56 GMTarthuredelstein<p>
The <code>document.visibility</code> property and the <code>visibilitychange</code> event let content know if the user has selected or deselected a tab. If the user switches from tab A to tab B, then tab A can receive a "hidden" event at the same time that tab B receives a "visible" event. So it seems potentially useful to suppress this information.
</p>
<p>
See <a class="ext-link" href="https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API"><span class="icon">​</span>https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19037#changeloghttps://trac.torproject.org/projects/tor/ticket/19198
https://trac.torproject.org/projects/tor/ticket/19198#19198: Examine whether we have proper first-party isolation inside nested WorkersSat, 28 May 2016 23:02:27 GMTarthuredelstein<p>
It's possible that our first-party isolation mechanism for blobs, the HTTP cache, or other things does not work properly inside nested Workers. We should check and potentially add to our regression tests.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19198#changeloghttps://trac.torproject.org/projects/tor/ticket/19508
https://trac.torproject.org/projects/tor/ticket/19508#19508: Proposal to drop Tor Browser's plugin patchesSun, 26 Jun 2016 06:39:08 GMTarthuredelstein<p>
Tor Browser has three patches related to blocking plugins:
</p>
<ul><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3547" title="#3547: defect: Disable all plugins but flash (closed: fixed)">#3547</a> adds a function that whitelists the flash plugin only and excludes loading all other plugins
</li><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/8312" title="#8312: defect: Remove &#34;This Plugin is Disabled&#34; click-through (closed: fixed)">#8312</a> hides the link to "Manage plugins" when the plugin is disabled
</li><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10280" title="#10280: enhancement: Torbrowser shouldn't load flash into the process space by default (closed: fixed)">#10280</a> adds a UI for enabling/disabling plugins in the add-ons page
</li></ul><p>
These patches were introduced when Flash was still in fairly wide use. But since then, Flash has been disabled by default in Firefox, and is replaced on a substantial number of websites by HTML5 video and JavaScript. Furthermore, we want to strongly discourage users from using Flash as there is a significant risk that it will bypass the proxy or expose the user to tracking or security vulnerabilities.
</p>
<p>
First, from what I can see, when the pref <code>plugin.disable</code> is set to true (as it is in <code>browser/app/profile/000-tor-browser.js</code>), all plugins (including Flash) are blocked from ever loading into the Firefox process. Therefore the code in our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/3547" title="#3547: defect: Disable all plugins but flash (closed: fixed)">#3547</a> is never exercised.
</p>
<p>
Second, <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10280" title="#10280: enhancement: Torbrowser shouldn't load flash into the process space by default (closed: fixed)">#10280</a> only makes it more likely for the user to set "plugin.disable" to false, by exposing that pref in the UI.
</p>
<p>
Finally, <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/8312" title="#8312: defect: Remove &#34;This Plugin is Disabled&#34; click-through (closed: fixed)">#8312</a> seems unnecessary because, when "plugin.disable" is true, no "Manage plugins" link appears. Instead, the only message is "A plugin is needed to display this content." Also, various popular video sites, such as YouTube and Vimeo, now use HTML5 video without any complaints about missing Flash.
</p>
<p>
So I would suggest we can drop these three patches. Instead we might consider a couple of UI tweaks to improve user safety:
</p>
<ol><li>Hide the Plugins section of about:addons altogether to prevent the user from even considering loading any plugins
</li><li>Change the plugin failure message to "A plugin would be needed to display this content. For security reasons, Tor Browser does not support plugins."
</li></ol><p>
I think both of these changes could be implemented as XUL overlays in torbutton.
</p>
<p>
Finally, for extra safety, we could add an extra C++ patch that ensures that whenever an nsPluginsDir::LoadPlugin implementation is called, the <code>plugin.disable</code> pref is checked and, if it is true, the function loads nothing and returns an error code. I think such a patch might be upstreamable.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19508#changeloghttps://trac.torproject.org/projects/tor/ticket/19510
https://trac.torproject.org/projects/tor/ticket/19510#19510: Drop #5741 patch?Sun, 26 Jun 2016 18:47:15 GMTarthuredelstein<p>
It appears that Mozilla fixed its WebSocket DNS leak here:
<a class="ext-link" href="https://bugzilla.mozilla.org/751465"><span class="icon">​</span>https://bugzilla.mozilla.org/751465</a>
and Georg successfully landed a regression test in Firefox to ensure that WebSockets don't leak DNS requests:
<a class="ext-link" href="https://bugzilla.mozilla.org/971153"><span class="icon">​</span>https://bugzilla.mozilla.org/971153</a>
</p>
<p>
So is it true that we can drop our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/5741" title="#5741: defect: TBB proxy bypass: Some DNS requests not going through Tor (closed: fixed)">#5741</a> patch now?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19510#changeloghttps://trac.torproject.org/projects/tor/ticket/19511
https://trac.torproject.org/projects/tor/ticket/19511#19511: Drop #16488 patchSun, 26 Jun 2016 18:53:18 GMTarthuredelstein<p>
Our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/16488" title="#16488: task: Remove &#34;Sign in to Sync&#34; from the menu (closed: fixed)">#16488</a> patch was intended to hide the Sign in to Sync button in the hamburger menu. Unfortuately, reviewers at Mozilla weren't sure it was a good idea, and then it stopped working correctly when I rebased to FF45ESR.
</p>
<p>
We introduced torbutton patch <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/18743" title="#18743: defect: &#34;Sign in to Sync&#34; icon not hidden in ESR45-based Tor Browser (closed: fixed)">#18743</a> instead. So I believe we can revert (or remove) our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/16488" title="#16488: task: Remove &#34;Sign in to Sync&#34; from the menu (closed: fixed)">#16488</a> patch from tor-browser.git.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19511#changeloghttps://trac.torproject.org/projects/tor/ticket/19741
https://trac.torproject.org/projects/tor/ticket/19741#19741: favicon in searchbar popup uses catchall circuitFri, 22 Jul 2016 22:48:44 GMTarthuredelstein<p>
To reproduce:
</p>
<ul><li>Set "torbutton.loglevel" to 3.
</li><li>Enter the word "test" in the searchbar. Click on the DuckDuckGo icon in the popup menu below to cause a search for "test" to be performed on DuckDuckGo. After the search is performed, a green "plus" symbol appears on the searchbar magnifying glass icon.
</li><li>Open the browser console, and clear it.
</li><li>Click on the searchbar again. An additional menu item appears, which contains the text <code>Add "DuckDuckGo (HTML)"</code> and a DuckDuckGo favicon.
</li><li>Examine the browser console. Log messages should appear as follows:
<pre class="wiki">[07-22 22:38:01] Torbutton INFO: tor SOCKS: http://3g2upl4pq6kufc4m.onion/favicon.ico via --NoFirstPartyHost-chrome-browser.xul--:9bb8a61534faf1f952647a3537560fb0
GET
http://3g2upl4pq6kufc4m.onion/favicon.ico [HTTP/1.1 200 OK 0ms]
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[07-22 22:38:02] Torbutton INFO: controlPort &gt;&gt; 650 STREAM 264 NEW 0 3g2upl4pq6kufc4m.onion:80 SOURCE_ADDR=127.0.0.1:52895 PURPOSE=USER
[07-22 22:38:02] Torbutton INFO: controlPort &gt;&gt; 650 STREAM 264 SENTCONNECT 15 3g2upl4pq6kufc4m.onion:80
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[07-22 22:38:02] Torbutton INFO: controlPort &gt;&gt; 650 STREAM 264 SUCCEEDED 15 3g2upl4pq6kufc4m.onion:80
</pre>should be visible. I believe these messages are caused by
</li></ul><p>
So it appears that the favicon display inside "add-engines" vbox of the search popup is being sent over the catchall circuit.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19741#changeloghttps://trac.torproject.org/projects/tor/ticket/19750
https://trac.torproject.org/projects/tor/ticket/19750#19750: Sandboxing in Tor BrowserMon, 25 Jul 2016 18:36:46 GMTarthuredelstein<p>
Here's a parent ticket to track efforts to sandbox Tor Browser. Please use this ticket to discuss various approaches and link to email discussions where available.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19750#changeloghttps://trac.torproject.org/projects/tor/ticket/20360
https://trac.torproject.org/projects/tor/ticket/20360#20360: tooltips on Security Slider not working on macOS sierraThu, 13 Oct 2016 18:26:17 GMTarthuredelstein<p>
Linda reports:
</p>
<blockquote class="citation">
<p>
The hovering didn't work for me on 6.0.5 on mac os sierra 10.12.
</p>
</blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/20360#changeloghttps://trac.torproject.org/projects/tor/ticket/20639
https://trac.torproject.org/projects/tor/ticket/20639#20639: Bundle HTML pages inside Tor BrowserSat, 12 Nov 2016 06:02:32 GMTarthuredelstein<p>
Follow up to <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/20614" title="#20614: defect: Add link to Tor Browser manual to about:tor (closed: fixed)">#20614</a>. Instead of linking to the Tor Browser manual on torproject.org, we should instead bundle it with the browser. And there should be a button that displays the manual to help users who are getting stuck trying to connect to the tor network.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20639#changeloghttps://trac.torproject.org/projects/tor/ticket/20842
https://trac.torproject.org/projects/tor/ticket/20842#20842: Proposal: Improve Tor Browser font whitelist / bundled fontsWed, 30 Nov 2016 02:52:33 GMTarthuredelstein<p>
<strong>Background:</strong>
</p>
<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/13313" title="#13313: enhancement: Enable bundled fonts in Tor Browser (closed: fixed)">#13313</a> we introduced a new font whitelisting mechanism. Tor Browser only allows certain fonts to be used in the browser, in order to prevent bad people from trying to identify you by detecting what fonts are installed on your computer. Font whitelisting is also available in Firefox, off by default. (The whitelisting is controlled by a pref, "font.system.whitelist", which contains a comma-separated list of allowed font names. You can edit this pref by opening a tab and browsing to <code>about:config</code>.)
</p>
<p>
On Window and Mac, we mostly whitelist certain system fonts that are bundled with the operating system by default. We bundle a few <a class="ext-link" href="https://www.google.com/get/noto/"><span class="icon">​</span>Google Noto fonts</a> as well for languages that don't have a built-in platform font.
</p>
<p>
On Linux, we bundle a large number of Google Noto fonts, plus Arimo, Cousine, and Tinos. We don't expose any system fonts, because these aren't consistent across Linux flavors.
</p>
<p>
My strategy for choosing fonts for the whitelist was to try to cover all possible languages with at least one font, and get the work done as efficiently as possible. I whitelisted Mac and Windows fonts that have been available for a long time and should be on essentially all systems. Bundling fonts from the Noto collection was a quick and dirty method for covering any missing fonts for different languages.
</p>
<p>
But there are probably more appealing fonts for some languages that we could use, especially on Linux. For example, in <a class="new ticket" href="https://trac.torproject.org/projects/tor/ticket/20820" title="#20820: enhancement: Add font support for Shift-JIS (new)">#20820</a> we are considering switching Linux from Noto Japanese to mona.ttf because the latter looks better (according to Yawning) and because mona.ttf can be used in the ancient Japanese art of ascii calligraphy. I also heard from someone who knows that the Tamil font on Windows is not too beautiful.
</p>
<p>
<strong>Proposed project:</strong>
</p>
<p>
So it would be a useful project to go through each of the fonts on each platform and see if there are better fonts that could be used instead. Important considerations would include:
</p>
<ul><li>Aesthetics
</li><li>Character coverage
</li><li>Printability
</li><li>Font licensing
</li><li>Font file size
</li></ul><p>
This would require asking the opinions of native speakers of various languages.
</p>
<p>
Ideally, we could come up with a new font whitelist and bundling list for Mac, Windows and Linux, where the fonts are beautiful and users are happy.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20842#changeloghttps://trac.torproject.org/projects/tor/ticket/20843
https://trac.torproject.org/projects/tor/ticket/20843#20843: Tor Browser: How do we help users to use higher security?Wed, 30 Nov 2016 04:42:46 GMTarthuredelstein<p>
The security slider lets users adjust their Tor Browser's behavior along the security-usability tradeoff. But Tor Browser is a juicy target, so we'd like to encourage users to use Medium-High Security or higher. But right now we set the default to Low because we don't want to scare away naive users who would think that Tor Browser is "broken" at higher security levels (when JavaScript and other features are disabled).
</p>
<p>
So an interesting UX question is how to design an interface that helps more users choose higher security, without driving users away. Testing would be important, I think.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20843#changeloghttps://trac.torproject.org/projects/tor/ticket/20955
https://trac.torproject.org/projects/tor/ticket/20955#20955: Tor Browser memory hardeningMon, 12 Dec 2016 19:38:19 GMTarthuredelstein<p>
Here's a parent ticket for memory hardening for Tor Browser.
</p>
<p>
See also notes at <a class="wiki" href="https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hardening">doc/TorBrowser/Hardening</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20955#changeloghttps://trac.torproject.org/projects/tor/ticket/20957
https://trac.torproject.org/projects/tor/ticket/20957#20957: Get DieHarder working with Tor BrowserMon, 12 Dec 2016 20:26:39 GMTarthuredelstein<p>
The <a class="ext-link" href="https://emeryberger.com/research/dieharder/"><span class="icon">​</span>DieHarder memory allocator</a> looks like a possible hardening measure for Tor Browser. We should try to get it working, and evaluate it for performance, effectiveness and suitability.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20957#changeloghttps://trac.torproject.org/projects/tor/ticket/20971
https://trac.torproject.org/projects/tor/ticket/20971#20971: Try building Tor Browser with SafeStackWed, 14 Dec 2016 19:42:06 GMTarthuredelstein<p>
SafeStack is part of the <a class="ext-link" href="http://dslab.epfl.ch/proj/cpi/"><span class="icon">​</span>Levee</a> project and prevents stack smashing attacks. It is reported to have a negligible performance hit.
</p>
<p>
Together, Levee's components, SafeStack and CPI or CPS, are supposed to prevent code flow hijacking. Once CPI and CPS have been released, we should try those as well.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/20971#changeloghttps://trac.torproject.org/projects/tor/ticket/21034
https://trac.torproject.org/projects/tor/ticket/21034#21034: Per site security settings?Mon, 19 Dec 2016 20:21:41 GMTarthuredelstein<p>
It would be useful (and perhaps safer) to have per-site security settings rather than browser-wide security settings. Also we might want to enforce different security settings for http vs https.
</p>
<p>
In Firefox 52, with e10s enabled, perhaps we can use separate content processes for every first-party and apply different security settings prefs separately to each one.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21034#changeloghttps://trac.torproject.org/projects/tor/ticket/21385
https://trac.torproject.org/projects/tor/ticket/21385#21385: Ensure fonts are always loaded in the same orderThu, 02 Feb 2017 19:40:30 GMTarthuredelstein<p>
We bundle fonts with Linux Tor Browser, but I recall noticing that the bundled fonts are used with different priorities on different Linux flavors, such that a given code point is displayed with Font 1 on Linux flavor A and Font 2 on Linux flavor B. This probably has to do with the order of font loading being different.
</p>
<p>
Currently we use a workaround in 000-tor-browser.js, where we enforce priorities useing the font.name* prefs. But we should investigate the underlying reason for this problem and come up with a better patch that ensures our whitelisted fonts are always applied in the same order. That way a given code point will always use the same font.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21385#changeloghttps://trac.torproject.org/projects/tor/ticket/21448
https://trac.torproject.org/projects/tor/ticket/21448#21448: Identify what build flags we should be using for security, and use themTue, 14 Feb 2017 00:59:22 GMTarthuredelstein<p>
I think we may be able to add some configure/compiler/linker flags in Tor Browser that can improve security without many downsides. Let's figure out what those are and add them.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21448#changeloghttps://trac.torproject.org/projects/tor/ticket/21657
https://trac.torproject.org/projects/tor/ticket/21657#21657: Test to make sure we isolate or disable all speculative connectsMon, 06 Mar 2017 20:28:40 GMTarthuredelstein<p>
There are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
</p>
<pre class="wiki"> link rel=preconnect
link rel=prefetch
link rel=prerender
</pre><p>
and possibly more.
We should test this for the ESR45 and ESR52 versions of Tor Browser, because isolation will have different mechanisms.
</p>
<p>
See <a class="ext-link" href="https://w3c.github.io/resource-hints/"><span class="icon">​</span>https://w3c.github.io/resource-hints/</a>
</p>
<p>
We should also look into "SpeculativeConnect" code in Firefox to make sure there aren't any other cases of non-first-party isolated connections.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21657#changeloghttps://trac.torproject.org/projects/tor/ticket/21714
https://trac.torproject.org/projects/tor/ticket/21714#21714: Patch tor-browser.git to quantize dimensions when user resizes windowSun, 12 Mar 2017 00:01:28 GMTarthuredelstein<p>
We would like to port or re-implement the old <a class="needs_revision ticket" href="https://trac.torproject.org/projects/tor/ticket/14429" title="#14429: defect: Automated rounding of content window dimensions (needs_revision)">#14429</a> patch to tor-browser.git, for subsequent uplifting to Firefox.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21714#changeloghttps://trac.torproject.org/projects/tor/ticket/21806
https://trac.torproject.org/projects/tor/ticket/21806#21806: webgl hangs on Tor BrowserThu, 23 Mar 2017 14:06:09 GMTarthuredelstein<p>
Cynthia and Tim observed this. First go to <a class="ext-link" href="http://hexgl.bkcore.com/play"><span class="icon">​</span>http://hexgl.bkcore.com/play</a> . Then click NoScript to allow webgl. Seen on mac.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21806#changeloghttps://trac.torproject.org/projects/tor/ticket/21814
https://trac.torproject.org/projects/tor/ticket/21814#21814: Reduce binary size for client-only torFri, 24 Mar 2017 16:57:01 GMTarthuredelstein<p>
Uncompressed, the Tor executable and associated libs as bundled in Tor Browser is 7.7 MB. If we want other browsers to adopt Tor, it would be good to make it a lot smaller if possible. What is responsible for the bulk? Can we cut out unused code from libcrypto and other libraries? Or can we reuse some shared libraries from the browser? Would it help to chop out unused code that implements relays, hidden services, etc.?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21814#changeloghttps://trac.torproject.org/projects/tor/ticket/21851
https://trac.torproject.org/projects/tor/ticket/21851#21851: Revert some of #18915 changes (search box)Tue, 04 Apr 2017 06:40:15 GMTarthuredelstein<p>
Following <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21309" title="#21309: defect: Fix Omnibox for TBB/52ESR (closed: fixed)">#21309</a>, we may be able to revert some of the <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/18915" title="#18915: defect: Omnibox in a non-english Tor Browser has no Disconnect.me as search ... (closed: fixed)">#18915</a> changes.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21851#changeloghttps://trac.torproject.org/projects/tor/ticket/21916
https://trac.torproject.org/projects/tor/ticket/21916#21916: possible obsolete or incorrect pref settingsTue, 11 Apr 2017 05:30:43 GMTarthuredelstein<p>
A cypherpunks user has <a href="https://trac.torproject.org/projects/tor/ticket/20680#comment:30">suggested</a> that a number of our prefs may be obsolete or incorrect. Let's examine them and change any that need changing:
</p>
<blockquote class="citation">
<p>
O [removed in esr17] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/6210" title="#6210: enhancement: set plugin.expose_full_path to false (closed: fixed)">#6210</a>: set plugin.expose_full_path to false
O [removed in esr38] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/9012" title="#9012: defect: Do not display the missing plugin information bar (closed: fixed)">#9012</a>: Do not display the missing plugin information bar
D [broken] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/9867" title="#9867: defect: Flash is not click-to-play (closed: fixed)">#9867</a>: Flash is not click-to-play
O* [removed in esr31] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10703" title="#10703: defect: Fallback charset enables fingerprinting of bundle localization (closed: fixed)">#10703</a>: Fallback charset enables fingerprinting of bundle localization
O [FF has] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/11253" title="#11253: enhancement: Turn on TLS 1.1 and 1.2 in TorBrowser (closed: fixed)">#11253</a>: Turn on TLS 1.1 and 1.2 in TorBrowser
O [removed in esr31] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/12212" title="#12212: defect: Disable deprecated Audio Data API (closed: fixed)">#12212</a>: Disable deprecated Audio Data API
O [removed in esr38] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/15029" title="#15029: defect: Tor Browser 4.5a4 prompts to install Flash (closed: fixed)">#15029</a>: Tor Browser 4.5a4 prompts to install Flash
O [FF has] Bug <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/17369" title="#17369: defect: The RC4 cipher flags in TBB must be set to &#34;false&#34; by default (closed: fixed)">#17369</a>: The RC4 cipher flags in TBB must be set to "false" by default
</p>
</blockquote>
Resultshttps://trac.torproject.org/projects/tor/ticket/21916#changeloghttps://trac.torproject.org/projects/tor/ticket/21945
https://trac.torproject.org/projects/tor/ticket/21945#21945: Fix initial window size on LinuxFri, 14 Apr 2017 19:34:23 GMTarthuredelstein<p>
Mozilla uplifted our window sizing patch, and it works very well on Mac and Windows, but on Linux windows are still sometimes smaller than they need to be.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21945#changeloghttps://trac.torproject.org/projects/tor/ticket/21983
https://trac.torproject.org/projects/tor/ticket/21983#21983: Should we do more to discourage custom prefs and nonstandard addons?Tue, 18 Apr 2017 16:52:00 GMTarthuredelstein<p>
We make some effort to discourage users from setting nonstandard prefs in Tor Browser, or installing 3rd-party extensions/plugins. But maybe we can do more? For example, should we pop up a warning about deanonymization when users first attempt to modify a pref or install an addon? And if users click past that warning, should be periodically pop up warnings in the future to let users know they have nonstandard prefs or a nonstandard addon installed?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/21983#changeloghttps://trac.torproject.org/projects/tor/ticket/22002
https://trac.torproject.org/projects/tor/ticket/22002#22002: Backport Mozilla's SVG-disabling patchWed, 19 Apr 2017 19:06:14 GMTarthuredelstein<p>
Mozilla partially uplifted our SVG disabling patch, but a lot of edge cases are left out that we need to add in order to use the uplifted patch.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22002#changeloghttps://trac.torproject.org/projects/tor/ticket/22075
https://trac.torproject.org/projects/tor/ticket/22075#22075: Enable speech synthesis in Reader modeWed, 26 Apr 2017 16:14:35 GMTarthuredelstein<p>
In <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/10283" title="#10283: task: SpeechSynthesis API may be fingerprintable (closed: fixed)">#10283</a> we disabled the speech synthesis API because it is fingerprintable, but it would be nice if the narrate feature worked in Reader mode. Can we patch Firefox to only disable the SpeechSynthesis API in content?
</p>
<p>
See <a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1166365"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1166365</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22075#changeloghttps://trac.torproject.org/projects/tor/ticket/22125
https://trac.torproject.org/projects/tor/ticket/22125#22125: Unit test for js localeTue, 02 May 2017 04:42:59 GMTarthuredelstein<p>
Let's introduce an automated regression test to ensure that the <code>javascript.use_us_english_locale</code> pref is applied to
</p>
<ul><li>members of <code>window.Date</code> objects
</li><li>Intl API
</li><li>toLocaleString
</li><li><code>DateTimeFormat.formatToParts</code>
</li></ul><p>
I can work on this at some point. The problem is that we need to set the LANG variable to de_DE or another non-en_US locale before starting Firefox. Maybe boklm's testing framework can do this? Or maybe it's possible in Mozilla's automated testing system, but I don't know a way yet.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22125#changeloghttps://trac.torproject.org/projects/tor/ticket/22130
https://trac.torproject.org/projects/tor/ticket/22130#22130: Use an "international" formatting for Dates etc, instead of US English localeTue, 02 May 2017 21:53:23 GMTarthuredelstein<p>
Right now we use
<code>javascript.use_us_english_locale</code>
but this is not friendly to non-US users. We should use Date formats with maximum readability across locales. For example, the ISO 8061 is pretty good, although I don't like the T in the middle.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22130#changeloghttps://trac.torproject.org/projects/tor/ticket/22584
https://trac.torproject.org/projects/tor/ticket/22584#22584: More RWX memory pages for TBB on some Windows versionsMon, 12 Jun 2017 15:08:46 GMTarthuredelstein<p>
A cypherpunk has reported some RWX memory pages were observed for Tor Browser on Windows 7 and Windows 10. See:
</p>
<ul><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21617#comment:4" title="#21617: defect: RWX page observed on Windows (closed: fixed)">ticket:21617#comment:4</a>
</li><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21617#comment:7" title="#21617: defect: RWX page observed on Windows (closed: fixed)">ticket:21617#comment:7</a>
</li><li><a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21617#comment:14" title="#21617: defect: RWX page observed on Windows (closed: fixed)">ticket:21617#comment:14</a>
</li></ul>Resultshttps://trac.torproject.org/projects/tor/ticket/22584#changeloghttps://trac.torproject.org/projects/tor/ticket/22756
https://trac.torproject.org/projects/tor/ticket/22756#22756: Only show Canvas fingerprinting prompt when there is a user interaction?Wed, 28 Jun 2017 17:46:09 GMTarthuredelstein<p>
An idea from the Mozilla SF All Hands 2017 meeting.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22756#changeloghttps://trac.torproject.org/projects/tor/ticket/22757
https://trac.torproject.org/projects/tor/ticket/22757#22757: How fingerprintable is Canvas after font whitelisting is enforced?Wed, 28 Jun 2017 17:47:45 GMTarthuredelstein<p>
Question arose at Mozilla SF All Hands 2017.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22757#changeloghttps://trac.torproject.org/projects/tor/ticket/22917
https://trac.torproject.org/projects/tor/ticket/22917#22917: Use --disable-auto-import on mingw builds of TBB and torFri, 14 Jul 2017 00:14:15 GMTarthuredelstein<p>
A cypherpunk <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/22563#comment:8" title="#22563: defect: Many memory pages in tor.exe for Windows violate W^X (closed: fixed)">pointed out</a> that we could possibly use --disable-auto-import on our mingw builds of TBB and tor. This would probably require patching Firefox as well as stack protection in gcc/mingw.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22917#changeloghttps://trac.torproject.org/projects/tor/ticket/22981
https://trac.torproject.org/projects/tor/ticket/22981#22981: Don't block audio/video on https sites under Medium SecurityWed, 19 Jul 2017 17:26:30 GMTarthuredelstein<p>
Right now "Medium Security" on the security slider blocks all audio and video using NoScript. But JavaScript is allowed for https sites. I would suggest also unblocking video and audio for https sites but keeping them blocked for http sites. This would increase usability for sites such as YouTube.
</p>
<p>
High Security would continue to block audio and video for both https and http sites.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22981#changeloghttps://trac.torproject.org/projects/tor/ticket/22982
https://trac.torproject.org/projects/tor/ticket/22982#22982: Introduce a single "adjust security" toolbar button for security slider and noscript optionsWed, 19 Jul 2017 17:35:52 GMTarthuredelstein<p>
Right now, the security slider is buried under a submenu. We could promote it to its own toolbar buttun/popup menu, similar to how ninavizz suggested in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21183" title="#21183: defect: Basic Usability Issues (closed: fixed)">#21183</a>. And we could move needed NoScript functionality (namely "temporarily whitelist video/audio/scripts for this tab") from the NoScript dropdown to the security popup. Other dangerous NoScript functionality could be omitted altogether (including "Allow Scripts Global" and "Options".
</p>
<p>
Finally the security slider button could have a decoration that indicates the current setting "H/M/L" as well as a second indicator showing whether we have temporarily whitelisted for this tab.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22982#changeloghttps://trac.torproject.org/projects/tor/ticket/22985
https://trac.torproject.org/projects/tor/ticket/22985#22985: Can we simplify and clarify click-to-play of audio/video?Wed, 19 Jul 2017 20:53:02 GMTarthuredelstein<p>
Right now click-to-play of videos is quite cumbersome and has poor usability. For example on youtube, this is what I observe on Medium Security.
</p>
<ul><li>On first page load, no video or audio is visible -- the video box is gray. A "musical notes" icon appears in the middle of the video box, and an "orbiting dots" indicator seems to indicate some problem loading. After a few seconds the video box goes black and it says "an error occured." Then after another few seconds the "musical notes" icon reappears.
</li></ul><ul><li>If I click on the "musical notes" icon, then a confirmation box appears, that says "Temporarily allow ... [URLs and codec gibberish]". If I click OK, then the whole page reloads. Again I get a gray video box with orbiting dots. This time there is a film canister icon in the middle of the dots.
</li></ul><ul><li>If I click on the film canister it says, "Temporarily allow [URL and more codec gibberish]". again I click OK, the page reloads and the video finally plays.
</li></ul><p>
So here, click-to-play required two clicks and two reloads (plus confirmation clicks). Ideally it should require only one reload. The option to click to play the video should be much more clear (it should probably have the text "Click to Play"). The click-to-play button shouldn't disappear when the youtube page tries to re-load the video. If a confirmation prompt is to be shown, then it should clearly explain to the user that video/audio is about to be loaded, and what the security concerns are.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/22985#changeloghttps://trac.torproject.org/projects/tor/ticket/23024
https://trac.torproject.org/projects/tor/ticket/23024#23024: Flags to increase hardening on WindowsMon, 24 Jul 2017 16:14:11 GMTarthuredelstein<p>
We can add <code>-fstack-protector-all</code> and <code>-D_FORTIFY_SOURCE=2</code> to our Windows build for some extra protection.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23024#changeloghttps://trac.torproject.org/projects/tor/ticket/23317
https://trac.torproject.org/projects/tor/ticket/23317#23317: Update font whitelists to reflect any changed Firefox default fontsThu, 24 Aug 2017 17:52:12 GMTarthuredelstein<p>
Masayuki Nakano writes (about Windows fonts):
</p>
<blockquote class="citation">
<p>
We decided that we should change our default Japanese fonts from legacy "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" (serif).
</p>
</blockquote>
<p>
We should consider updating "font.system.whitelist" to reflect this, although it depends on what fonts are available by default on most Windows systems. We should also check if any other default fonts have been added that we should include in our whitelists.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23317#changeloghttps://trac.torproject.org/projects/tor/ticket/23482
https://trac.torproject.org/projects/tor/ticket/23482#23482: 2017 Fundraising campaignTue, 12 Sep 2017 17:32:06 GMTarthuredelstein<p>
This ticket can be the parent for tasks for Tor Project folks related to the 2017 fundraising campaign. See <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/20413" title="#20413: defect: 2016 Fundraising campaign (closed: fixed)">#20413</a> for last year.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23482#changeloghttps://trac.torproject.org/projects/tor/ticket/23768
https://trac.torproject.org/projects/tor/ticket/23768#23768: Update code to wipe indexedDB in New IdentityWed, 04 Oct 2017 23:27:03 GMTarthuredelstein<p>
Looks like Mozilla may have fixed the issue of wiping indexedDB.
</p>
<p>
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1047098"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1047098</a>
</p>
<p>
Let's see if we can get this working in New Identity.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23768#changeloghttps://trac.torproject.org/projects/tor/ticket/23838
https://trac.torproject.org/projects/tor/ticket/23838#23838: Use OONI to inform Tor Launcher user workflowThu, 12 Oct 2017 19:58:02 GMTarthuredelstein<p>
<a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/OONI-TorBrowserCollaboration">At the Montreal meeting</a> we discussed how OONI data can be used to make the Tor Launcher workflow simpler and safer for users. Specifically, if we ask users the country in which they are located, Tor Launcher could, in some cases, decide to automatically connect to Vanilla tor, or to a specific bridge type, or to ask the users further questions. The basic data on whether Vanilla Tor will work from a given country should be available relatively soon.
</p>
<p>
This ticket can serve as a discussion/parent ticket for the data analysis, UX analysis UI design, Tor Launcher patching, etc.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23838#changeloghttps://trac.torproject.org/projects/tor/ticket/23839
https://trac.torproject.org/projects/tor/ticket/23839#23839: Testing Framework for Censorship CircumventionThu, 12 Oct 2017 20:03:39 GMTarthuredelstein<p>
<a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/OONI-TorBrowserCollaboration">At the Montreal meeting</a>, we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browser that would allow collection of data on connectivity for Tor and for different bridges and pluggable transports. OONI could collate and analyze this data to give a better picture of the per-country bridge connectivity situation. That data could be used to improve Tor Launcher's connection UX, and also help compare different censorship circumvention tools.
</p>
<p>
This can be a parent ticket for designing and developing such a module.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23839#changeloghttps://trac.torproject.org/projects/tor/ticket/23850
https://trac.torproject.org/projects/tor/ticket/23850#23850: Webpage for Tor ecosystem: List of, and links to, success storiesSat, 14 Oct 2017 02:29:53 GMTarthuredelstein<p>
Let's make a page that highlights many success stories for projects and products in the world that use Tor. (Suggested in the <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/EncouragingThirdPartyIntegrationAndOnionServicesEverywhere">Montreal meeting.</a>)
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23850#changeloghttps://trac.torproject.org/projects/tor/ticket/23851
https://trac.torproject.org/projects/tor/ticket/23851#23851: Write a "Tor Integration Guide"Sat, 14 Oct 2017 02:31:56 GMTarthuredelstein<p>
The website should have a page specifically explaining how to integrate Tor into your third-party app or product. Suggested in <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/EncouragingThirdPartyIntegrationAndOnionServicesEverywhere">the Montreal meeting</a>.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23851#changeloghttps://trac.torproject.org/projects/tor/ticket/23852
https://trac.torproject.org/projects/tor/ticket/23852#23852: Document the value of embedding Tor in third-party productsSat, 14 Oct 2017 02:36:44 GMTarthuredelstein<p>
Third party app or device creators may want to embed Tor into their app or device. What sort of value proposition can convince managers or customers that embedding Tor is a good thing to do? Let's develop a web page laying out the benefits. Suggested in <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Notes/EncouragingThirdPartyIntegrationAndOnionServicesEverywhere">Montreal meeting.</a>
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23852#changeloghttps://trac.torproject.org/projects/tor/ticket/23853
https://trac.torproject.org/projects/tor/ticket/23853#23853: Document the value of onion sitesSat, 14 Oct 2017 02:39:47 GMTarthuredelstein<p>
Why are onion services (aka hidden services) useful? Let's write a document explaining the value to website creators, explaining why they should set up a hidden site alternative to their website.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23853#changeloghttps://trac.torproject.org/projects/tor/ticket/23992
https://trac.torproject.org/projects/tor/ticket/23992#23992: Allow email subscription to blogWed, 25 Oct 2017 18:03:09 GMTarthuredelstein<p>
I think it would be very good for user engagement if we can offer a way for users to subscribe to our blog.torproject.org posts via email. I think Drupal has some modules that can make this possible.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/23992#changeloghttps://trac.torproject.org/projects/tor/ticket/24018
https://trac.torproject.org/projects/tor/ticket/24018#24018: Automate measuring connection timeouts per exitThu, 26 Oct 2017 16:25:33 GMTarthuredelstein<p>
I have been investigating connection timeouts manually, using Tor Browser in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21394" title="#21394: defect: connection timeouts are affecting Tor Browser usability (closed: fixed)">#21394</a>.
</p>
<p>
My manual test is as follows: I set Tor Browser's pref "extension.torbutton.loglevel to 3. In the Browser console, I filter for the word "TIMEOUT". Then I attempt to connect to a website, and I count the number of TIMEOUTs displayed on the browser console, such as this:
</p>
<pre class="wiki">[10-26 06:25:47] Torbutton INFO: controlPort &gt;&gt; 650 STREAM 532 DETACHED 833 2606:2800:220:1:248:1893:25c8:1946:80 REASON=TIMEOUT
</pre><p>
I repeatedly hit "New Tor Circuit for this Site" in the torbutton menu and manually write down how many timeouts were observed for each circuit. Here's my data from when I attempted to connect to example.com 50 times:
</p>
<pre class="wiki">http://example.com
00100000021000002001001001000000001000000000001000
</pre><p>
This sort of stream timeout is because, according to arma:
</p>
<pre class="wiki">it means you sent your begin cell, and then you didn't get an end cell or a connected cell after 10 seconds
</pre><p>
The dominant source of timeouts appears to be DNS resolution failures at the exit nodes. I observed almost no timeouts connecting directly to IPv4 or IPv6 addresses instead of a domain name (see <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/21394#comment:20" title="#21394: defect: connection timeouts are affecting Tor Browser usability (closed: fixed)">ticket:21394#comment:20</a>).
</p>
<p>
Regardless of the cause, I think these timeouts are causing serious damage to Tor Browser usability and we should try hard to fix it.
</p>
<p>
teor suggested some fixes to tor. In the meantime it would be great if we had an automated test that can measure the frequency of connection timeouts on a daily basis. I imagine it could generate several circuits through each exit node (both to domains and to bare IP addresses) and produce summary statistics. That would also help us know if the fixes are working or if we have any regressions in the future.
</p>
<p>
Is this something the Metrics team would be interested in working on? I see the timeout statistics on <a class="ext-link" href="https://metrics.torproject.org/torperf-failures.html"><span class="icon">​</span>https://metrics.torproject.org/torperf-failures.html</a> but I don't think that is measuring exactly the same thing.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/24018#changeloghttps://trac.torproject.org/projects/tor/ticket/24965
https://trac.torproject.org/projects/tor/ticket/24965#24965: Automatically remove metadata from images (EXIF) before uploadMon, 22 Jan 2018 23:25:34 GMTarthuredelstein<p>
We should enhance Tor Browser to wipe dangerous (EXIF or other) metadata from any images the user decides to upload (both on desktop and mobile). But keep the landscape/portrait tags. Bonus points for video/audio, or other common file formats.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/24965#changeloghttps://trac.torproject.org/projects/tor/ticket/25092
https://trac.torproject.org/projects/tor/ticket/25092#25092: check if mailto: protocol is correctly warning in Tor BrowserTue, 30 Jan 2018 19:46:24 GMTarthuredelstein<p>
<a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=440892"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=440892</a> suggests we may not be showing the user any warning for mailto: protocols, etc. Maybe our external app warning patch covers this? Or maybe not.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/25092#changeloghttps://trac.torproject.org/projects/tor/ticket/25134
https://trac.torproject.org/projects/tor/ticket/25134#25134: Import strings from all locales in torbutton import-translations.shSat, 03 Feb 2018 18:31:56 GMTarthuredelstein<p>
I have been looking at how to add more locales to Tor Browser and I noticed that tor-launcher.git and torbutton.git handle translations differently. In tor-launcher, the script <code>import-translations.sh</code> imports new strings from all locales provided by Transifex, not just the ones deploy in Tor Browser. But in torbutton, <code>import-translations.sh</code> we are only importing strings from a specific list of locales and ignoring the rest. I would suggest we should change torbutton to import all locales, because then:
</p>
<ul><li>We won't have to keep a list of locales in torbutton sync'd with Tor Browser.
</li><li>It will potentially facilitate building a multi-local Tor Browser.
</li></ul>Resultshttps://trac.torproject.org/projects/tor/ticket/25134#changeloghttps://trac.torproject.org/projects/tor/ticket/25197
https://trac.torproject.org/projects/tor/ticket/25197#25197: Design document isn't precise about "Security" and "Privacy".Fri, 09 Feb 2018 22:39:16 GMTarthuredelstein<p>
In Tor Browser, we have a "Security" Slider and various "Privacy" features. But these words are not so easily distinguished. Maybe we could think of a better words?
</p>
<p>
In any case, we should defined the two concepts very clearly in the Design document, and we should make sure we don't mix them up. For example, section 2.1 is entitled "Security Requirements" but goes on to list what I would consider privacy properties and does not include the sort of security intended to be provided by the Slider.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/25197#changeloghttps://trac.torproject.org/projects/tor/ticket/25198
https://trac.torproject.org/projects/tor/ticket/25198#25198: User manual should explain Tor Browser features moreFri, 09 Feb 2018 22:47:46 GMTarthuredelstein<p>
The user manual is excellent at describing how to use Tor Browser, but it could do with more explanation on the first page of the privacy and security features of Tor Browser, or how Tor Browser is different from other browsers.
</p>
<p>
Things we could consider include:
</p>
<ul><li>A clearer definition of fingerprinting protection
</li><li>First-party isolation (in lay terms)
</li><li>Disk avoidance
</li><li>Hardening/sandboxing
</li><li>Proxy enforcement
</li></ul><p>
All this should be kept super simple and brief! But right now the description is incomplete, I would say.
</p>
<p>
Also, in the Security Slider section, we should explain why users would use it, what protections we are trying to provide, and what the tradeoffs are.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/25198#changeloghttps://trac.torproject.org/projects/tor/ticket/25247
https://trac.torproject.org/projects/tor/ticket/25247#25247: mochitest failures for #23104 patchWed, 14 Feb 2018 04:09:11 GMTarthuredelstein<p>
I ran the mochitests for the <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/23104" title="#23104: defect: CSS line-height reveals the platform Tor Browser is running on (closed: fixed)">#23104</a> patch on our tor-browser-52.6.0esr-8.0-2 branch on Debian GNU/Linux 9.1 and I ran into the following failures:
</p>
<pre class="wiki">Passed: 3
Failed: 3
Todo: 0
failed | Line Height validation - got 20.4, expected 19.8
failed | Line Height validation - got 20.4, expected 19.8
failed | Line Height validation - got 20.4, expected 19.8
passed | Line Height validation
passed | Line Height validation
passed | Line Height validation
</pre>Resultshttps://trac.torproject.org/projects/tor/ticket/25247#changeloghttps://trac.torproject.org/projects/tor/ticket/25311
https://trac.torproject.org/projects/tor/ticket/25311#25311: Check that #18900 is still fixedTue, 20 Feb 2018 20:29:02 GMTarthuredelstein<p>
In <a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1434666"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=1434666</a> we checked in a patch that is supposed to fix the problem seen in <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/18900" title="#18900: defect: TB 6.0a5: updater doesn't work on Linux (cannot find libraries) (closed: fixed)">#18900</a>. But we should run at least a manual regression test to see that this indeed fixed the bug, and we don't need our <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/18900" title="#18900: defect: TB 6.0a5: updater doesn't work on Linux (cannot find libraries) (closed: fixed)">#18900</a> patch any more for TBB/ESR60.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/25311#changelog