Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs
Mike Taylor
Contact emails
wande...@chromium.org, m...@chromium.org, mike...@chromium.org
Explainer
https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
Specification
Partitioned Storage is roughly specified at 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/dom/pull/1142
https://github.com/whatwg/html/pull/8447
We have also updated other APIs to use StorageKey (ServiceWorker [1], BroadcastChannel [1], SharedWorker[1]), and landed necessary additions to Storage itself ([1][2]).
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
Blink component
Blink>Storage
TAG review
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 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. 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. Apart from Firebase, we’re not aware of any existing compatibility issues that can’t be solved by the deprecation trials. 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/
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
Launch bug
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
Links to previous Intent discussions
Intent to Prototype: 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
Yoav Weiss
--
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+...@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.
Eli Grey
Mike Taylor
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.
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.
Also, have we reached out to the usual suspects to make sure they test this change ahead of time?
Mike Taylor
Hi Eli,
Correct, we're not deprecating third-party cookies with this
change - you can learn more about the timeline
for that here. I don't understand the setup of your use
case, or which safer APIs you're referring to - some more info
would be useful (also feel free to email me and the folks in cc
directly, if you prefer).
Can I ask how you handle users on Firefox and Safari? This change moves us to align with their storage model.
thanks,
Mike
Eli Grey
Chris Fredrickson
If I can chime in on a few points from the First-Party Sets perspective:
- Do you plan to use First-Party Sets to put your consent management site in the same FPS as your customers' sites? (Note that you would have to work around the FPS disjointness requirement, e.g. using CNAMEs.) That would allow your product to continue to do limited cross-site data sharing, although it would have to use cookies to do so.
- FYI, both the Storage Access API and Chromium's proposed extension (requestStorageAccessFor) only unblock access to unpartitioned cookies; they do not unblock access to unpartitioned storage. (You may already know this, since you linked to the relevant Storage Access API issue.) Please feel free to comment on that issue if it would address a critical use case for your product.
- If you're expecting to use First-Party Sets to enable limited cross-site data sharing, you may be interested in https://github.com/WICG/first-party-sets/issues/111 and/or https://github.com/WICG/first-party-sets/issues/94 (which admittedly is related to cookies). Please feel free to comment on those issues if either of them would address your use case; we're actively looking for feedback to help us shape and motivate/prioritize those proposals.
Elijah Grey
Eric Lawrence
I understand the drive to do this (neutering 3P cookies without neutering all of their replacements is of questionable value), but it does feel like a huge loss for the power of Web Platform. BroadcastChannel will turn into BroadcastChannelExceptInSomeCasesThatAreHardToReasonAbout.
Domenic Denicola
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/42a5bada-46cb-4508-8e63-fa88ea0570a1n%40chromium.org.
Alex Russell
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9SnUy3iPaqspOQyWZ1eoE5cA88JHJ5p6GjZ_RaFv25CQ%40mail.gmail.com.
Eric Lawrence
Mike Taylor
Right, it's lumped under the Communication API section of the
explainer. We could call it StorageKey Partitioning to be more
precise, but I'm not sure that gains us much.
Mike Taylor
Hi Eric,
On 4/13/23 8:13 PM, Eric Lawrence wrote:
What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc.
When we change longstanding behaviors, we break existing code, and force web developers (or their customers) to try to figure out why their site works in one context (e.g. directly navigated), and not in another (e.g. inside the Company Portal website).
Introducing partitioning where it was not in use before is particularly challenging because in most cases there's no obvious explanation of what went wrong: Data just disappears.
This makes the web platform feel unpredictable and unstable as a platform to build atop.
Ben Kelly
What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc.
Ben Kelly
Chris Fredrickson
Hi Chris,I appreciate your response. Here are my responses to your points:1. Yes, we plan to use FPS to put our consent management tool in the same FPS (using <customer-id>.sync.transcend.io as a service domain per customer, alternatively CNAME-backed by the customer). We will still be forced to reduce customers' users' privacy by sharing user consent data through cookies (and completely lose our ability to sync quarantine data cross-site as it cannot safely be included in network requests through cookies).
Elijah Grey
Yoav Weiss
On 4/4/23 11:51 PM, Yoav Weiss wrote:
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.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.
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.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.
Chris Fredrickson
Mike Taylor
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 <mike...@chromium.org> wrote:
On 4/4/23 11:51 PM, Yoav Weiss wrote:
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.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.
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.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.
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 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.
Rick Byers
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.
Mike Taylor
Hi Rick,
On 4/25/23 12:00 PM, Rick Byers wrote:
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?
We have added a number of tentative WPTs (tentative until we land
the spec bits) to ensure that we don't regress partitioned storage
and match what other browsers are doing.
The one major difference that comes to mind is that we intend to ship blob URLs partitioned by StorageKey - it's been an open question whether to partition by StorageKey or agent cluster (see https://github.com/w3c/FileAPI/issues/153). Our plan was to start with StorageKey then investigate if agent cluster partitioning is feasible, but given that Firefox had to turn it off due to compat reasons (see https://bugzilla.mozilla.org/show_bug.cgi?id=1728192#c3 and associated regressions in https://bugzilla.mozilla.org/show_bug.cgi?id=1658878), StorageKey seems like the more compatible option for now.
Mike Taylor
> On 4/25/23 12:00 PM, Rick Byers wrote:
>
>> 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?
question - oops.
Right now it seems to me that the costs of landing these spec PRs is
higher than we're willing to block on, given the requested refactoring
(and yes, it's unfortunate that 3 engines would be shipping essentially
unspecced behavior, but that's where we're at). That said, I'm happy to
devote my few IC hours to pushing these along as a personal project over
the coming months.
Rick Byers
Yoav Weiss
Mike Taylor
Thanks Rick and Yoav.
We learned from two partners (one internal, one external) late last week that a 3P deprecation trial would be needed for them to preserve widely-used functionality while they work on a migration strategy.
We're tracking the work in crbug.com/1441411 and hope to have
that ready by M115. Once we land the fix, I'll circle back and
look for a 3rd LGTM and have an updated rollout schedule. :)
Mike Taylor
OK - let's consider this I2S officially revived. Looking for a
3rd LGTM to begin shipping in M115.
We have implemented 3rd party deprecation trial support for M115+
(see
https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials),
and extended the deprecation trial's expiration date accordingly
to account for the delay. And we have the Enterprise policy ready
to go.
The rollout schedule will look something like the following, pending metrics and compatibility stability:
July 25th: 1% of Stable population (approximately 1 week after
M115 is released)
Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%
As always, if we discover significant user-facing breakage we'll explore pausing or rolling back to address.
thanks,
Mike
Mike West
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org.
Jagadeesha B Y
I see that Chrome 115 release notes - https://chromestatus.com/feature/5723617717387264 mentioning about storage partition being enabled by default. Could someone confirm how gradual this rollout is? do we know if storage partition is rolled out fully?
Kyra Seevers
Hi there,
Thank you for your email - as of today (Monday 7/24/23), the feature is not rolled-out to stable.
However, I can confirm that the rollout schedule for this feature begins in M115 at Stable 1% (once M115 is served to 100% of users). M115 is currently served to 12.5% of users - you can track the status at https://chromiumdash.appspot.com/releases?platform=Windows. Two weeks after that, we'll go to 10%, assuming no large stability or compatibility regressions. Then 50 and 100% at additional 2 week increments.
In the meantime, we have a deprecation trial (https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials) running in M115+ that allows sites who opt-in to maintain unpartitioned storage for a few milestones while they develop a storage-partitioning-compatible solution.
Thanks,
Kyra
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org.