Clarify section 3.14 and add Third Party Tracking as an opt-in threat model

[diracdeltas]

Migrated from mikewest/spec-questionnaire#6

@mikeperry-tor wrote:

It seems that the question in section 3.14 ("Does this specification distinguish between behavior in first-party and third-party contexts?") is very easy to misinterpret or overlook entirely, even though it is absolutely essential to any evaluation of an API from a privacy perspective.

For example, I could easily see a specification that decides that this section is satisfied simply by allowing for the third party script to detect its context, and then decide for itself how it wants to use the API (independent of any considerations of tracking, consent, or user control).

Something like this would be a bit stronger and clearer:

"At minimum, every new API or feature should be capable of being configured by the user to gracefully degrade into a functional mode of operation that does not allow third party content elements to use it to track unique users between different first party sites. Specifically, any storage, authentication tokens, shared state, and cross-window communication should be capable of being isolated between different first party origins, at user option.

For detailed guidance on how to provide graceful degradation to protect against more subtle forms of tracking that do not involve direct communication or unique identifier storage (aka 'fingerprinting'), we refer the reader to https://w3c.github.io/fingerprinting-guidance/."
In Tor Browser, we've implemented graceful degradation of the browser cache and DOM storage APIs by double keying all entries using both the first party and third party origin. This allows third party elements to continue to use this functionality in iframes and mashups, but prevents them from using the functionality to track users between different first party sites. In other cases, we've simply had to disable offending functionality (due to lack of engineering resources), which obviously has a significant impact on usability when things break.

If new APIs and feature specifications came with graceful degradation modes that did not require disabling them outright, the web would be a much better place.

If it were up to me, I would also elevate "Third Party Tracking" to a threat model that users could opt-in to protect themselves against, and specify this in the threat model section. All features should be capable of allowing the user to select this threat model via a single choice in their browser UI that applies to all browser features (instead of being given control only over third party cookies, as is the case today).

I can submit a pull request for this threat model addition if you like.

@marcoscaceres commented:

@mikeperry-tor I'm having trouble understanding:

"At minimum, every new API or feature should be capable of being configured by the user to gracefully degrade into a functional mode of operation that does not allow third party content elements to use it to track unique users between different first party sites."
Can you maybe follow that by a couple of examples to clarify what you mean? Or how it could be done with some other existing APIs?

[diracdeltas]

I agree that "Does this specification distinguish between behavior in first-party and third-party contexts?" is not strong enough but OTOH, @mikeperry-tor's examples sound more like an issue with browser implementation than the feature specification itself. Perhaps I'm not understanding - are there examples of features that prevent techniques like double-keying at the specification level?

[diracdeltas]

If it were up to me, I would also elevate "Third Party Tracking" to a threat model that users could opt-in to protect themselves against, and specify this in the threat model section. All features should be capable of allowing the user to select this threat model via a single choice in their browser UI that applies to all browser features (instead of being given control only over third party cookies, as is the case today).

I can submit a pull request for this threat model addition if you like.

I am in favor of this addition.

[mikeperry-tor]

Are there examples of features that prevent techniques like double-keying at the specification level?

Typically they tend to impede compatible, gracefully degrading implementations of these techniques through neglect of treatment of third party tracking. This leads website developers to create sites that rely on a particular type of functionality behaving in a way that is incompatible with isolation in unpredictable and/or breakage-inducing ways.

Four examples:

• URL.createObjectURL creates blob URL UUIDs that may be sourced from any origin. The spec seems unclear on this point, but the Firefox implementation allows image src, script src, iframe, and other accesses to succeed. A hypothetical example of breakage would be if a site stores my account's current avatar/availability status in a blob URL and expects to be able to display it in like buttons or federated login choices on arbitrary sites.
• SharedWorker threads specify that if the user agent is choosing to isolate third party content, the scope (and presumably the reflected self object) should be set to null (https://html.spec.whatwg.org/multipage/workers.html#sharedworker). Unfortunately, this is described as a developer feature, not an anti-tracking feature, and so none of the developer docs describe this potential breakage-inducing variant in functionality. It would make more sense if this object was non-null, but not shared, and the specification was clear that content should not rely on the self property to contain values they expected, or share state, documents, and event handlers how they expect. I'm also unclear based on the spec how the application cache or the document list should behave..
• HTTP/2 section 9.1 (https://http2.github.io/http2-spec/#rfc.section.9.1) specifies that clients SHOULD NOT create more than one connection to a site, where as in Tor Browser, we will be creating a new connection to sites that are loaded under different top-level first party domains. This is unlikely to cause breakage, but it is a worrying thing to see specified.
• In cases like HSTS and possibly also CSP upgrades (https://w3c.github.io/webappsec/specs/upgrade/), to avoid supercookies we will likely ignore cached HSTS and CSP state for third parties when the first party is HTTP, and simply block third party elements that would have been upgraded because of previously cached rules when the first party is HTTPS. This may lead to situations where sites rely on this caching functionality to deploy HTTPS properly, and those sites will break when isolation is enabled.

Let me know when any pull requests should be submitted, and what form they should take.

[mnot]

An example of doing this (comparatively) well in a spec is Canvas, which has the origin-clean flag http://www.w3.org/TR/html5/scripting-1.html#security-with-canvas-elements. The only issue I have with it is that it says the flag MUST start as 'true', whereas someone might want to default it to false (thereby making the canvas unreadable).

I had thought that privacy mode might be one thing that took advantage of these kinds of hooks in the specs to give users control. It probably isn't the right thing to do this with, but there could eventually be some sort of mode like it -- either in the standards our outside of them (like TorBrowser has done) that takes advantage of them.

So, +1 from me, even if browsers don't surface controls immediately, having these controls in the specs is important.

WRT H2 connection coalescing and similar things - this is actually being discussed right now, see w3c/resource-hints#32.

[diracdeltas]

@mikeperry-tor Thanks, you can submit pull requests at any time to this repo. The earlier the better since some specs are already using this doc for review, ex: #1

[lknik]

Hello.

Tough one. But I want to dust-off and move the SP-Q forward at some point.

To simplify this point (and discussion above, and sorry for not treating the point as the core element of the questionnaire), I'll include:

Third-party tracking may occur when content from one origin is embedded or otherwise injected in another origin in a way that information may be accessed, revealed, queried or reasoned by third-party. This third-party may be a script injected on a first-party site

• The simplest example is injecting a link to a site that behaves differently under specific condition, for example based on the fact that user is or is not logged to the site. This may reveal that the user has an account on a site.