It's going to be surprising to developers that BroadcastChannel is
"storage"
On Thu, Apr 13, 2023, 4:30 PM Domenic Denicola <dome...@chromium.org>
wrote:
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 <http://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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9SnUy3iPaqspOQyWZ1eoE5cA88JHJ5p6GjZ_RaFv25CQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
