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. On Fri, Apr 14, 2023, 10:36 AM Ben Kelly <wanderv...@chromium.org> wrote: > > > 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. > > >> >> 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. >> >> >> >> On Thu, Apr 13, 2023, 18:30 Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> 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. >>> >>> On Fri, Apr 14, 2023 at 7:06 AM Eric Lawrence <bay...@gmail.com> wrote: >>> >>>> 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. >>>> >>>> >>>> On Monday, April 10, 2023 at 5:07:37 PM UTC-5 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). >>>>> 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 >>>>>> <https://github.com/WICG/first-party-sets#abuse-mitigation-measures>, >>>>>> 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 >>>>>> <https://github.com/privacycg/storage-access/issues/102>.) 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 >>>>>>> <https://github.com/privacycg/requestStorageAccessFor> (FPS-scoped) >>>>>>> or something else extending the storage API >>>>>>> <https://github.com/privacycg/storage-access/issues/102> 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 >>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1431031>. >>>>>>> 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 >>>>>>>> <https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline>. >>>>>>>> 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 >>>>>>>>> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md> >>>>>>>>> Specification Partitioned Storage is roughly specified at >>>>>>>>> https://privacycg.github.io/storage-partitioning/ >>>>>>>>> <https://privacycg.github.io/storage-partitioning/>. As part of this >>>>>>>>> work, >>>>>>>>> we have started to codify the necessary concepts in HTML, DOM, and >>>>>>>>> Storage >>>>>>>>> in the following PRs: https://github.com/whatwg/storage/pull/144 >>>>>>>>> <https://github.com/whatwg/storage/pull/144> >>>>>>>>> https://github.com/whatwg/dom/pull/1142 >>>>>>>>> <https://github.com/whatwg/dom/pull/1142/files> >>>>>>>>> https://github.com/whatwg/html/pull/8447 >>>>>>>>> <https://github.com/whatwg/html/pull/8447> We have also updated >>>>>>>>> other APIs >>>>>>>>> to use StorageKey (ServiceWorker [1 >>>>>>>>> <https://github.com/w3c/ServiceWorker/pulls?q=is%3Apr+is%3Aclosed+partition>], >>>>>>>>> BroadcastChannel [1 <https://github.com/whatwg/html/pull/7567>], >>>>>>>>> SharedWorker[1 <https://github.com/whatwg/html/pull/7995>]), and >>>>>>>>> landed >>>>>>>>> necessary additions to Storage itself ([1 >>>>>>>>> <https://github.com/whatwg/storage/commit/bea19b70f497d7059c920b9f0a81ac8f49bd36ed>][2 >>>>>>>>> <https://github.com/whatwg/storage/commit/c68c38413c02496114d51af28caa83d11689d300>]). >>>>>>>>> What we thought to be a straightforward set of changes has evolved to >>>>>>>>> be a >>>>>>>>> more complex refactoring, per the request of HTML editors. We propose >>>>>>>>> to >>>>>>>>> ship with a WIP spec spread out across the PRs above (noting that >>>>>>>>> Firefox >>>>>>>>> and Safari have already shipped partitioned storage). That said, we >>>>>>>>> intend >>>>>>>>> to finish this work. Summary We intend to partition a number of APIs >>>>>>>>> in >>>>>>>>> third-party contexts. This effort is focused on partitioning APIs >>>>>>>>> above the >>>>>>>>> network stack. This includes quota-managed storage, service workers, >>>>>>>>> and >>>>>>>>> communication APIs (like BroadcastChannel). See the explainer for more >>>>>>>>> details: >>>>>>>>> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md >>>>>>>>> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md> >>>>>>>>> Blink component Blink>Storage TAG review >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/629 >>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/629> TAG review >>>>>>>>> status >>>>>>>>> Resolution: Satisfied Risks Interoperability and Compatibility Given >>>>>>>>> that >>>>>>>>> Firefox and Safari have already shipped this feature, we expect our >>>>>>>>> implementation to be interoperable. We are aware of breakage >>>>>>>>> <https://github.com/privacycg/storage-partitioning/issues/34#issuecomment-1194358637> >>>>>>>>> for sites that use Firebase for authentication (because it relies on >>>>>>>>> being >>>>>>>>> able to access unpartitioned sessionStorage). Firebase has blogged on >>>>>>>>> how >>>>>>>>> sites can mitigate this issue >>>>>>>>> <https://firebase.google.com/docs/auth/web/redirect-best-practices>. >>>>>>>>> We >>>>>>>>> built a deprecation trial specifically for the sessionStorage >>>>>>>>> redirect use >>>>>>>>> case, which should work for Firebase users. In addition, we have a >>>>>>>>> general >>>>>>>>> deprecation trial available and enterprise policies in place. See >>>>>>>>> below for >>>>>>>>> more info on the deprecation trials. We’ve made storage partitioning >>>>>>>>> available for local testing in Chrome for the past 6 months >>>>>>>>> <https://developer.chrome.com/en/blog/storage-partitioning-dev-trial/>. >>>>>>>>> Apart from Firebase, we’re not aware of any existing compatibility >>>>>>>>> issues >>>>>>>>> that can’t be solved by the deprecation trials >>>>>>>>> <https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/>. >>>>>>>>> There may be unforeseen contexts and use cases that rely on >>>>>>>>> unpartitioned >>>>>>>>> storage and as such, we propose to roll this feature out carefully via >>>>>>>>> Finch, according to the following proposed schedule: May 9th: 1% of >>>>>>>>> Stable >>>>>>>>> population (approximately 1 week after M113 is released) May 23rd: >>>>>>>>> 10% June >>>>>>>>> 6th: 50% June 20th: 100% As usual, if we identify concerning metrics, >>>>>>>>> regressions, or site breakage reports, we may pause or roll back to >>>>>>>>> investigate or address issues. Deprecation trial instructions: >>>>>>>>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ >>>>>>>>> <https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/> >>>>>>>>> Gecko: Shipped/Shipping WebKit: Shipped/Shipping Web developers: Mixed >>>>>>>>> signals. Some developers have expressed compatibility concerns, >>>>>>>>> others have >>>>>>>>> been supportive. Other signals: WebView application risks Does this >>>>>>>>> intent >>>>>>>>> deprecate or change behavior of existing APIs, such that it has >>>>>>>>> potentially >>>>>>>>> high risk for Android WebView-based applications? No, we don’t intend >>>>>>>>> to >>>>>>>>> turn this on for WebView yet. Debuggability DevTools has support for >>>>>>>>> partitioned storage. Will this feature be supported on all six Blink >>>>>>>>> platforms (Windows, Mac, Linux, Chrome OS, Android, and Android >>>>>>>>> WebView)? >>>>>>>>> No (not WebView) Is this feature fully tested by web-platform-tests? >>>>>>>>> Yes. >>>>>>>>> We’ve written WPTs to verify our 3rd party storage partitioning. Flag >>>>>>>>> name >>>>>>>>> ThirdPartyStoragePartitioning Requires code in //chrome? Nope >>>>>>>>> Tracking bug >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1191114 >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1191114> >>>>>>>>> Launch bug >>>>>>>>> https://launch.corp.google.com/launch/4214498 >>>>>>>>> <https://launch.corp.google.com/launch/4214498> Anticipated spec >>>>>>>>> changes >>>>>>>>> Open questions about a feature may be a source of future web compat or >>>>>>>>> interop issues. Please list open issues (in other words, links to >>>>>>>>> known >>>>>>>>> GitHub issues in the project, for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (such as changes to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). None Link >>>>>>>>> to >>>>>>>>> entry on the Chrome Platform Status >>>>>>>>> https://chromestatus.com/feature/5723617717387264 >>>>>>>>> <https://chromestatus.com/feature/5723617717387264> Links to previous >>>>>>>>> Intent discussions Intent to Prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ> >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/FNi-nNC8fiw/m/gNftPAzUBgAJ >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/FNi-nNC8fiw/m/gNftPAzUBgAJ> >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/42a5bada-46cb-4508-8e63-fa88ea0570a1n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgkdWP75j99qiB3-LPgCWb8twWYehDdUJdmzpANhSmafA%40mail.gmail.com.
