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 >>> >>> >>> >>> 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 >>> cookies design 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 >>> >>> -- >>> 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/CAOmohSKtWYE%2BZEqOr_0sVOifzETg8av10V2ggNkjznRZiCkswA%40mail.gmail.com.
