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/CAM0wra9SnUy3iPaqspOQyWZ1eoE5cA88JHJ5p6GjZ_RaFv25CQ%40mail.gmail.com.
