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/f950db13-d4e0-3cd2-99f9-6d2eda9d8f3d%40chromium.org.
