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/CALmWzr3gFzFNkdTeq31YWB_MS-2AN7%3DdN6PSMQpoER-Uv4SY7A%40mail.gmail.com.
