Apologies for my slowness! On Thu, Apr 6, 2023 at 2:01 AM Mike Taylor <miketa...@chromium.org> wrote:
> On 4/4/23 11:51 PM, Yoav Weiss wrote: > > Thanks for working on this!! > Aligning with Safari and Firefox on this means that this is important not > just for user privacy, but also from an interop perspective. It also gives > us some confidence that this deprecation can be successful. > > This is effectively a deprecation, but one where I can't think of a > reasonable way to measure usage, so it seems to me that a careful rollout + > deprecation trial (as you're suggesting) is the way to go here. > > Yeah, I'm hopeful that the web has adjusted to this as the norm given > Firefox and Safari's behavior, but we know that Firefox had some site > breakage to deal with when they first introduced the feature, so I'd rather > be cautious with the rollout to avoid any major incidents. > > Is the deprecation trial enabled as a 3P OT? That may ease the deployment > for platform providers that have a hard time shipping header changes to a > large set of origins. > > We made the decision to not support 3Ps for the deprecation trial. > Instead, when a site enables the Deprecation trial, all of its embedded > frames will have a 1st party StorageKey. Our thinking was that we wanted > the embedder to be in control of its users' storage, rather than the > embeddee. But if this turns out to be untenable, we're open to considering > making this work as a 3P trial as well. > The scenario I'm slightly concerned about is a large platform (ecommerce, CRM, etc) with a ~gazillion different customer origins, that is currently relying on any of these APIs to communicate common state (e.g. checkout flows). Such a platform would most probably be able to opt-in using a 3P OT (by delivering a common origin script that does the opt-in), but may not be able to opt-in each origin individually. It's probably fine to make sure that only the top-level frame can participate in the 3P OT, although I'm not 100% sure if that's how 3P OTs are currently wired. +Panos Astithas <pastit...@google.com> may know. Also, have we reached out to the usual suspects to make sure they test this > change ahead of time? > > We have been in touch with some partners through our partnership team, and > other top sites as well. :) > > > On Wed, Apr 5, 2023 at 12:44 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> *Contact emails* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * wanderv...@chromium.org <wanderv...@chromium.org>, m...@chromium.org >> <m...@chromium.org>, mikety...@chromium.org <mikety...@chromium.org> >> Explainer >> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md >> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md> >> Specification Partitioned Storage is roughly specified at >> https://privacycg.github.io/storage-partitioning/ >> <https://privacycg.github.io/storage-partitioning/>. As part of this work, >> we have started to codify the necessary concepts in HTML, DOM, and Storage >> in the following PRs: https://github.com/whatwg/storage/pull/144 >> <https://github.com/whatwg/storage/pull/144> >> https://github.com/whatwg/dom/pull/1142 >> <https://github.com/whatwg/dom/pull/1142/files> >> https://github.com/whatwg/html/pull/8447 >> <https://github.com/whatwg/html/pull/8447> We have also updated other APIs >> to use StorageKey (ServiceWorker [1 >> <https://github.com/w3c/ServiceWorker/pulls?q=is%3Apr+is%3Aclosed+partition>], >> BroadcastChannel [1 <https://github.com/whatwg/html/pull/7567>], >> SharedWorker[1 <https://github.com/whatwg/html/pull/7995>]), and landed >> necessary additions to Storage itself ([1 >> <https://github.com/whatwg/storage/commit/bea19b70f497d7059c920b9f0a81ac8f49bd36ed>][2 >> <https://github.com/whatwg/storage/commit/c68c38413c02496114d51af28caa83d11689d300>]). >> What we thought to be a straightforward set of changes has evolved to be a >> more complex refactoring, per the request of HTML editors. We propose to >> ship with a WIP spec spread out across the PRs above (noting that Firefox >> and Safari have already shipped partitioned storage). That said, we intend >> to finish this work. Summary We intend to partition a number of APIs in >> third-party contexts. This effort is focused on partitioning APIs above the >> network stack. This includes quota-managed storage, service workers, and >> communication APIs (like BroadcastChannel). See the explainer for more >> details: >> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md >> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md> >> Blink component Blink>Storage TAG review >> https://github.com/w3ctag/design-reviews/issues/629 >> <https://github.com/w3ctag/design-reviews/issues/629> TAG review status >> Resolution: Satisfied Risks Interoperability and Compatibility Given that >> Firefox and Safari have already shipped this feature, we expect our >> implementation to be interoperable. We are aware of breakage >> <https://github.com/privacycg/storage-partitioning/issues/34#issuecomment-1194358637> >> for sites that use Firebase for authentication (because it relies on being >> able to access unpartitioned sessionStorage). Firebase has blogged on how >> sites can mitigate this issue >> <https://firebase.google.com/docs/auth/web/redirect-best-practices>. We >> built a deprecation trial specifically for the sessionStorage redirect use >> case, which should work for Firebase users. In addition, we have a general >> deprecation trial available and enterprise policies in place. See below for >> more info on the deprecation trials. We’ve made storage partitioning >> available for local testing in Chrome for the past 6 months >> <https://developer.chrome.com/en/blog/storage-partitioning-dev-trial/>. >> Apart from Firebase, we’re not aware of any existing compatibility issues >> that can’t be solved by the deprecation trials >> <https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/>. >> There may be unforeseen contexts and use cases that rely on unpartitioned >> storage and as such, we propose to roll this feature out carefully via >> Finch, according to the following proposed schedule: May 9th: 1% of Stable >> population (approximately 1 week after M113 is released) May 23rd: 10% June >> 6th: 50% June 20th: 100% As usual, if we identify concerning metrics, >> regressions, or site breakage reports, we may pause or roll back to >> investigate or address issues. Deprecation trial instructions: >> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ >> <https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/> >> Gecko: Shipped/Shipping WebKit: Shipped/Shipping Web developers: Mixed >> signals. Some developers have expressed compatibility concerns, others have >> been supportive. Other signals: WebView application risks Does this intent >> deprecate or change behavior of existing APIs, such that it has potentially >> high risk for Android WebView-based applications? No, we don’t intend to >> turn this on for WebView yet. Debuggability DevTools has support for >> partitioned storage. Will this feature be supported on all six Blink >> platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >> No (not WebView) Is this feature fully tested by web-platform-tests? Yes. >> We’ve written WPTs to verify our 3rd party storage partitioning. Flag name >> ThirdPartyStoragePartitioning Requires code in //chrome? Nope Tracking bug >> https://bugs.chromium.org/p/chromium/issues/detail?id=1191114 >> <https://bugs.chromium.org/p/chromium/issues/detail?id=1191114> Launch bug >> https://launch.corp.google.com/launch/4214498 >> <https://launch.corp.google.com/launch/4214498> Anticipated spec changes >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (in other words, links to known >> GitHub issues in the project, for the feature specification) whose >> resolution may introduce web compat/interop risk (such as changes to naming >> or structure of the API in a non-backward-compatible way). None Link to >> entry on the Chrome Platform Status >> https://chromestatus.com/feature/5723617717387264 >> <https://chromestatus.com/feature/5723617717387264> Links to previous >> Intent discussions Intent to Prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/FNi-nNC8fiw/m/gNftPAzUBgAJ >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/FNi-nNC8fiw/m/gNftPAzUBgAJ> >> * >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e8540107-85b2-a113-6347-1290c23f6379%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e8540107-85b2-a113-6347-1290c23f6379%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU%2BjPmtD-%2BvZvsfgyHjJgWJ3bF3LOE_iC4cAH_xDVERww%40mail.gmail.com.
