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.
