Update design doc for TBB 4.5
We need to update the Tor Browser design doc to cover the changes in TBB 4.5 since 4.5-alpha-1.
Once this is done, we should send the link to Nick Doty along with some suggestions for https://w3c.github.io/fingerprinting-guidance/
Activity
I sent some feedback to tbb-dev: https://lists.torproject.org/pipermail/tbb-dev/2015-April/000264.html. Section 5.2 there would benefit from some insights that are gained from our Tor Browser experience.
-
I have feedback up to the fingerprinting part. The two bigger things in the attached patch are that tracking with HTTP works perfectly fine without having JavaScript enabled and that we did not fully isolate
URL.createObjectURLto the URL bar domain but rather just disable it in worker contexts for now. One thing that confused me and is not reflected in the patch is the "IP address, Tor Circuit, and HTTP Keep-Alive linkability" part. I did not really get what the IP address isolation adds/means in this context. And mixing somehow IP address unlinkability and Tor circuit unlinkability inThe Tor client has logic to prevent connections with different SOCKS usernames and passwords from using the same Tor circuit, which provides us with IP address unlinkability.makes it a bit confusing. I think we should just omit the IP address references and talk about Tor circuit unlinkability in these cases. This makes the point in a straightforward way without distinguishing between both.
I like the fingerprinting introduction really well. It occurred to me that we can make our position even clearer but then I got distracted by the HTTP submission. I'll provide a second patch for that and review the rest of it as soon as I can. Might not be tomorrow or over the weekend but I am optimistic that we can send the mail to Nick on Monday.
On IRC, Georg pointed out that we should motivate and explain our preference for uniformity rather than randomness, and specifically cite the PriVaricator paper in that discussion (http://research.microsoft.com/pubs/209989/tr1.pdf). We were thinking this is best done in a subsection like "Randomization vs Uniformity", either before or after the "Sources of Fingerprinting Issues" subsection.
Georg thinks it may be more useful to have before the sources list, because while reading "Device and Hardware Characteristics", he noticed that we omit the fact that we also reduce hardware info by reporting less screen resolution info, and set WebGL into minimal mode, and do other similar things to achieve uniformity beyond just site permissions and disabling APIs.
I am currently of the opinion that it is most important to get the sources described up front, as that will help us motivate our choice for uniformity by referring to the different sources where it may or may not work. I think clarifying the Hardware section can be done with a separate sentence, without going down the full rabbit hole of uniformity vs randomness until later.
I will think about this and if I have time, update the doc tonight/tomorrow with an attempt at this section, and see how it feels.
-
More notes to add to Georg's list when we do this update pass: I think we should also rework the Identifier Linkability intro to more explicitly describe first party isolation, as well as generalize "Open TCP Port Fingerprinting" item to "Open TCP Port and Local Network fingerprinting" or something similar.
-
Another note: Briefly mention timezone and clock offset as part of the End-User Configuration Details section.
We probably should also put Layer 8 Fingerprinting (ie user behavior) somewhere (or declare it mostly out of scope), since we do have a defense section on Keystroke fingerprinting that we need to support.
-
Trac:
0001-Typo-fixes.patch -
When first party isolation is used with explicit identifier storage that already has a constrained third party scope (such as cookies, DOM storage, and cache)Hm... why do you think DOM storage and the browser caches have a constrained third party scope? SafeCache is basically the result of trying to apply the idea of a third party scope afterwards. And DOM storage, well, there is a small "may" in the spec (http://dev.w3.org/html5/webstorage/#user-tracking):
User agents may restrict access to the localStorage objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.And Mozilla did not manage to implement that "may" yet due to various concerns/issues: https://bugzilla.mozilla.org/show_bug.cgi?id=536509
Thus, if we want to add examples unconditionally as you did (which is a good idea) just having cookies there seems better.
-
Trac:
0001-minor-fixes.patch -
Ok, applied this. Wrt the earlier comments: media.webaudio.enabled is documented in the slider section. Also, wrt cache and DOM storage isolation, they indeed are scoped to third party already. When you source a third party element that uses DOM storage, other third parties cannot access its stored elements due to the same origin policy. It's first party isolation we add there. However, I think you're right about the cache -- the same origin policy is only applied to third party images, stylesheets, and scripts if they are inside a frame or iframe. Since this is less strict than our notion of third parties, I have removed mention of the cache.
Calling this closed. Sending it to Nick now!
Trac:
Status: new to closed
Resolution: N/A to fixed mentioned in issue #15598 (moved)
mentioned in issue tpo/web/trac#15598 (closed)
