I share the concerns around compat risk and making the platform less predictable for businesses. But I also don't see any alternative given that at least Google Chrome is going ahead with strong tracking protection and Firefox and Safari already have this. I assume the codebase will support both partitioned and unpartitioned storage for some time into the future due to enterprise policy and perhaps other knobs that might impact Chrome, and so other embedders like Edge are free to apply their own policy around when the partition storage and when not, right Mike? The existing deployment experience, data from other browsers, finch-controlled rollout & killswitch, dev trials, enterprise policy knob and webview opt-out seem like the complete suite of relevant compat mitigation risks. So I'm OK with this proceeding from a web compat perspective as you see fit Mike.
In terms of the standards / process piece, it looks as if the spec PRs have all stalled for several months. What do you think is necessary to get these unblocked and landed? As the last engine to implement this behavior, perhaps we shouldn't feel too compelled to block shipping on PRs landing? What about WPT or other interop testing? Are there any known cases where behavior is observably different between engines and any test cases we can provide to help quantify that and encourage alignment? Thanks, Rick On Tue, Apr 25, 2023 at 10:52 AM Mike Taylor <miketa...@chromium.org> wrote: > On 4/24/23 2:11 PM, Yoav Weiss wrote: > > 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. > > Yeah, that's a fair concern. To date, we're not aware of any such use > cases or site breakage - but that doesn't mean it's not out there. :) We > have engaged with one large enterprise SaaS platform to encourage early > testing last September, and thus far haven't heard anything concerning from > them. > > We're hoping that turning this on at 1% might flush out some of these > possible scenarios and help us decide if we need to re-think how the > Deprecation Trial works, or even the launch plan (perhaps launching behind > the "Block 3P cookies" setting to start with). After thinking a bit more, > it probably makes sense to hold at 1% for longer than the original 2 weeks, > perhaps 4 weeks instead. Given that Gecko and WebKit have already shipped > partitioned storage, I'm hopeful that things aren't so dire - but we may > just discover how much of the web isn't tested or supported in those > engines. > > > 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/482f0215-8ded-fe8b-9765-423567625f41%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/482f0215-8ded-fe8b-9765-423567625f41%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/CAFUtAY-7qzcCaDaNvTd-7d9wZCD3%2Bqj6OyYUqKy2P3Oex3dawA%40mail.gmail.com.
