It would also be helpful to discuss what breakage looks like in this
case. Would it be a one-time loss of state (i.e., have to log in again),
or something different?
On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
OK, so just to summarize my understanding:
* We expect this to have some impact on 0.032% of page views
* We have a Finch flag that can be used as a kill switch in case we
see lots of breakage in the wild
* Developers can get around this deprecation by changing their
cookies to be "same-site: none" *and* requesting SAA from users
Is the above correct?
If so, 0.032% sounds like a lot. Would it be possible for y'all to
same pages that trigger that use counter and see how many of them
break and what does breakage look like?
On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya <se...@google.com> wrote:
The flag is a base::features flag named
kAncestorChainBitEnabledInPartitionedCookies.
Updated the review gates on chromestatus.com <http://chromestatus.com>
On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
Also, can you flip on the relevant review gates in
chromestatus.com <http://chromestatus.com>?
On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via
blink-dev <blink-dev@chromium.org> wrote:
The first mitigation listed here is to migrate
existing partitioned cookies to include the new
bit, and the second mitigation is to have a flag
that can disable this feature. Would disabling the
feature also include migrating the existing
cookies back to exclude the new bit?
Disabling the flag would not migrate the existing
cookies back to exclude the new bit. It would make it
so that the new bit value is not considered when
checking equivalence. Not considering the value of the
bit when is the current behavior so we anticipate no
issues ignoring the bit if the flag needs to disable
the feature.
Can you clarify what kind of flag are we talking about? Is
this a Finch flag we expect to turn off if we encounter
lots of breakage? An enterprise policy flag? A flag we
expect users to use? (I doubt it's the latter, but
clarifications would help :D)
And somewhat related, but does the format of the
cookie request developers make have to change too,
or is this bit determination purely done within
the browser?
In almost all cases this is set within the browser.
The only circumstance I've run into where the value
could be set by a developer is with the
chrome.cookies.set api for extensions. This API
allows the developer to set the site associated with
the cookie partition key and with this change would
allow for the bit value to be set as well.
On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin
<vmp...@chromium.org> wrote:
On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya
<se...@chromium.org> wrote:
Contact emails
se...@chromium.org, dylancut...@chromium.org,
kaustub...@chromium.org
Explainer
Keying of "CHIPS" cookies should align with
other state:
<https://github.com/privacycg/CHIPS/issues/40#issuecomment-1883726735>
Specification
Add cross-site ancestor chain bit to spec:
https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
<https://github.com/explainers-by-googlers/CHIPS-spec/pull/13>
Summary
We are looking to align the partition key
<https://developers.google.com/privacy-sandbox/3pcd/chips#:~:text=A%20cookie%27s%20partition%20key%20is%20the%20site%20(scheme%20and%20registrable%20domain)%20of%20the%20top%2Dlevel%20URL%20the%20browser%20was%20visiting%20at%20the%20start%20of%20the%20request%20to%20the%20endpoint%20that%20set%20the%20cookie.>in
CHIPS (Cookies Having Independent Partitioned
State, aka partitioned cookies) with the
existing implementation of StorageKey.
The only sites that would experience different
behavior, would be when a top-level site “A”
embeds an iframe to a cross-site document on
site “B”, and then the iframe B embeds an
iframe that loads a document from site “A”
(shorthand: A1->B->A2). Previously,
partitioned cookies sent or received in the
inner iframe A2 would be the same partitioned
cookies sent or received in the outer frame
A1. This is no longer true.
This change is privacy neutral, but will have
improved security characteristics, because it
prevents cross-site iframes from embedding
arbitrary endpoints of the top-level site with
credentials, without first being granted
permission to do so through the Storage Access
API (SAA) or Cross-Origin Resource Sharing
(CORS).
The impact of this change is expected to be
small as our metrics indicate that only 0.2%
of CHIPS (partitioned cookies) set by the
first party are currently being used in
A1->B->A2 contexts. This constitutes 0.032% of
all page loads (calculated using the usage of
PartitionedCookie
<https://chromestatus.com/metrics/feature/timeline/popularity/4177>).
For websites that do need access to the same
cookies across A1 and A2 (in the A1->B->A2
configuration), we recommend using
SameSite=None cookies *without* the
Partitioned attribute, and invoking the
Storage Access API (SAA) or using the
Cross-Origin Resource Sharing (CORS).
Blink component
Internals>Network>Cookies>PartitionedCookies
<https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECookies%3EPartitionedCookies%22>
TAG review
Not requested, as this does not differ in any
significant way from the original CHIPS design
that was already reviewed by TAG
<https://github.com/w3ctag/design-reviews/issues/779>.
TAG review status
N/A
Risks
Interoperability and Compatibility
The inclusion of a new element in the
partition key will mean that partitioned
cookies (CHIPS) created after the launch of
this change will not be compatible with the
partitioned cookies that already exist in
users cookie jars. To address this, existing
partitioned cookies will be migrated (without
any need for developer action) to include the
new cross-site ancestor chain bit value, which
will be set with a value of true if the
existing partition key does not match the host
key (indicating a cross site ancestor is
present) and false if the partition key does
match the host key. This will ensure that most
existing CHIPS have the same scope as they did
prior to the change.
Only 0.2% of partitioned cookies are utilized
from within A1->B->A2 scenarios, but
developers who need to be able to access
cookies in A1->B->A2 scenarios will be able to
use SAA, and CORS to gain access to those
cookies, after transitioning to SameSite=None
cookies without the Partitioned attribute.
To limit the impact of any significant
breakages that may occur when this is
deployed, the new feature will be gated by a
flag allowing for it to be turned off easily.
Additionally metrics are being gathered to
proactively identify the sites that are going
to be impacted by this change, so that we can
do outreach to potentially impacted sites. As
this feature gets deployed, we will monitor
the bug and breakage reports to help identify
issues and assist developers in transitioning
to one of the other mechanisms that will allow
their sites to work in an A1->B->A2 context.
The first mitigation listed here is to migrate
existing partitioned cookies to include the new
bit, and the second mitigation is to have a flag
that can disable this feature. Would disabling the
feature also include migrating the existing
cookies back to exclude the new bit?
And somewhat related, but does the format of the
cookie request developers make have to change too,
or is this bit determination purely done within
the browser?
As this does not differ in any significant way
from the original partitioned cookiesdesign
that has been reviewed in the past, we are not
seeking the various browsers to take official
positions in their standards position repos.
There is support for the adoption of CHIPS
<https://github.com/mozilla/standards-positions/issues/678#issuecomment-1241916316>from
Firefox as well as support from them for
adding the cross-site ancestor chain bit
<https://github.com/privacycg/meetings/blob/main/2023/telcons/10-12-minutes.md#keying-of-chips-cookies-should-align-with-other-state>.
Webkit is still considering adopting CHIPS
<https://github.com/WebKit/standards-positions/issues/50#issuecomment-1768040057>as
we work through their concerns
<https://github.com/privacycg/CHIPS/issues/74>regarding
partition size limitations. This will not be
impacted by the addition of a cross-site
ancestor chain bit. We updated the WebKit
standards positions issue with a note
regarding this change to the proposal.
Debuggability
DevTools will need to be updated
<https://bugs.chromium.org/p/chromium/issues/detail?id=1516984>to
show the cross-site ancestor chain bit but
otherwise it should be able to be debugged
like other API calls.
Will this feature be supported on all
six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android
WebView)?
All platforms listed.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
We plan to land web-platform-tests shortly
<https://bugs.chromium.org/p/chromium/issues/detail?id=1521791>.
Flag name on chrome://flags
CookiePartitionKeyIncludesCrossSiteAncestorChainBit
<https://bugs.chromium.org/p/chromium/issues/detail?id=1521841>
Finch feature name
None
Could you please clarify if the flag you mentioned
is a Finch flag or something else?
Requires code in //chrome?
False
Estimated milestones
Targeted shipping on desktop and Android in M125.
Anticipated spec changes
None
Link to entry on the Chrome Platform
Status
https://chromestatus.com/feature/5144832583663616
<https://chromestatus.com/feature/5144832583663616>
--
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/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com?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/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com?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/CAOmohSL78hpV-iy6Ce%3Dn4a-aU21-2vj%2Bce4D9rLE_R0oUWKpqQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL78hpV-iy6Ce%3Dn4a-aU21-2vj%2Bce4D9rLE_R0oUWKpqQ%40mail.gmail.com?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/1db53a2f-cf82-4715-8aeb-b6153a507321%40chromium.org.
