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> >> >> * >> > -- 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/1411ffed-68f0-4583-84b6-c5a0e427ffd7n%40chromium.org.
