hasStorageAccess/hasUnpartitionedCookieAccess doesn’t tell us if storage partitioning is disabled. It just tells you if there is unpartitioned cookie access. That will always return false post-3PCD. It will also return true pre-3PCD with storage partitioning disabled.
We also can't call requestStorageAccess because Chrome's implementation requires a top-level interaction. Customers are interacting with our site solely embedded. So yeah it'd be great if there was an API to let us know if customers are in this storage partitioning disabled state. We could identify these customers and directly ask them to add an additional CookiesAllowedForUrls Enterprise Policy to allow our site local and session storage access. On Thu, Jul 11, 2024 at 1:11 PM Ari Chivukula <aric...@chromium.org> wrote: > That's not on our roadmap for now as > hasStorageAccess/hasUnpartitionedCookieAccess are there to help understand > the need to call requestStorageAccess to access cookies (they fit into a > larger use case pattern cross-browser). > > One way to get access to unpartitioned storage would be by using the new > handle returned from a call to requestStorageAccess outlined here: > https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess > > The handle returned would grant unpartitioned storage access whether or > not the calling context itself were partitioned. > > ~ Ari Chivukula (Their/There/They're) > > On Thu, Jul 11, 2024, 11:47 Brett McStotts <brett.mcsto...@gmail.com> > wrote: > >> Ok. I'm testing now and with Storage Partitioning Disabled + 3PCD a >> cross-origin iframe is blocked from accessing local storage, session >> storage, and DOMCache. I think this will cause unexpected behavior for >> sites using this Enterprise Policy next year when 3PCD takes effect. It'd >> be great if there was a Document API of hasUnpartitionedStorageAccess() >> similar to hasUnpartitionedCookieAccess >> <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasUnpartitionedCookieAccess> >> that >> would let us know if customers embedding our application are using this >> Enterprise Policy. >> >> On Tue, Jul 9, 2024 at 10:38 AM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Hi Brett, >>> >>> We don't yet have an expiration date set for >>> https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting, >>> or any concrete plans to add one. If and when we do decide to deprecate it, >>> we'll give a 6 months deprecation notice through the normal enterprise >>> policy channels. FWIW, I would like to remove it eventually - but I don't >>> expect it to happen this year. >>> >>> thanks, >>> Mike >>> On 7/5/24 12:37 PM, Brett McStotts wrote: >>> >>> >>> Can we confirm the above >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/WphjGBWtCAAJ>is >>> true that the DisableStoragePartitioning Enterprise Policy will also expire >>> on September 3rd, 2024? >>> >>> We've uncovered an upcoming issue for us with Storage Partitioning and >>> Partitioned cookies. We have Site A that embeds Site B in an iframe. Site B >>> uses a Shared Worker that refreshes an access cookie. Disabling Storage >>> Partitioning makes the Shared Worker a top-level context. So if the >>> SharedWorker for the iframed sets a Partitioned cookie, the cookie will >>> have a partition key of Site B. Therefore, it won't be accessible in the >>> iframe embedded under Site A. >>> >>> We're setting both a partitioned and unpartitioned cookie right now so >>> it's fine. But after 3PCD the unpartitioned cookie won't be available. >>> We'll have to tell customers embedding our site who are using the >>> DisableStoragePartitioning Enterprise Policy to also use the >>> CookiesAllowedForUrls Enterprise policy. Or make architecture changes. >>> >>> However, if the Enterprise Policy is expiring then this is a non-issue. >>> On Monday, December 4, 2023 at 10:54:40 AM UTC-5 ari...@chromium.org >>> wrote: >>> >>>> Heads up that there's an Origin Trial which allows unpartitioned access >>>> to some storage and communication mechanisms via SAA (the same mechanism >>>> that grants unpartitioned cookie access): >>>> https://developer.chrome.com/blog/saa-non-cookie-storage/ >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Mon, Apr 10, 2023 at 6:07 PM 'Elijah Grey' via blink-dev < >>>> blin...@chromium.org> wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> I appreciate your response. Here are my responses to your points: >>>>> >>>>> 1. Yes, we plan to use FPS to put our consent management tool in the >>>>> same FPS (using <customer-id>.sync.transcend.io as a service domain >>>>> per customer, alternatively CNAME-backed by the customer). We will still >>>>> be >>>>> forced to reduce customers' users' privacy by sharing user consent data >>>>> through cookies (and completely lose our ability to sync quarantine data >>>>> cross-site as it cannot safely be included in network requests through >>>>> cookies). >>>>> 2. Thanks, I'll make sure to leave a comment about our use case. >>>>> 3. Same as above. I'll expound on my use case in that issue too. >>>>> >>>>> Again, I posit that the non-ideal alignment of these unpartitioned >>>>> storage deprecation timelines will push site owners to use cookies to >>>>> share >>>>> state where they previously did not have to use cookies. A non-cookie >>>>> solution should be available prior to the deprecation point to prevent >>>>> adverse incentives from affecting the web as a whole. >>>>> >>>>> I understand that the actual harms are likely minor, but they are >>>>> measurable. We attempt to limit total entropy of consent data propagated >>>>> by >>>>> our sync system, but even with our best efforts it is not unreasonable to >>>>> assume that bad actors would use the uniqueness of consent cookies (e.g. >>>>> by >>>>> looking at timestamps etc.) to uniquely track users. Our current system >>>>> does not attempt to uniquely track users and serves as an enforcement >>>>> point >>>>> to prevent other tools from uniquely tracking users for certain purposes >>>>> without consent (depending on user-applicable legal regimes). >>>>> >>>>> Regards, >>>>> Eli >>>>> On Monday, April 10, 2023 at 10:45:09 AM UTC-7 Chris Fredrickson wrote: >>>>> >>>>>> Hi Eli, >>>>>> >>>>>> If I can chime in on a few points from the First-Party Sets >>>>>> perspective: >>>>>> >>>>>> 1. Do you plan to use First-Party Sets to put your consent >>>>>> management site in the same FPS as your customers' sites? (Note that >>>>>> you >>>>>> would have to work around the FPS disjointness requirement >>>>>> <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+...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/494b3f4b-b9de-4fac-8e83-2555d2d3a9a3n%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/CALmWzr2z-hwfWYt0MYfNDHnmb%3D0whANNe0fxGrAkVd9FdVG-YQ%40mail.gmail.com.
