Hi Rick,
On 4/25/23 12:00 PM, Rick Byers wrote:
I share the concerns around compat risk and making the platform less
predictable for businesses. But I also don't see any alternative given
that at least Google Chrome is going ahead with strong tracking
protection and Firefox and Safari already have this. I assume the
codebase will support both partitioned and unpartitioned storage for
some time into the future due to enterprise policy and perhaps other
knobs that might impact Chrome, and so other embedders like Edge are
free to apply their own policy around when the partition storage and
when not, right Mike? The existing deployment experience, data from
other browsers, finch-controlled rollout & killswitch, dev trials,
enterprise policy knob and webview opt-out seem like the complete
suite of relevant compat mitigation risks. So I'm OK with this
proceeding from a web compat perspective as you see fit Mike.
Yep, that's correct - we'll need to support both paths for quite some
time, certainly at least for the enterprise policies, or perhaps other
use cases or modes we discover warrant unpartitioned storage.
In terms of the standards / process piece, it looks as if the spec PRs
have all stalled for several months. What do you think is necessary to
get these unblocked and landed? As the last engine to implement this
behavior, perhaps we shouldn't feel too compelled to block shipping on
PRs landing? What about WPT or other interop testing? Are there any
known cases where behavior is observably different between engines and
any test cases we can provide to help quantify that and encourage
alignment?
We have added a number of tentative WPTs (tentative until we land the
spec bits) to ensure that we don't regress partitioned storage and match
what other browsers are doing.
The one major difference that comes to mind is that we intend to ship
blob URLs partitioned by StorageKey - it's been an open question whether
to partition by StorageKey or agent cluster (see
https://github.com/w3c/FileAPI/issues/153). Our plan was to start with
StorageKey then investigate if agent cluster partitioning is feasible,
but given that Firefox had to turn it off due to compat reasons (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1728192#c3 and associated
regressions in https://bugzilla.mozilla.org/show_bug.cgi?id=1658878),
StorageKey seems like the more compatible option for now.
On Tue, Apr 25, 2023 at 10:52 AM Mike Taylor <miketa...@chromium.org>
wrote:
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/482f0215-8ded-fe8b-9765-423567625f41%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/73af946e-4e91-d5f1-4090-303432aa9189%40chromium.org.
