Hi everyone, As we recently announced [0], we are working on a number of new anti-tracking features which are intended to change the current approach in Firefox with regards to how user’s data is shared with third-party trackers as the user browses the web.
In the old world (the status quo for now), the data sharing is a non-consensual and invisible part of browsing the web. We would like to change this model by flipping the defaults, that is, make changes to Firefox to avoid sharing user’s data with third-party trackers by default, and also make the data sharing, where it happens, more visible and controllable by the user. As part of these efforts we are experimenting with a new cookie policy [1] that will block trackers from accessing cookies and other storage while in a third-party context. One of the new mechanisms that we would like to expose to web developers is to ask for consent in order to gain access to the user’s data in a third-party context. We are going to do this by adopting the Storage Access API [2] implemented by Safari for a very similar purpose. At a high-level, the Storage Access API allows content in third-party frames to request access to storage on a specific first party that would otherwise be blocked by our new policy. Safari uses this API as part of their Intelligent Tracking Prevention [3] feature, and there are some differences in the edge cases of how that feature works compared to our new cookie policy. We discuss this in more detail below, but the main differences include: - In our implementation, once Storage Access API grants storage access, all existing third-party iframes on the same first party will receive that storage access, whereas in WebKit’s implementation they each would require calling requestStorageAccess() separately. - In our implementation, all future resource loads from a third party that has been granted storage access will also be granted access on the same first party. This includes access to third-party cookie headers for content embedded into the main context of the page. - In our implementation, once the Storage Access API grants storage access, all newly created third-party iframes of the same origin will have storage access for a period of time (currently defined at 30 days) without calling requestStorageAccess() again, whereas in WebKit’s implementation they’d need to reaffirm their access by calling the API again. - In our implementation, when the promise returned from requestStorageAccess() is resolved, the third-party context will have access to its full first-party cookie jar. That includes things like cookies, localStorage, IndexedDB, DOM Cache, and so on. In WebKit’s current implementation, only access to cookies will be granted. - In our implementation, we phase out the granted storage access permissions after a number of days passed, whereas in WebKit’s implementation they phase out the permissions after a number of days of browser usage passed. We don’t necessarily believe that a model where the user is asked whether they consent to sharing their data with third-party trackers is ideal, because explaining the implications of the data sharing is very hard, and there are many problems associated with asking for permission from the user. But we are looking at this API as a programmatic hook into the point in time when a third-party context would like to obtain full storage access rights, which would allow the browser to perform various forms of security/privacy checks at that time. Prompting the user is only one of the options we’ve thought about so far. Note that the API limits granting access only to callers coming at times when processing a user gesture. Summary: Storage Access API is used to grant first-party storage access to third-party embedded content under some browser controlled conditions. [2] Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1469714 Link to standard: No standard exists yet, this is being discussed in https://github.com/whatwg/html/issues/3338. Platform coverage: All platforms. Estimated or target release: Unclear as of yet (an intent to ship will be sent later when a decision to ship has been made). Preference behind which this will be implemented: dom.storage_access.enabled Is this feature enabled by default in sandboxed iframes? No, the allow-storage-access-by-user-activation sandbox flag enables it. DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1462372. We will be filing more specific bugs as we work through the scenarios where devtools can assist web developers in order to use this functionality. Do other browser engines implement this? Shipped in Safari 11.1, no public signals from Chrome or Edge. web-platform-tests: Our implementation unfortunately doesn’t come with web-platform-tests, for two reasons. One is that there is currently no way to mock user gestures in web platform tests [4], and the second reason is that furthermore, our implementation also depends on being able to manipulate the URL Classifier backend for testing purposes. Is this feature restricted to secure contexts? No, because we would like to be compatible with the WebKit implementation of this feature in terms of exposure, which is already shipped to all contexts. How stable is the spec: Safari is the only browser currently shipping the feature, and we may be the 2nd browser if we get to that point soon. Safari has changed some of the semantics around the API in ITP 2.0 recently. It’s possible for there to be further changes to the API before we’re ready to ship. We’ll be working closely with other vendors who are interested in collaborating on this space. Security & Privacy Concerns: - Does this specification deal with personally-identifiable information? The API doesn’t expose new PII to the Web. It does permit the exposure of PII to contexts where the browser would block such exposure by default. The API is designed to allow the browser to intervene in the decision of whether to grant storage access to a third party resource (e.g. through the use heuristics, by prompting the user, etc.). We haven’t yet settled on how to address this question in our implementation. Note that, in the most permissive of possible implementations, this API exposes no more information than is currently available in the default cookie policy of Firefox. This does not provide a way for third parties to access storage that would otherwise not be accessible today. - Does this specification deal with high-value data? Certainly, for example login tokens potentially stored in cookies; see the bullet point above. - Does this specification introduce new state for an origin that persists across browsing sessions? The specification does not mandate this, but our current implementation remembers an affirmative grant of storage access to a given third party under a first-party domain for 30 days. This state can be cleared when clearing the site data through the existing UI the browser exposes. This part of the design is subject to change. - Does this specification expose persistent, cross-origin state to the web? No. - Does this specification expose any other data to an origin that it doesn’t currently have access to? No. - Does this specification enable new script execution/loading mechanisms? No. - Does this specification allow an origin access to a user’s location? No. - Does this specification allow an origin access to sensors on a user’s device? No. - Does this specification allow an origin access to aspects of a user’s local computing environment? No. - Does this specification allow an origin access to other devices? No. - Does this specification allow an origin some measure of control over a user agent’s native UI? No. - Does this specification expose temporary identifiers to the web? No. - Does this specification distinguish between behavior in first-party and third-party contexts? Yes, see the algorithm in the whatwg/html issue. - How should this specification work in the context of a user agent’s "incognito" mode? Our current implementation doesn’t grant storage access to documents loaded in private windows. - Does this specification persist data to a user’s local device? As explained above, an affirmative result of the API call will be persisted locally for 30 days. - Does this specification have a "Security Considerations" and "Privacy Considerations" section? No. - Does this specification allow downgrading default security characteristics? No. Web designer / developer use-cases AKA Why a developer would use Feature X? This feature will be useful for web developers working on websites that require storage/cookie access when embedded in a third-party context. It allows the developer to gain access to the first-party storage area (cookie jar) of the website when it is embedded in third-party contexts. Example: The following code samples shows a typical way in which this API could be used in Firefox: function storeData() { window.localStorage[‘foo’] = 42; } try { storeData(); } catch (e) { document.requestLocalStorage().then(storeData, errorHandler); } [0] https://blog.mozilla.org/futurereleases/2018/08/30/changing-our-approach-to-anti-tracking/ [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1473978 [2] https://webkit.org/blog/8124/introducing-storage-access-api/ [3] https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/ [4] https://github.com/web-platform-tests/wpt/issues/7156 Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
