Can we confirm the above
<https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/WphjGBWtCAAJ>is
true that the DisableStoragePartitioning Enterprise Policy will also
expire on September 3rd, 2024?
We've uncovered an upcoming issue for us with Storage Partitioning and
Partitioned cookies. We have Site A that embeds Site B in an iframe.
Site B uses a Shared Worker that refreshes an access cookie. Disabling
Storage Partitioning makes the Shared Worker a top-level context. So
if the SharedWorker for the iframed sets a Partitioned cookie, the
cookie will have a partition key of Site B. Therefore, it won't be
accessible in the iframe embedded under Site A.
We're setting both a partitioned and unpartitioned cookie right now so
it's fine. But after 3PCD the unpartitioned cookie won't be available.
We'll have to tell customers embedding our site who are using the
DisableStoragePartitioning Enterprise Policy to also use the
CookiesAllowedForUrls Enterprise policy. Or make architecture changes.
However, if the Enterprise Policy is expiring then this is a non-issue.
On Monday, December 4, 2023 at 10:54:40 AM UTC-5 ari...@chromium.org
wrote:
Heads up that there's an Origin Trial which allows unpartitioned
access to some storage and communication mechanisms via SAA (the
same mechanism that grants unpartitioned cookie access):
https://developer.chrome.com/blog/saa-non-cookie-storage/
~ Ari Chivukula (Their/There/They're)
On Mon, Apr 10, 2023 at 6:07 PM 'Elijah Grey' via blink-dev
<blin...@chromium.org> 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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/494b3f4b-b9de-4fac-8e83-2555d2d3a9a3n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/494b3f4b-b9de-4fac-8e83-2555d2d3a9a3n%40chromium.org?utm_medium=email&utm_source=footer>.
