{"action":"created","issue":{"url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/7","labels_url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/7/comments","events_url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/7/events","html_url":"https://github.com/w3ctag/security-questionnaire/issues/7","id":75339586,"number":7,"title":"Clarify section 3.14 and add Third Party Tracking as an opt-in threat model","user":{"login":"diracdeltas","id":549654,"avatar_url":"https://avatars.githubusercontent.com/u/549654?v=3","gravatar_id":"","url":"https://api.github.com/users/diracdeltas","html_url":"https://github.com/diracdeltas","followers_url":"https://api.github.com/users/diracdeltas/followers","following_url":"https://api.github.com/users/diracdeltas/following{/other_user}","gists_url":"https://api.github.com/users/diracdeltas/gists{/gist_id}","starred_url":"https://api.github.com/users/diracdeltas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/diracdeltas/subscriptions","organizations_url":"https://api.github.com/users/diracdeltas/orgs","repos_url":"https://api.github.com/users/diracdeltas/repos","events_url":"https://api.github.com/users/diracdeltas/events{/privacy}","received_events_url":"https://api.github.com/users/diracdeltas/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-05-11T19:59:58Z","updated_at":"2015-05-11T23:07:22Z","closed_at":null,"body":"Migrated from https://github.com/mikewest/spec-questionnaire/issues/6\r\n\r\n@mikeperry-tor wrote:\r\n\r\n> 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.\r\n> \r\n> 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).\r\n> \r\n> Something like this would be a bit stronger and clearer:\r\n> \r\n> \"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.\r\n> \r\n> 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/.\"\r\n> 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.\r\n> \r\n> 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.\r\n> \r\n> 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).\r\n> \r\n> I can submit a pull request for this threat model addition if you like.\r\n\r\n@marcoscaceres commented:\r\n> @mikeperry-tor I'm having trouble understanding:\r\n> \r\n> \"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.\"\r\n> 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?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/comments/101071300","html_url":"https://github.com/w3ctag/security-questionnaire/issues/7#issuecomment-101071300","issue_url":"https://api.github.com/repos/w3ctag/security-questionnaire/issues/7","id":101071300,"user":{"login":"mikeperry-tor","id":7707841,"avatar_url":"https://avatars.githubusercontent.com/u/7707841?v=3","gravatar_id":"","url":"https://api.github.com/users/mikeperry-tor","html_url":"https://github.com/mikeperry-tor","followers_url":"https://api.github.com/users/mikeperry-tor/followers","following_url":"https://api.github.com/users/mikeperry-tor/following{/other_user}","gists_url":"https://api.github.com/users/mikeperry-tor/gists{/gist_id}","starred_url":"https://api.github.com/users/mikeperry-tor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikeperry-tor/subscriptions","organizations_url":"https://api.github.com/users/mikeperry-tor/orgs","repos_url":"https://api.github.com/users/mikeperry-tor/repos","events_url":"https://api.github.com/users/mikeperry-tor/events{/privacy}","received_events_url":"https://api.github.com/users/mikeperry-tor/received_events","type":"User","site_admin":false},"created_at":"2015-05-11T23:07:21Z","updated_at":"2015-05-11T23:07:21Z","body":"> Are there examples of features that prevent techniques like double-keying at the specification level?\r\n\r\nTypically 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.\r\n\r\nFour examples:\r\n* 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.\r\n* 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..\r\n* 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.\r\n* 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.\r\n\r\nLet me know when any pull requests should be submitted, and what form they should take."}}