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/CAGpy5DLBC0j1F-5GfdVcqhmAk6FzP5LRF-M7JCnuVZzoYK4X-Q%40mail.gmail.com.
