Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

4.495 görüntüleme
İlk okunmamış mesaja atla

Mike Taylor

okunmadı,
4 Nis 2023 18:44:524.04.2023
alıcı blink-dev, m...@chromium.org, wande...@chromium.org

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

okunmadı,
4 Nis 2023 23:52:054.04.2023
alıcı Mike Taylor, blink-dev, m...@chromium.org, wande...@chromium.org
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

okunmadı,
5 Nis 2023 14:28:065.04.2023
alıcı blink-dev, mike...@chromium.org, Marijn Kruisselbrink, wande...@chromium.org
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

okunmadı,
5 Nis 2023 20:01:045.04.2023
alıcı Yoav Weiss, blink-dev, m...@chromium.org, wande...@chromium.org

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

okunmadı,
5 Nis 2023 20:17:405.04.2023
alıcı Eli Grey, blink-dev, Marijn Kruisselbrink, wande...@chromium.org

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

okunmadı,
5 Nis 2023 22:31:015.04.2023
alıcı blink-dev, mike...@chromium.org, Marijn Kruisselbrink, wande...@chromium.org, 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

okunmadı,
10 Nis 2023 13:45:0910.04.2023
alıcı blink-dev, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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

okunmadı,
10 Nis 2023 18:07:3710.04.2023
alıcı blink-dev, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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

okunmadı,
13 Nis 2023 18:06:3613.04.2023
alıcı blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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

okunmadı,
13 Nis 2023 19:30:5313.04.2023
alıcı Eric Lawrence, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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.

Alex Russell

okunmadı,
13 Nis 2023 20:10:1113.04.2023
alıcı Domenic Denicola, Eric Lawrence, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
It's going to be surprising to developers that BroadcastChannel is "storage"

Eric Lawrence

okunmadı,
13 Nis 2023 20:13:3213.04.2023
alıcı Domenic Denicola, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, 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.

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

okunmadı,
13 Nis 2023 20:44:2013.04.2023
alıcı Alex Russell, Domenic Denicola, Eric Lawrence, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Marijn Kruisselbrink, Ben Kelly

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

okunmadı,
13 Nis 2023 20:51:1113.04.2023
alıcı Eric Lawrence, Domenic Denicola, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Marijn Kruisselbrink, Ben Kelly

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

okunmadı,
14 Nis 2023 10:37:0514.04.2023
alıcı Eric Lawrence, Domenic Denicola, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink
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

okunmadı,
14 Nis 2023 13:10:1814.04.2023
alıcı Eric Lawrence, Domenic Denicola, blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink
Folks on this thread may be interested in this issue that discusses having requestStorageAccess() expose unpartitioned storage via a storage bucket:


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

Chris Fredrickson

okunmadı,
24 Nis 2023 12:12:3624.04.2023
alıcı blink-dev, Elijah Grey, Chris Fredrickson, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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

okunmadı,
24 Nis 2023 12:35:4424.04.2023
alıcı blink-dev, Chris Fredrickson, Elijah Grey, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly
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

okunmadı,
24 Nis 2023 14:12:2324.04.2023
alıcı Mike Taylor, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org
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

okunmadı,
24 Nis 2023 15:48:5124.04.2023
alıcı Elijah Grey, Eli Grey, Mike Taylor, Marijn Kruisselbrink, Ben Kelly, Chrome First-Party Sets team
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

okunmadı,
25 Nis 2023 10:52:0825.04.2023
alıcı Yoav Weiss, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org

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

okunmadı,
25 Nis 2023 12:00:2825.04.2023
alıcı Mike Taylor, Yoav Weiss, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org
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


Mike Taylor

okunmadı,
26 Nis 2023 09:36:1926.04.2023
alıcı Rick Byers, Yoav Weiss, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org

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

okunmadı,
26 Nis 2023 14:02:1626.04.2023
alıcı Rick Byers, Yoav Weiss, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org
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

okunmadı,
27 Nis 2023 10:23:5427.04.2023
alıcı Mike Taylor, Yoav Weiss, Panos Astithas, blink-dev, m...@chromium.org, wande...@chromium.org
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

okunmadı,
1 May 2023 00:21:511.05.2023
alıcı Rick Byers, Mike Taylor, Panos Astithas, blink-dev, Marijn Kruisselbrink, Ben Kelly
LGTM2

Mike Taylor

okunmadı,
1 May 2023 10:43:511.05.2023
alıcı Yoav Weiss, Rick Byers, Panos Astithas, blink-dev, Marijn Kruisselbrink, Ben Kelly

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

okunmadı,
30 May 2023 11:39:4630.05.2023
alıcı Yoav Weiss, Rick Byers, Panos Astithas, blink-dev, Marijn Kruisselbrink, Ben Kelly

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

okunmadı,
31 May 2023 11:42:1531.05.2023
alıcı Mike Taylor, Yoav Weiss, Rick Byers, Panos Astithas, blink-dev, Marijn Kruisselbrink, Ben Kelly
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.

Jagadeesha B Y

okunmadı,
23 Tem 2023 19:05:2723.07.2023
alıcı blink-dev, mk...@chromium.org, yoav...@chromium.org, rby...@chromium.org, past...@google.com, blink-dev, Marijn Kruisselbrink, wande...@chromium.org, mike...@chromium.org

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

okunmadı,
24 Tem 2023 10:18:2624.07.2023
alıcı Jagadeesha B Y, blink-dev, mk...@chromium.org, yoav...@chromium.org, rby...@chromium.org, past...@google.com, Marijn Kruisselbrink, wande...@chromium.org, mike...@chromium.org

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 a