On 4/24/23 2:11 PM, Yoav Weiss wrote:
Apologies for my slowness!
On Thu, Apr 6, 2023 at 2:01 AM Mike Taylor <miketa...@chromium.org> wrote:
On 4/4/23 11:51 PM, Yoav Weiss wrote:
Thanks for working on this!!
Aligning with Safari and Firefox on this means that this is
important not just for user privacy, but also from an interop
perspective. It also gives us some confidence that this
deprecation can be successful.
This is effectively a deprecation, but one where I can't think of
a reasonable way to measure usage, so it seems to me that a
careful rollout + deprecation trial (as you're suggesting) is the
way to go here.
Yeah, I'm hopeful that the web has adjusted to this as the norm
given Firefox and Safari's behavior, but we know that Firefox had
some site breakage to deal with when they first introduced the
feature, so I'd rather be cautious with the rollout to avoid any
major incidents.
Is the deprecation trial enabled as a 3P OT? That may ease the
deployment for platform providers that have a hard time shipping
header changes to a large set of origins.
We made the decision to not support 3Ps for the deprecation trial.
Instead, when a site enables the Deprecation trial, all of its
embedded frames will have a 1st party StorageKey. Our thinking was
that we wanted the embedder to be in control of its users'
storage, rather than the embeddee. But if this turns out to be
untenable, we're open to considering making this work as a 3P
trial as well.
The scenario I'm slightly concerned about is a large platform
(ecommerce, CRM, etc) with a ~gazillion different customer origins,
that is currently relying on any of these APIs to communicate common
state (e.g. checkout flows).
Such a platform would most probably be able to opt-in using a 3P OT
(by delivering a common origin script that does the opt-in), but may
not be able to opt-in each origin individually.
It's probably fine to make sure that only the top-level frame can
participate in the 3P OT, although I'm not 100% sure if that's how 3P
OTs are currently wired.
+Panos Astithas <mailto:pastit...@google.com> may know.
Yeah, that's a fair concern. To date, we're not aware of any such use
cases or site breakage - but that doesn't mean it's not out there. :) We
have engaged with one large enterprise SaaS platform to encourage early
testing last September, and thus far haven't heard anything concerning
from them.
We're hoping that turning this on at 1% might flush out some of these
possible scenarios and help us decide if we need to re-think how the
Deprecation Trial works, or even the launch plan (perhaps launching
behind the "Block 3P cookies" setting to start with). After thinking a
bit more, it probably makes sense to hold at 1% for longer than the
original 2 weeks, perhaps 4 weeks instead. Given that Gecko and WebKit
have already shipped partitioned storage, I'm hopeful that things aren't
so dire - but we may just discover how much of the web isn't tested or
supported in those engines.
Also, have we reached out to the usual suspects to make sure they
test this change ahead of time?
We have been in touch with some partners through our partnership
team, and other top sites as well. :)
On Wed, Apr 5, 2023 at 12:44 AM Mike Taylor
<miketa...@chromium.org> wrote:
**
*Contact emails*
*
wanderv...@chromium.org, m...@chromium.org, mikety...@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/e8540107-85b2-a113-6347-1290c23f6379%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e8540107-85b2-a113-6347-1290c23f6379%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/482f0215-8ded-fe8b-9765-423567625f41%40chromium.org.
