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]

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?

--
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]

I'm not sure if I'm reading this right. Is partitioned storage being shipped without deprecating legacy third-party cookies at the same time? If this change doesn't also deprecate third party cookies, it effectively pushes some websites to use third-party cookies instead of safer APIs scoped by FPS (which aren't ready yet). I maintain a consent manager that uses localStorage and postMessage/MessageChannel to locally synchronize cross domain consent and quarantine data. It is not a best practice to use third party cookies for this as I would rather not leak data over the network unnecessarily. I am now forced to leak consent data over the network unnecessarily because the actual effective privacy boundaries have not changed due to the lack of third-party cookie deprecation.

As far as I can tell, this will only result in a degradation of privacy for my users if I need to switch to third party cookies. Currently quarantine data never touches the network but with this change we can no longer privately and securely synchronize quarantined events, so we will have to reduce our functionality in Chrome.

[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.

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.

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. :)

[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]

Hi Mike,

By not coordinating Privacy Sandbox timeline with the unpartitioned storage deprecation timeline, Chrome is pushing us to use cookies due having to balance user privacy with customer demands to use all available browser capabilities. We currently support cross-site sync in Chrome/Edge only using unpartitioned storage, and by killing this feature without aligning deprecation timelines, Chrome is going to make us leak user consent data over the network with cookies. This results in an effective net privacy decrease for the users of Transcend Consent.

I vote that either unpartitioned storage timeline is pushed back or the 3P cookie deprecation timeline is moved up (the latter seems more difficult given the existing public commitments I've seen from Google). Anything less than the full deprecation of all unpartitioned storage (including cookies) is harmful to users' interests, as a partial deprecation just pushes sites to use other still-unpartitioned storage mechanisms with potentially worse privacy characteristics.

> which safer APIs you're referring to - some more info would be useful

APIs like requestStorageAccessFor (FPS-scoped) or something else extending the storage API could serve this purpose.

> Can I ask how you handle users on Firefox and Safari? This change moves us to align with their storage model.

We don't attempt to do cross-site sync in Firefox and Safari. For browsers with partitioned storage our sync endpoints are only used to propagate consent & quarantine data cross-(sub)domain on one site (eTLD+1) as we don't currently rely on cookies.

As an aside: Google is has been severely dropping the ball lately when it comes to coordination of Privacy Sandbox initiatives with other browser privacy features. For example, Chrome ignores its own Do Not Track feature when auto-enabling Privacy Sandbox trials. Please work on improving cross-team coordination to prevent these sort of issues from happening.

Regards,

Eli

[Chris Fredrickson]

Hi Eli,

If I can chime in on a few points from the First-Party Sets perspective:

1. 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.
   
2. 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.
3. 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.

Thanks,

Chris

[Elijah Grey]

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).

2. Thanks, I'll make sure to leave a comment about our use case.

3. Same as above. I'll expound on my use case in that issue too.

Again, I posit that the non-ideal alignment of these unpartitioned storage deprecation timelines will push site owners to use cookies to share state where they previously did not have to use cookies. A non-cookie solution should be available prior to the deprecation point to prevent adverse incentives from affecting the web as a whole.

I understand that the actual harms are likely minor, but they are measurable. We attempt to limit total entropy of consent data propagated by our sync system, but even with our best efforts it is not unreasonable to assume that bad actors would use the uniqueness of consent cookies (e.g. by looking at timestamps etc.) to uniquely track users. Our current system does not attempt to uniquely track users and serves as an enforcement point to prevent other tools from uniquely tracking users for certain purposes without consent (depending on user-applicable legal regimes).

Regards,

Eli

This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

[Eric Lawrence]

My read of this: https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#communication-apis is that BroadcastChannel will not allow a IdP loaded in a top-level frame to communicate authentication tokens to IdP subframes within RP websites (Approach #4 in https://textslashplain.com/2023/04/12/auth-flows-in-a-partitioned-world/#:~:text=authToken%27%3A%20sToken%7D%2C%20sRPOrigin)%3B%0A%7D-,Approach%204)

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]

I don't think there's much that's hard to reason about here. Storage is being partitioned, uniformly. It's the same for BroadcastChannel as it is for localStorage or IndexedDB. IdP-subframe-in-RP will uniformly be treated as different from IdP-as-top-level, with regard to storage access.

I sympathize with the situation being tricky for the short time between storage partitioning rollout and third-party cookie deprecation rollout, since then "uniformly" actually means "uniformly (except cookies for the next N months)". But that's a temporary state of affairs.

--

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]

It's going to be surprising to developers that BroadcastChannel is "storage"

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]

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. 

[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.

That's only partially true - so long as the StorageKey is the same, it will work as it did before. Otherwise these APIs will just be the new cookies in the future (see https://github.com/whatwg/html/issues/5803).

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.

You could also define unpredictability/instability by having 1 engine disagree with the 2 other major engines who have already shipped this behavior.

[Ben Kelly]

On Thu, Apr 13, 2023 at 8:13 PM Eric Lawrence <bay...@gmail.com> 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.

By this argument they were never properly named because you could not broadcast or share across origins.  There have always been constraints on which frames could participate in these APIs.  Adjusting this boundary for only some APIs and not others would be weird.  Adjusting all these APIs to use the same underlying concept, StorageKey, seems like the most principled approach here.

[Ben Kelly]

Folks on this thread may be interested in this issue that discusses having requestStorageAccess() expose unpartitioned storage via a storage bucket:

https://github.com/privacycg/storage-access/issues/102

If this would be useful for your use cases, please comment there.

[Chris Fredrickson]

Hi Elijah,

Sorry for the late response here, just wanted to make sure you were aware of one more thing related to First-Party Sets (inline):

On Monday, April 10, 2023 at 6:07:37 PM UTC-4 Elijah Grey wrote:

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).

The entities in First-Party Sets are registrable domains, not origins, and all sets must be mutually disjoint. So the plan to use different <customer-id>.sync.transcend.io subdomains in different sets would not work, as you'd really be trying to put the same registrable domain (transcend.io) in multiple different sets.

[Elijah Grey]

Our plan is to also register something similar to sync.transcend.io on the public suffix list and publish an acceptable use policy. If we don't get accepted then we will of course need to require customers to configure their own sync coordination domains (manually hosted or CNAME-backed).

Does that plan mesh well with the FPS registry or are there any other gotchas that we might be forgetting? 

[Yoav Weiss]

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:

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 may know.

[Chris Fredrickson]

blink-dev to bcc, +Chrome First-Party Sets team for FPS discussion

I don't think anything related to FPS would prevent that from working. Note that since FPS's assumption is that users do not directly interact with service domains, but the Storage Access API requires user interaction in order to grant cookie access, you will need to coordinate with your customers so that their top-level domains get user activation and request cookie access on behalf of your embedded sites (via requestStorageAccessFor).

However, as the PSL maintainers will no doubt remind you, remember that different user agents (e.g. browsers) make no guarantees about when updates to the PSL will be incorporated. (IIRC, Chrome, Safari, and Firefox vary between updating their snapshots every few months, and updating once a year or so. But there's no SLA/SLO.) So if your sites rely on a PSL update in order to work -- or inversely, if an update breaks your sites and needs to be rolled back -- there's no easy way to predict when your site will work properly in a given user agent. It may take months, or a year, or more.

[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:

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 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]

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

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.

Yep, that's correct - we'll need to support both paths for quite some time, certainly at least for the enterprise policies, or perhaps other use cases or modes we discover warrant unpartitioned storage.

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/26/23 9:36 AM, Mike Taylor wrote:

> 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?

I was gently reminded offline that I didn't answer this part of your
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]

Thanks Mike. I trust your and wanderview@'s judgement here - I know how hard y'all have been willing to work in the past to get the right thing done in specs. Thanks for being willing to keep pushing in parallel. But given two other implementations have already shipped this, it was clearly already a spec bug that the spec didn't reflect reality. I agree that we shouldn't block shipping a 3rd implementation on spec refactoring work.

LGTM1 to ship from my perspective. Obviously this will need a very thoughtful and careful roll-out. But I trust Mike and his team to engage with impacted folks to make sure it goes smoothly, as they did with UA reduction.

[Yoav Weiss]

LGTM2

[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]

LGTM3 with all the caveats about careful rollout discussed above.

-mike

--

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? 

Our SASS product has a heavy reliance on Shared worker and this would break our customer use cases.  We use shared worker to co-ordinate Web RTC signalling and websocket management which is critical for the app. 

[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.

--

Kyra Seevers (she/her) |

Software Engineer |

kyras...@google.com |

859-537-9917

[Jagadeesha B Y]

Apologies if this is being addressed already. I see that chrome has enterprise policies for the same. https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting

Would this be the alternatives for the deprecation trial?  does the same expiry (Chrome 127 on September 3, 2024) is applicable for these policies as well? 

Context: I'm about to publish a recommendation for our customers on how to continue using our SAAS APP which relies on Shared worker and it would otherwise impact the critical call handling features.  Unfortunately our customers doesn't have any choice except disabling it for now.  so trying to evaluate the quickest options. 

[Kyra Seevers]

> Would this be the alternatives for the deprecation trial?  

Yes, the enterprise policy `DefaultThirdPartyStoragePartitioningSetting` is another method of achieving unpartitioned storage. It would require the standard enterprise management setup: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/policies.md. 

> does the same expiry (Chrome 127 on September 3, 2024) is applicable for these policies as well?

Yes, the deprecation trial and the enterprise policy have the same expiry date (Chrome 127 on September 3, 2024).

Thanks,

Kyra

[Ben Kelly]

Jagadeesha, can you also take a look at the proposal in:

https://github.com/privacycg/storage-access/issues/102

And comment there if you think that would help with your use case?

[Jagadeesha B Y]

Yup i have been following - https://github.com/privacycg/storage-access/issues/102 closely and it does make my use cases to work seamlessly. Hopefully we get more traction on this topic and the same solution (RSA) works for shared worker and other type of storages too. 

there are the related issues i have cut to follow up on this topic  -  https://github.com/privacycg/storage-access/issues/175, https://github.com/cfredric/chrome-storage-access-api/issues/3, and https://github.com/WICG/first-party-sets/issues/161 and https://issuetracker.google.com/issues/288303220?pli=1

[Vi S]

Hi Kyra,

Per your message here (https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ) it sounds like as of 7/26/2023, the Storage Partitioning change has not been released yet since M115 is not served to 100% of users. Is that correct? My understanding of this message is that M115 is currently served to 12.5% of users and that once M115 is served to 100% of users (which will happen in the next ~4 weeks), only then will the storage partition change be rolled out in a gradual manner. Is this understanding accurate?

Additionally, would you be able to provide an updated schedule for the rollout of the storage partitioning change (similar to the one linked here: https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ) ?

Thank you

[Mike Taylor]

On 7/26/23 4:01 PM, Vi S wrote:

Hi Kyra,

Per your message here (https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ) it sounds like as of 7/26/2023, the Storage Partitioning change has not been released yet since M115 is not served to 100% of users. Is that correct? My understanding of this message is that M115 is currently served to 12.5% of users and that once M115 is served to 100% of users (which will happen in the next ~4 weeks), only then will the storage partition change be rolled out in a gradual manner. Is this understanding accurate?

That's correct.

Additionally, would you be able to provide an updated schedule for the rollout of the storage partitioning change (similar to the one linked here: https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ) ?

Once we begin the gradual roll-out, we'll provide a estimated rollout schedule on this thread (I hesitate to do so now - it's hard to know when we will begin exactly).

thanks,
Mike

[Jagadeesha B Y]

Do we know when does M115 will hit 100%?  Exact date would help us to communicate on the storage partition impact to our customers. 

[Mike Taylor]

No, we don't know with certainty. 

You can watch https://chromiumdash.appspot.com/releases?platform=Windows to see when 115 is being served to 100% for all platforms. Today it's at 50% for Windows, for example.

[Kyra Seevers]

Hi all,

M115 is now being served at 100% on Desktop and Android. We will begin the rollout to Stable 1% shortly - the approximate rollout schedule is now as follows:

Stable 1%: July 28th

Stable 10%: Aug 11th

Stable 50%: Aug 25th

Stable 100%: Sept 8th

[Vi S]

Thanks for the update, Kyra.

Would like to ask a follow-up question here. I noticed that in chrome://flags/ there's the flag Experimental third-party storage partitioning. For how long will users have access to this flag? And for how long will they be able to disable this?

Additionally, for further clarification, if a customer disables this flag in Chrome, would the user have the storage partition change that is scheduled to roll out on 7/28 at 1%?

[Tim Williams]

Hey There,

I am truly struggling to understand the timing here.

Currently, the partitioning is under a flag.

Are you saying that the flag would be turned on to 100% of Desktop and Android users on Sept 8th THIS YEAR??

That's a huge and extremely fast change, wow.

[Tim Williams]

I've submitted the following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1468811 since the trial isn't working while I did everything right.

[Mike Taylor]

Thanks for the bug report! We'll triage it in our regular meeting tomorrow.

And yes, your understanding of the timing is correct (we've been working on this project for 2+ years, and in dev-trial since September of last year). Note that advancing to a higher percentage will depend on the stability and web-compatibility of partitioned 3P storage.

thanks,
Mike

[Tim Williams]

Hey Mike,

Thanks for the update!
I totally understand your timing, and it's on us to blame for missing this out (or at least we thought that it would be together with the cookie update which was postponed several times).

Anyway, I encourage you to postpone the timing until the trial bug will be fixed to enable us, and other developers who would like to use the trial meta tag to be able to do so.

Thanks!

[Kyra Seevers]

Hi all,

Quick update: we began the rollout to 10% stable today. 

The new rollout schedule is approximately:

Stable 50%: Aug 28th
Stable 100%: Sept 11th

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4cf940ed-3dd6-4c49-91af-e6b7c7d42ac4n%40chromium.org.

[Junji Genesys]

Hello Kyra,

Thank you for communicating about the rollout plan for the storage partitioning.

We've found that the new storage partitioning behavior has impacted our product, which is a web client application embedded in an iframe inside Salesforce and provides call center agents functionality such as handling phone calls. We use browser-based phone (WebRTC phone) that can pop out as a separate window, which communicates with the embedded client frame via localStorage and BroadcastChannel. The new storage partitioning restriction blocks this communication as our application is running as an embedded iframe with a top-level domain that differs from our browser phone running in a popped out window. Our browser phone does not work properly in that scenario, and as a result, users are not able to answer their calls. Many of our customers have started reporting this issue, and it is currently our top priority to address this issue given its time-sensitive nature.

We've also learned about an existence of the experimental flag, two relevant enterprise policies and the deprecation trial for disabling this new change as a temporary measure. We're especially interested in the deprecation trial, but that can be activated only by the top-level domain site and there is no way for the embedded content in an iframe to activate the deprecation trial.

I've contacted Salesforce support to see if they can sign-up and activate the deprecation trial, but they asked me to reach out to Chrome team to see if Chrome team can create a ticket with Salesforce and help them with the deprecation trial for unpartitioned third-party storage.

Would you be able to work with Salesforce for the deprecation trial in their environment?
Also, since you might have dealt with other third-party vendors before, what suggestions do you have on how to approach a situation like this?
I greatly appreciate your prompt response and help on this matter.

Thank you,

Junji

[Yoav Weiss]

Is your application running script in the top level context? Since the deprecation trial is implemented as a third-party origin trial, you may be able to sign up as a third party.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15914fe7-8e14-4580-b1f2-d038ddfba9d6n%40chromium.org.

[Mike Taylor]

Yes, if you sign up for a 3rd party token and inject that into the site embedding your iframe before your iframe is created, that will give you access to unpartitioned storage (until the Deprecation Trial expires).

Here's a demo that injects an 3P origin trial token then creates an iframe:

https://rogue-lace-join.glitch.me/

And the relevant source files:

https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8
https://miketaylr.com/misc/3pspdt.js

Feel free to reach out to me off-list to discuss more or if you have any further questions.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV9jqK7%2BA-W7A8tWK03vcaqS2onRymPzFxiVOPG1bGcSQ%40mail.gmail.com.

[Junji Genesys]

Our application has no access to the top-level context, so there is no way for us to include our third-party trial script in the top-level context.
We basically provide Salesforce with our embedded client URL, and they use it to load and embed our client in their iframe.

[Tim Williams]

We have the same situation as Junji here.

For us, it means that our solution would be broken across all websites since the platforms are using our iframe URL and we have 0 ability to inject code at their top Domain (nor do we want to).

[Mike Taylor]

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 - it would be great if you both could give more context about your embedded application, and how you deal with Safari and Firefox as comments in the bug (same goes for anyone else facing this issue).

thanks,
Mike

[Kyra Seevers]

Hi all,

Another quick update: we began the rollout to 50% stable today. 

We will roll-out to 100% of Stable users on approximately Sept. 20th, 2023.

Thanks,

Kyra

[Muhammad Ahmed Mallick]

Hi All,
I'm also facing challenges with the current situation. We're loading my own website within the Chrome extension, and we manage the user's login state (tokens) on my website. The extension's iframe is supposed to retrieve the token from local storage, but it's currently broken. It's not feasible to ask the user to log in twice just to access the extension's content.

Please let me know if there is any solution to get it fixed asap.

Thanks 
Ahmed

[Kyra Seevers]

Hi Muhammad,

I have filed this bug for the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We would appreciate it if you could describe your set-up with more detail in this bug. Have you registered for the deprecation trial described here?: https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/

Thanks,

Kyra

kyras...@chromium.org

[Chinmay Manchanda]

Hi Kyra,

Do we have an update on what time the feature will be rolled out today?

Cheers,
Chinmay

[Kyra Seevers]

Hi Chinmay,

Thanks for reaching out! Due to internal delays, we won't be rolling out to Stable 100% likely until the end of the week or the beginning of next week. I'll keep the thread updated with any further delays.

Thanks,

Kyra

[Chinmay Manchanda]

Thanks for the update,

Would you please clarify these for me?

• The disclosure in the deprecation trial mentions a 0.5% limit on using the feature tracked on the chrome page loads. Is that limit per origin or on all chrome page loads globally? 
• The thirdPartyStoragePartitioning will only be rolled out to Chrome 115 and above, is that correct? 
• We noticed a couple of cases where it seems to be disabled on windows 10 setups, is that in the rollout by design or is it a happy coincidence that these setups were not in the 50% rollout?

Cheers,
Chinmay

Get Outlook for iOS

---

From: Kyra Seevers <kyras...@google.com>
Sent: Wednesday, September 20, 2023 10:53:11 PM
To: Chinmay Manchanda <cmanc...@tyro.com>
Cc: blink-dev <blin...@chromium.org>; Kyra Seevers <kyras...@chromium.org>
Subject: [EXTERNAL]_Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

 

CAUTION: This email originated from outside of Tyro. Do not click any links or open any attachments unless you can confirm the sender and know the content is safe.

Tyro Payments Limited ACN 103 575 042 AFSL 471951 (Tyro) is the issuer of its own financial products. As Tyro does not take into account your personal circumstances, please consider if these products are suitable for you. T&Cs available at tyro.com/terms-and-conditions/ . You can contact Tyro on 1300 00 TYRO (8976) or at tyro.com/support/ and access Tyro's dispute resolution process at tyro.com/complaint-resolution-process/. The information contained in this email is confidential. If you have received this email in error, please delete it and let us know immediately. If you no longer wish to receive commercial electronic messages from us, please e-mail unsub...@tyro.com using UNSUBSCRIBE in the subject line.

Security Warning: Tyro will not contact you asking to disclose your password or PIN. Tyro will not request you to login with a username or password, unless login is a requirement as a result of an activity that you yourself have initiated or are aware of. If you receive a suspicious email or phone call purporting to be from Tyro, please call us on 1300 00 TYRO (8976) or email c...@tyro.com . We review our security regularly, however, no warranty is provided that any email and/or attachments are free from viruses or other defects and no liability will be accepted for any loss, damage or other consequences that may arise from opening or using any such email and/or attachments.

[Mike Taylor]

On 9/20/23 9:12 AM, Chinmay Manchanda wrote:

Thanks for the update,

Would you please clarify these for me?

• The disclosure in the deprecation trial mentions a 0.5% limit on using the feature tracked on the chrome page loads. Is that limit per origin or on all chrome page loads globally?
  

This notice is a bit misleading - it only applies to an Origin Trial (which is typically used for new features). For a Deprecation Trial, there is no traffic limit.

• The thirdPartyStoragePartitioning will only be rolled out to Chrome 115 and above, is that correct?
  

Yes, correct.

• We noticed a couple of cases where it seems to be disabled on windows 10 setups, is that in the rollout by design or is it a happy coincidence that these setups were not in the 50% rollout?

Seems like a coincidence. :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SYCPR01MB463984555D524EA20C708DEFA5F9A%40SYCPR01MB4639.ausprd01.prod.outlook.com.

[Kyra Seevers]

Hi all,

Wanted to keep the thread updated and confirm that we have not shipped to Stable 100% yet. We will be delaying another day or two due to internal delays.

Thanks,

Kyra

[Manish Bisht]

Hi,

Is this enabled by default to chrome dev without the use or feature flag ?

Also is there any example of host_permissions that is mentioned here because I don't think this is working with the chrome flag enabled.

Thanks,

[Kyra Seevers]

Hi all,

Quick update: the ThirdPartyStoragePartitioning feature flag is now enabled by default in Canary. We will be rolling out to 100% Stable shortly.

Manish - could you please file a bug describing your set-up here: https://bugs.chromium.org/p/chromium/issues/entry, and add the label "Proj-StoragePartitioningTrial". Also, have you looked into our deprecation trial in the meantime?: https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/.

Thanks all,

Kyra

[Illia Kyselov]

Hi all,

I hope this message finds you in good health. I am reaching out to seek your expertise in helping me solve a problem.

Our app incorporates an extension that aids users in accruing information from diverse sites, a feature that is instrumental in social network and business development, among other applications. A crucial aspect of this function is the user's ability to open the extension and add contacts without the need to log in in our app in extension at each individual website (as login information is stored in Local Storage).

From my understanding, we cannot use the option DisableThirdPartyStoragePartitioning because our extension has to work across all websites.

This leads me to question if there is no immediate solution to this problem. Does this imply we need to contemplate workarounds, potentially affecting the user experience of our app?

I eagerly await your advice on this matter. Your assistance and contribution are greatly appreciated. Thank you for your continued support.

Best regards.

[Kyra Seevers]

Hi Illia,

Thanks for reaching out - does this bug answer any of your questions?: https://bugs.chromium.org/p/chromium/issues/detail?id=1481485&q=reporter%3Ame&can=1

If not, could you please file a bug describing your set-up here: https://bugs.chromium.org/p/chromium/issues/entry, and add the label "Proj-StoragePartitioningTrial" and cc kyras...@chromium.org?

In the bug, please include information about your extension set-up - does the extension have host permissions for each of the websites? Is it Manifest v2 or v3?

Thanks,

Kyra

[Jayakrishnan Gounder]

Hi All,

We are facing the same problem as others. We have chrome extension page in a Iframe on top of another web apps. When the "Block third-party cookies" is turned on, we are getting the following error:

"DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document."

As per this link Storage Partitioning - Chrome for Developers, we've already set the host permissions for all the web apps, and Extension uses Manifest v3.

Only way to make it work is turn "Block third party cookies" off. It used to work before regardless of the state of "Block third-party cookies".

I am looking forward to your response, thanks for your cooperation.

Regards.

[Mike Taylor]

As before, please file a bug at crbug.com/new. Feel free to cc mike...@chromium.org and add the "Proj-StoragePartitioningTrial" label, thanks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46bacb9b-db4b-49f1-b0f2-943a87659bc9n%40chromium.org.

[Mike Taylor]

Oh, I just realized this should be expected behavior, until M119.

Prior to M119, when a user toggled "Block third-party cookies", all 3rd party storage was disabled. Starting in M119, when a user toggles "Block third-party cookies" partitioned 3rd party storage will be enabled instead.

Please test in Canary, and file a bug if it's still not working as you would expect.

See https://groups.google.com/a/chromium.org/g/blink-dev/c/uppiYp7lIpY/m/5OFnTw3pAAAJ

thanks,
Mike

[Kyra Seevers]

Hi James,

This feature is now shipped to 100% of Stable users in M115+.

Thanks,

Kyra

On Sun, Oct 8, 2023 at 4:40 PM James Leskovar <jles...@gmail.com> wrote:

Hi Kyra,

Could we get an update on the status of the rollout to Stable users?

Regards
James Leskovar

[James Leskovar]

Hi Kyra,

Could we get an update on the status of the rollout to Stable users?

Regards
James Leskovar

On Saturday, October 7, 2023 at 2:51:13 AM UTC+11 Mike Taylor wrote:

[Russel Simmons]

I ran into what I believe is a closely related issue, and filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1497198

But I didn't see a way to CC you or add that label, so letting you know here.

The gist is that adding host permissions for an extension does not seem to enable access to the top-level partition, as mentioned in docs:

"If a page with the chrome-extension:// scheme includes an iframe, and the extension has host permissions for the site it is embedding, that site will also have access to its top-level partition."

"Extension pages (pages with a chrome-extension:// scheme) can be embedded on sites across the web, and in these cases, they will continue to have access to their top-level partition. These pages can also embed other sites, in which case those sites will have access to their top-level partition as long as the extension has host permissions for that site."

thanks

Russ

[Mike Taylor]

Thank you very much for the bug report!

[Mike Taylor]

Hi Brett,

On 11/3/23 6:40 PM, Brett McStotts wrote:

Happy Friday All!

I noticed that setting the #third-party-storage-partitioning flag to disabled in Chrome disables storage partitioning. However, disabling the #third-party-storage-partitioning flag in Chrome Beta disables all embedded storage. For example, I'm not able to start a Shared Worker or access Local Storage in a cross-domain iframe. Will this behavior in Chrome Beta make its way to regular Chrome? If so, do you happen to have a timeline of when?

Can you verify if 3P cookies are blocked, where you are seeing 3P storage also disabled? If so, that is expected behavior, and has been true for a very long time (you can verify on this simple demo: https://rogue-lace-join.glitch.me/). If you're seeing this with 3P cookies enabled, please file a bug at crbug.com/new and cc me (or just send back a pointer to the bug). The new default behavior is partitioned storage in all 3P contexts, with or without 3P cookies enabled.

For background, we just discovered a customer use-case on our site that is affected by storage partitioning. We are in the process of setting up the Deprecation Trial while we resolve this. In the meantime, we're considering telling the affected customer to set #third-party-storage-partitioning flag to disabled as a temporary workaround. However, we don't want to tell them to do this, then the Beta behavior makes its way to production and causes a cascade of other issues for the customer :) .

Yes, understood! The Deprecation Trial would be the recommended course of action, as it will be the most predictable for your users until you can implement a workaround to the affected use case.

thanks,
Mike

Thank you,

Brett

[Brett McStotts]

Happy Friday All!

I noticed that setting the #third-party-storage-partitioning flag to disabled in Chrome disables storage partitioning. However, disabling the #third-party-storage-partitioning flag in Chrome Beta disables all embedded storage. For example, I'm not able to start a Shared Worker or access Local Storage in a cross-domain iframe. Will this behavior in Chrome Beta make its way to regular Chrome? If so, do you happen to have a timeline of when?

For background, we just discovered a customer use-case on our site that is affected by storage partitioning. We are in the process of setting up the Deprecation Trial while we resolve this. In the meantime, we're considering telling the affected customer to set #third-party-storage-partitioning flag to disabled as a temporary workaround. However, we don't want to tell them to do this, then the Beta behavior makes its way to production and causes a cascade of other issues for the customer :) . 

Thank you,

Brett

On Monday, October 30, 2023 at 9:46:14 AM UTC-4 mike...@chromium.org wrote:

[Brett McStotts]

Ok. It turns out I did have 3P Cookies blocked from prior testing. It's interesting that I was able to write to LocalStorage with Block 3P Cookies and Storage Partitioning set to Enabled. However, having Block Cookies set to only Incognito with Storage Partitioning Disabled works fine. 

[Arthur Furman]

Hi team,

As a 3rd party service, I currently use the Deprecation Trial to postpone the storage partitioning.

Once I am ready to move to partitioned storage, I need to:
a. Migrate the data to partitioned storage to avoid data loss.
b. Selectively choose the keys I want to migrate under a certain domain (once it is loaded).

by removing the Depracation Trial, the access to the data saved in the unpartitioned storage is be lost,
so the current plan is to copy the data to unpartitioned 3rd party Cookies, which will be phased out on 24Q1, and migrate the data back to partitioned storage once the relevant domain is loaded.

as this feels a bit hacky, is there a more recommended way to 'migrate' my keys and values from unpartitioned storage to partitioned storage, and accompish goals a & b mentioned above?

Thank you!

[Arthur Furman]

Further to my message above, openned a bug with a demo and a few suggestions: https://bugs.chromium.org/p/chromium/issues/detail?id=1501639

[Ari Chivukula]

Heads up that there's an Origin Trial which allows unpartitioned access to some storage and communication mechanisms via SAA (the same mechanism that grants unpartitioned cookie access): https://developer.chrome.com/blog/saa-non-cookie-storage/

~ Ari Chivukula (Their/There/They're)

On Mon, Apr 10, 2023 at 6:07 PM 'Elijah Grey' via blink-dev <blin...@chromium.org> wrote:

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).

2. Thanks, I'll make sure to leave a comment about our use case.

3. Same as above. I'll expound on my use case in that issue too.

Again, I posit that the non-ideal alignment of these unpartitioned storage deprecation timelines will push site owners to use cookies to share state where they previously did not have to use cookies. A non-cookie solution should be available prior to the deprecation point to prevent adverse incentives from affecting the web as a whole.

I understand that the actual harms are likely minor, but they are measurable. We attempt to limit total entropy of consent data propagated by our sync system, but even with our best efforts it is not unreasonable to assume that bad actors would use the uniqueness of consent cookies (e.g. by looking at timestamps etc.) to uniquely track users. Our current system does not attempt to uniquely track users and serves as an enforcement point to prevent other tools from uniquely tracking users for certain purposes without consent (depending on user-applicable legal regimes).

Regards,

Eli

On Monday, April 10, 2023 at 10:45:09 AM UTC-7 Chris Fredrickson wrote:

Hi Eli,

If I can chime in on a few points from the First-Party Sets perspective:

1. 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.
   
2. 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.
3. 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.

Thanks,

Chris

On Wednesday, April 5, 2023 at 10:31:01 PM UTC-4 Eli Grey wrote:

Hi Mike,

By not coordinating Privacy Sandbox timeline with the unpartitioned storage deprecation timeline, Chrome is pushing us to use cookies due having to balance user privacy with customer demands to use all available browser capabilities. We currently support cross-site sync in Chrome/Edge only using unpartitioned storage, and by killing this feature without aligning deprecation timelines, Chrome is going to make us leak user consent data over the network with cookies. This results in an effective net privacy decrease for the users of Transcend Consent.

I vote that either unpartitioned storage timeline is pushed back or the 3P cookie deprecation timeline is moved up (the latter seems more difficult given the existing public commitments I've seen from Google). Anything less than the full deprecation of all unpartitioned storage (including cookies) is harmful to users' interests, as a partial deprecation just pushes sites to use other still-unpartitioned storage mechanisms with potentially worse privacy characteristics.

> which safer APIs you're referring to - some more info would be useful

APIs like requestStorageAccessFor (FPS-scoped) or something else extending the storage API could serve this purpose.

> Can I ask how you handle users on Firefox and Safari? This change moves us to align with their storage model.

We don't attempt to do cross-site sync in Firefox and Safari. For browsers with partitioned storage our sync endpoints are only used to propagate consent & quarantine data cross-(sub)domain on one site (eTLD+1) as we don't currently rely on cookies.

As an aside: Google is has been severely dropping the ball lately when it comes to coordination of Privacy Sandbox initiatives with other browser privacy features. For example, Chrome ignores its own Do Not Track feature when auto-enabling Privacy Sandbox trials. Please work on improving cross-team coordination to prevent these sort of issues from happening.

Regards,

Eli

On Wednesday, April 5, 2023 at 5:17:40 PM UTC-7 mike...@chromium.org wrote:

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

On 4/5/23 2:28 PM, Eli Grey wrote:

I'm not sure if I'm reading this right. Is partitioned storage being shipped without deprecating legacy third-party cookies at the same time? If this change doesn't also deprecate third party cookies, it effectively pushes some websites to use third-party cookies instead of safer APIs scoped by FPS (which aren't ready yet). I maintain a consent manager that uses localStorage and postMessage/MessageChannel to locally synchronize cross domain consent and quarantine data. It is not a best practice to use third party cookies for this as I would rather not leak data over the network unnecessarily. I am now forced to leak consent data over the network unnecessarily because the actual effective privacy boundaries have not changed due to the lack of third-party cookie deprecation.

As far as I can tell, this will only result in a degradation of privacy for my users if I need to switch to third party cookies. Currently quarantine data never touches the network but with this change we can no longer privately and securely synchronize quarantined events, so we will have to reduce our functionality in Chrome.

On Tuesday, April 4, 2023 at 3:44:52 PM UTC-7 mike...@chromium.org wrote:

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 

This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

--
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/494b3f4b-b9de-4fac-8e83-2555d2d3a9a3n%40chromium.org.

[Brett McStotts]

Can we confirm the above is true that the DisableStoragePartitioning Enterprise Policy will also expire on September 3rd, 2024?

We've uncovered an upcoming issue for us with Storage Partitioning and Partitioned cookies. We have Site A that embeds Site B in an iframe. Site B uses a Shared Worker that refreshes an access cookie. Disabling Storage Partitioning makes the Shared Worker a top-level context. So if the SharedWorker for the iframed sets a Partitioned cookie, the cookie will have a partition key of Site B. Therefore, it won't be accessible in the iframe embedded under Site A. 

We're setting both a partitioned and unpartitioned cookie right now so it's fine. But after 3PCD the unpartitioned cookie won't be available. We'll have to tell customers embedding our site who are using the DisableStoragePartitioning Enterprise Policy to also use the CookiesAllowedForUrls Enterprise policy. Or make architecture changes.

However, if the Enterprise Policy is expiring then this is a non-issue.

[Mike Taylor]

Hi Brett,

We don't yet have an expiration date set for https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting, or any concrete plans to add one. If and when we do decide to deprecate it, we'll give a 6 months deprecation notice through the normal enterprise policy channels. FWIW, I would like to remove it eventually - but I don't expect it to happen this year.

thanks,
Mike

[Brett McStotts]

Ok. I'm testing now and with Storage Partitioning Disabled + 3PCD a cross-origin iframe is blocked from accessing local storage, session storage, and DOMCache. I think this will cause unexpected behavior for sites using this Enterprise Policy next year when 3PCD takes effect. It'd be great if there was a Document API of hasUnpartitionedStorageAccess() similar to hasUnpartitionedCookieAccess that would let us know if customers embedding our application are using this Enterprise Policy.

[Ari Chivukula]

That's not on our roadmap for now as hasStorageAccess/hasUnpartitionedCookieAccess are there to help understand the need to call requestStorageAccess to access cookies (they fit into a larger use case pattern cross-browser).

One way to get access to unpartitioned storage would be by using the new handle returned from a call to requestStorageAccess outlined here: https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess

The handle returned would grant unpartitioned storage access whether or not the calling context itself were partitioned.

~ Ari Chivukula (Their/There/They're)

[Brett McStotts]

hasStorageAccess/hasUnpartitionedCookieAccess doesn’t tell us if storage partitioning is disabled. It just tells you if there is unpartitioned cookie access. That will always return false post-3PCD. It will also return true pre-3PCD with storage partitioning disabled.

We also can't call requestStorageAccess because Chrome's implementation requires a top-level interaction. Customers are interacting with our site solely embedded.

So yeah it'd be great if there was an API to let us know if customers are in this storage partitioning disabled state. We could identify these customers and directly ask them to add an additional CookiesAllowedForUrls Enterprise Policy to allow our site local and session storage access.