Opened 5 years ago

Closed 5 years ago

#15580 closed task (fixed)

Update design doc for TBB 4.5

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-4.5-alpha, TorBrowserTeam201505
Cc: gk, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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/

Child Tickets

Attachments (5)

Change History (19)

comment:1 Changed 5 years ago by gk

Cc: gk added

comment:2 Changed 5 years ago by gk

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.

comment:3 Changed 5 years ago by gk

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.createObjectURL to 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 in

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

comment:4 Changed 5 years ago by mikeperry

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.

comment:5 Changed 5 years ago by mikeperry

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.

comment:6 Changed 5 years ago by mikeperry

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.

comment:7 Changed 5 years ago by mcs

Cc: brade mcs added

comment:8 Changed 5 years ago by gk

Attached is a second patch proposing another round of minor fixes and clarifications. I am starting now with the ideas I had for the fingerprinting section.

comment:9 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201505 added; TorBrowserTeam201504 removed

comment:10 Changed 5 years ago by gk

The third patch is just fixing two typos (HEAD points to 3d07e2d54d2944bd182145908399bc01c7bbe791).

Changed 5 years ago by gk

Attachment: 0001-Typo-fixes.patch added

comment:11 Changed 5 years ago by gk

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.

Last edited 5 years ago by gk (previous) (diff)

comment:12 Changed 5 years ago by gk

Okay, I attached the update for the fingerprinting section as well. Looking at all the changes it seems we forgot to document media.webaudio.enabled in the slider itself? Or am I missing something?

comment:13 Changed 5 years ago by gk

Just one final patch with minor typo fixes and stuff. This looks reaaaaally great now, thanks!

Changed 5 years ago by gk

Attachment: 0001-minor-fixes.patch added

comment:14 Changed 5 years ago by mikeperry

Resolution: fixed
Status: newclosed

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!

Note: See TracTickets for help on using tickets.