Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs
Mike Taylor
Contact emails
wande...@chromium.org, m...@chromium.org, mike...@chromium.org
Explainer
https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
Specification
Partitioned Storage is roughly specified at https://privacycg.github.io/storage-partitioning/. As part of this work, we have started to codify the necessary concepts in HTML, DOM, and Storage in the following PRs:
https://github.com/whatwg/storage/pull/144
https://github.com/whatwg/dom/pull/1142
https://github.com/whatwg/html/pull/8447
We have also updated other APIs to use StorageKey (ServiceWorker [1], BroadcastChannel [1], SharedWorker[1]), and landed necessary additions to Storage itself ([1][2]).
What we thought to be a straightforward set of changes has evolved to be a more complex refactoring, per the request of HTML editors. We propose to ship with a WIP spec spread out across the PRs above (noting that Firefox and Safari have already shipped partitioned storage). That said, we intend to finish this work.
Summary
We intend to partition a number of APIs in third-party contexts. This effort is focused on partitioning APIs above the network stack. This includes quota-managed storage, service workers, and communication APIs (like BroadcastChannel). See the explainer for more details:
https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
Blink component
Blink>Storage
TAG review
https://github.com/w3ctag/design-reviews/issues/629
TAG review status
Resolution: Satisfied
Risks
Interoperability and Compatibility
Given that Firefox and Safari have already shipped this feature, we expect our implementation to be interoperable. We are aware of breakage for sites that use Firebase for authentication (because it relies on being able to access unpartitioned sessionStorage). Firebase has blogged on how sites can mitigate this issue. We built a deprecation trial specifically for the sessionStorage redirect use case, which should work for Firebase users. In addition, we have a general deprecation trial available and enterprise policies in place. See below for more info on the deprecation trials.
We’ve made storage partitioning available for local testing in Chrome for the past 6 months. Apart from Firebase, we’re not aware of any existing compatibility issues that can’t be solved by the deprecation trials. There may be unforeseen contexts and use cases that rely on unpartitioned storage and as such, we propose to roll this feature out carefully via Finch, according to the following proposed schedule:
May 9th: 1% of Stable population (approximately 1 week after M113 is released)
May 23rd: 10%
June 6th: 50%
June 20th: 100%
As usual, if we identify concerning metrics, regressions, or site breakage reports, we may pause or roll back to investigate or address issues.
Deprecation trial instructions: https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/
Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
Web developers: Mixed signals. Some developers have expressed compatibility concerns, others have been supportive.
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No, we don’t intend to turn this on for WebView yet.
Debuggability
DevTools has support for partitioned storage.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No (not WebView)
Is this feature fully tested by web-platform-tests?
Yes. We’ve written WPTs to verify our 3rd party storage partitioning.
Flag name
ThirdPartyStoragePartitioning
Requires code in //chrome?
Nope
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1191114
Launch bug
https://launch.corp.google.com/launch/4214498
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (in other words, links to known GitHub issues in the project, for the feature specification) whose resolution may introduce web compat/interop risk (such as changes to naming or structure of the API in a non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5723617717387264
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/FNi-nNC8fiw/m/gNftPAzUBgAJ
Yoav Weiss
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e8540107-85b2-a113-6347-1290c23f6379%40chromium.org.
Eli Grey
Mike Taylor
On 4/4/23 11:51 PM, Yoav Weiss wrote:
Thanks for working on this!!Aligning with Safari and Firefox on this means that this is important not just for user privacy, but also from an interop perspective. It also gives us some confidence that this deprecation can be successful.
This is effectively a deprecation, but one where I can't think of a reasonable way to measure usage, so it seems to me that a careful rollout + deprecation trial (as you're suggesting) is the way to go here.
Is the deprecation trial enabled as a 3P OT? That may ease the deployment for platform providers that have a hard time shipping header changes to a large set of origins.
Also, have we reached out to the usual suspects to make sure they test this change ahead of time?
Mike Taylor
Hi Eli,
Correct, we're not deprecating third-party cookies with this
change - you can learn more about the timeline
for that here. I don't understand the setup of your use
case, or which safer APIs you're referring to - some more info
would be useful (also feel free to email me and the folks in cc
directly, if you prefer).
Can I ask how you handle users on Firefox and Safari? This change moves us to align with their storage model.
thanks,
Mike
Eli Grey
Chris Fredrickson
If I can chime in on a few points from the First-Party Sets perspective:
- Do you plan to use First-Party Sets to put your consent management site in the same FPS as your customers' sites? (Note that you would have to work around the FPS disjointness requirement, e.g. using CNAMEs.) That would allow your product to continue to do limited cross-site data sharing, although it would have to use cookies to do so.
- FYI, both the Storage Access API and Chromium's proposed extension (requestStorageAccessFor) only unblock access to unpartitioned cookies; they do not unblock access to unpartitioned storage. (You may already know this, since you linked to the relevant Storage Access API issue.) Please feel free to comment on that issue if it would address a critical use case for your product.
- If you're expecting to use First-Party Sets to enable limited cross-site data sharing, you may be interested in https://github.com/WICG/first-party-sets/issues/111 and/or https://github.com/WICG/first-party-sets/issues/94 (which admittedly is related to cookies). Please feel free to comment on those issues if either of them would address your use case; we're actively looking for feedback to help us shape and motivate/prioritize those proposals.
Elijah Grey
Eric Lawrence
I understand the drive to do this (neutering 3P cookies without neutering all of their replacements is of questionable value), but it does feel like a huge loss for the power of Web Platform. BroadcastChannel will turn into BroadcastChannelExceptInSomeCasesThatAreHardToReasonAbout.
Domenic Denicola
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/42a5bada-46cb-4508-8e63-fa88ea0570a1n%40chromium.org.
Alex Russell
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9SnUy3iPaqspOQyWZ1eoE5cA88JHJ5p6GjZ_RaFv25CQ%40mail.gmail.com.
Eric Lawrence
Mike Taylor
Right, it's lumped under the Communication API section of the
explainer. We could call it StorageKey Partitioning to be more
precise, but I'm not sure that gains us much.
Mike Taylor
Hi Eric,
On 4/13/23 8:13 PM, Eric Lawrence wrote:
What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc.
When we change longstanding behaviors, we break existing code, and force web developers (or their customers) to try to figure out why their site works in one context (e.g. directly navigated), and not in another (e.g. inside the Company Portal website).
Introducing partitioning where it was not in use before is particularly challenging because in most cases there's no obvious explanation of what went wrong: Data just disappears.
This makes the web platform feel unpredictable and unstable as a platform to build atop.
Ben Kelly
What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc.
Ben Kelly
Chris Fredrickson
Hi Chris,I appreciate your response. Here are my responses to your points:1. Yes, we plan to use FPS to put our consent management tool in the same FPS (using <customer-id>.sync.transcend.io as a service domain per customer, alternatively CNAME-backed by the customer). We will still be forced to reduce customers' users' privacy by sharing user consent data through cookies (and completely lose our ability to sync quarantine data cross-site as it cannot safely be included in network requests through cookies).
Elijah Grey
Yoav Weiss
On 4/4/23 11:51 PM, Yoav Weiss wrote:
Yeah, I'm hopeful that the web has adjusted to this as the norm given Firefox and Safari's behavior, but we know that Firefox had some site breakage to deal with when they first introduced the feature, so I'd rather be cautious with the rollout to avoid any major incidents.Thanks for working on this!!Aligning with Safari and Firefox on this means that this is important not just for user privacy, but also from an interop perspective. It also gives us some confidence that this deprecation can be successful.
This is effectively a deprecation, but one where I can't think of a reasonable way to measure usage, so it seems to me that a careful rollout + deprecation trial (as you're suggesting) is the way to go here.
We made the decision to not support 3Ps for the deprecation trial. Instead, when a site enables the Deprecation trial, all of its embedded frames will have a 1st party StorageKey. Our thinking was that we wanted the embedder to be in control of its users' storage, rather than the embeddee. But if this turns out to be untenable, we're open to considering making this work as a 3P trial as well.Is the deprecation trial enabled as a 3P OT? That may ease the deployment for platform providers that have a hard time shipping header changes to a large set of origins.
Chris Fredrickson
Mike Taylor
On 4/24/23 2:11 PM, Yoav Weiss wrote:
Apologies for my slowness!
On Thu, Apr 6, 2023 at 2:01 AM Mike Taylor <mike...@chromium.org> wrote:
On 4/4/23 11:51 PM, Yoav Weiss wrote:
Yeah, I'm hopeful that the web has adjusted to this as the norm given Firefox and Safari's behavior, but we know that Firefox had some site breakage to deal with when they first introduced the feature, so I'd rather be cautious with the rollout to avoid any major incidents.Thanks for working on this!!Aligning with Safari and Firefox on this means that this is important not just for user privacy, but also from an interop perspective. It also gives us some confidence that this deprecation can be successful.
This is effectively a deprecation, but one where I can't think of a reasonable way to measure usage, so it seems to me that a careful rollout + deprecation trial (as you're suggesting) is the way to go here.
We made the decision to not support 3Ps for the deprecation trial. Instead, when a site enables the Deprecation trial, all of its embedded frames will have a 1st party StorageKey. Our thinking was that we wanted the embedder to be in control of its users' storage, rather than the embeddee. But if this turns out to be untenable, we're open to considering making this work as a 3P trial as well.Is the deprecation trial enabled as a 3P OT? That may ease the deployment for platform providers that have a hard time shipping header changes to a large set of origins.
The scenario I'm slightly concerned about is a large platform (ecommerce, CRM, etc) with a ~gazillion different customer origins, that is currently relying on any of these APIs to communicate common state (e.g. checkout flows).Such a platform would most probably be able to opt-in using a 3P OT (by delivering a common origin script that does the opt-in), but may not be able to opt-in each origin individually.It's probably fine to make sure that only the top-level frame can participate in the 3P OT, although I'm not 100% sure if that's how 3P OTs are currently wired.+Panos Astithas may know.
Yeah, that's a fair concern. To date, we're not aware of any such
use cases or site breakage - but that doesn't mean it's not out
there. :) We have engaged with one large enterprise SaaS platform
to encourage early testing last September, and thus far haven't
heard anything concerning from them.
We're hoping that turning this on at 1% might flush out some of
these possible scenarios and help us decide if we need to re-think
how the Deprecation Trial works, or even the launch plan (perhaps
launching behind the "Block 3P cookies" setting to start with).
After thinking a bit more, it probably makes sense to hold at 1%
for longer than the original 2 weeks, perhaps 4 weeks instead.
Given that Gecko and WebKit have already shipped partitioned
storage, I'm hopeful that things aren't so dire - but we may just
discover how much of the web isn't tested or supported in those
engines.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/482f0215-8ded-fe8b-9765-423567625f41%40chromium.org.
Mike Taylor
Hi Rick,
On 4/25/23 12:00 PM, Rick Byers wrote:
I share the concerns around compat risk and making the platform less predictable for businesses. But I also don't see any alternative given that at least Google Chrome is going ahead with strong tracking protection and Firefox and Safari already have this. I assume the codebase will support both partitioned and unpartitioned storage for some time into the future due to enterprise policy and perhaps other knobs that might impact Chrome, and so other embedders like Edge are free to apply their own policy around when the partition storage and when not, right Mike? The existing deployment experience, data from other browsers, finch-controlled rollout & killswitch, dev trials, enterprise policy knob and webview opt-out seem like the complete suite of relevant compat mitigation risks. So I'm OK with this proceeding from a web compat perspective as you see fit Mike.
In terms of the standards / process piece, it looks as if the spec PRs have all stalled for several months. What do you think is necessary to get these unblocked and landed? As the last engine to implement this behavior, perhaps we shouldn't feel too compelled to block shipping on PRs landing? What about WPT or other interop testing? Are there any known cases where behavior is observably different between engines and any test cases we can provide to help quantify that and encourage alignment?
We have added a number of tentative WPTs (tentative until we land
the spec bits) to ensure that we don't regress partitioned storage
and match what other browsers are doing.
The one major difference that comes to mind is that we intend to ship blob URLs partitioned by StorageKey - it's been an open question whether to partition by StorageKey or agent cluster (see https://github.com/w3c/FileAPI/issues/153). Our plan was to start with StorageKey then investigate if agent cluster partitioning is feasible, but given that Firefox had to turn it off due to compat reasons (see https://bugzilla.mozilla.org/show_bug.cgi?id=1728192#c3 and associated regressions in https://bugzilla.mozilla.org/show_bug.cgi?id=1658878), StorageKey seems like the more compatible option for now.
Mike Taylor
> On 4/25/23 12:00 PM, Rick Byers wrote:
>
>> In terms of the standards / process piece, it looks as if the spec
>> PRs have all stalled for several months. What do you think is
>> necessary to get these unblocked and landed? As the last engine to
>> implement this behavior, perhaps we shouldn't feel too compelled to
>> block shipping on PRs landing?
question - oops.
Right now it seems to me that the costs of landing these spec PRs is
higher than we're willing to block on, given the requested refactoring
(and yes, it's unfortunate that 3 engines would be shipping essentially
unspecced behavior, but that's where we're at). That said, I'm happy to
devote my few IC hours to pushing these along as a personal project over
the coming months.
Rick Byers
Yoav Weiss
Mike Taylor
Thanks Rick and Yoav.
We learned from two partners (one internal, one external) late last week that a 3P deprecation trial would be needed for them to preserve widely-used functionality while they work on a migration strategy.
We're tracking the work in crbug.com/1441411 and hope to have
that ready by M115. Once we land the fix, I'll circle back and
look for a 3rd LGTM and have an updated rollout schedule. :)
Mike Taylor
OK - let's consider this I2S officially revived. Looking for a
3rd LGTM to begin shipping in M115.
We have implemented 3rd party deprecation trial support for M115+
(see
https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials),
and extended the deprecation trial's expiration date accordingly
to account for the delay. And we have the Enterprise policy ready
to go.
The rollout schedule will look something like the following, pending metrics and compatibility stability:
July 25th: 1% of Stable population (approximately 1 week after
M115 is released)
Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%
As always, if we discover significant user-facing breakage we'll explore pausing or rolling back to address.
thanks,
Mike
Mike West
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org.
Jagadeesha B Y
I see that Chrome 115 release notes - https://chromestatus.com/feature/5723617717387264 mentioning about storage partition being enabled by default. Could someone confirm how gradual this rollout is? do we know if storage partition is rolled out fully?
Kyra Seevers
Hi there,
Thank you for your email - as of today (Monday 7/24/23), the feature is not rolled-out to stable.
However, I can confirm that the rollout schedule for this feature begins in M115 at Stable 1% (once M115 is served to 100% of users). M115 is currently served to 12.5% of users - you can track the status at https://chromiumdash.appspot.com/releases?platform=Windows. Two weeks after that, we'll go to 10%, assuming no large stability or compatibility regressions. Then 50 and 100% at additional 2 week increments.
In the meantime, we have a deprecation trial (https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials) running in M115+ that allows sites who opt-in to maintain unpartitioned storage for a few milestones while they develop a storage-partitioning-compatible solution.
Thanks,
Kyra
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org.
Jagadeesha B Y
Kyra Seevers
Ben Kelly
Jagadeesha B Y
Vi S
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?
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
Vi S
Tim Williams
Tim Williams
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
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).
Kyra Seevers
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
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
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
We basically provide Salesforce with our embedded client URL, and they use it to load and embed our client in their iframe.
Tim Williams
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
Muhammad Ahmed Mallick
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
Chinmay Manchanda
Do we have an update on what time the feature will be rolled out today?
Cheers,
Chinmay
Kyra Seevers
Chinmay Manchanda
- 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?
Chinmay
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
| 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?
- 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?
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
Manish Bisht
Kyra Seevers
Illia Kyselov
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
Jayakrishnan Gounder
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 Kyra,Could we get an update on the status of the rollout to Stable users?Regards
James Leskovar
James Leskovar
James Leskovar
Russel Simmons
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:
Mike Taylor
Thank you very much for the bug report!
Mike Taylor
Hi Brett,
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
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?
Brett
Brett McStotts
Arthur Furman
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
Ari Chivukula
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,EliOn 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:
- Do you plan to use First-Party Sets to put your consent management site in the same FPS as your customers' sites? (Note that you would have to work around the FPS disjointness requirement, e.g. using CNAMEs.) That would allow your product to continue to do limited cross-site data sharing, although it would have to use cookies to do so.
- FYI, both the Storage Access API and Chromium's proposed extension (requestStorageAccessFor) only unblock access to unpartitioned cookies; they do not unblock access to unpartitioned storage. (You may already know this, since you linked to the relevant Storage Access API issue.) Please feel free to comment on that issue if it would address a critical use case for your product.
- If you're expecting to use First-Party Sets to enable limited cross-site data sharing, you may be interested in https://github.com/WICG/first-party-sets/issues/111 and/or https://github.com/WICG/first-party-sets/issues/94 (which admittedly is related to cookies). Please feel free to comment on those issues if either of them would address your use case; we're actively looking for feedback to help us shape and motivate/prioritize those proposals.
Thanks,ChrisOn 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 usefulAPIs 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,EliOn 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.