Hey Mike, Thanks for your comments, let me address your two points:
I'd be happier if we'd been able to keep the `__Host-`-like restrictions on > `Domain` and `Path` (even if not the prefix); that seems like a missed > opportunity, given that we're going to need to support CHIPS into the > indefinite future. The patch removing these requirements ( > https://github.com/privacycg/CHIPS/pull/46) references discussion on a > PrivacyCG(?) call, but I wasn't able to find minutes. Could you help me > understand the rationale? The PrivacyCG feedback is best summarized here <https://github.com/privacycg/meetings/blob/main/2022/telcons/07-14-minutes.md#should-chips-be-hostname-bound-the-no-domain-requirement-43> but the notes are sparse. While it would be ideal to keep the Domain restriction, we came to the conclusion that requiring no-Domain will make adoption of partitioned cookies more difficult for websites based on partner feedback (example <https://github.com/privacycg/CHIPS/issues/39>), since there is significant site re-architecting that may be needed to adapt to the requirement. As for Path, restricting Path to only "/" seems not necessary after removing the Domain restriction. During a PrivacyCG call on the matter, we also heard from partners that third-party embeds have use cases for setting cookie paths. You can see notes on the call here <https://github.com/privacycg/CHIPS/issues/47>. We are still requiring that cookies set with Partitioned should be set with Secure, and have no plans to remove that requirement. There are a few issues open against the spec that seem like they ought to > be resolved before shipping. https://github.com/privacycg/CHIPS/issues/58, > https://github.com/privacycg/CHIPS/issues/40, and > https://github.com/privacycg/CHIPS/issues/2 all seem like they would > benefit from explicit resolution. Do you think those ought to be considered > blockers? Let me address each issue you linked: For issue 58, "Specify what happens when partitioned cookies collide with same-name unpartitioned cookies," we believe that the correct behavior is to save and send both cookies. There is precedent for saving/storing multiple cookies with the same name. The Storage Model section of RFC626bis already defines how to handle cookies with the same name by treating cookies as unique based on their {name, domain, path}. Our implementation adds the cookie's partition key to this tuple. We have added a PR <https://github.com/DCtheTall/CHIPS-spec/pull/9> to our draft spec which we are publishing to the IETF datatracker. The issue has been closed now. Issue 40, "Keying of "CHIPS" cookies should align with other state," can be reworded as "Should the cookie partition key have a cross-site ancestor chain bit?". The primary difference between Chromium’s storage partition key and cookie partition key is that the storage key has an additional bit which indicates whether the frame has a cross-site ancestor. This was added in order to fix an existing limitation where SameSite cookie semantics are not accounted for <https://github.com/privacycg/storage-partitioning/issues/25> in service workers. Our thinking is that this bit is not relevant for the cookie partition key, since site developers can restrict which cookies are available in embedded contexts using the SameSite attribute already. Issue 2, "User agents should indicate to servers whether a request is cross-site," we have not come to a solution for this but we think that mechanism applies to state partitioning broadly (not just CHIPS), and probably doesn't affect the UA's treatment of cookies. So, our request is to not treat this as a blocker for the launch of CHIPS. Given that we have closed #58, #40 has a proposed resolution, and #2 should not be a blocker for the launch of CHIPS, we think we are ready to ship. — Hey Rick, Let me answer your question as well. > I see there is one failing > <https://wpt.fyi/results/cookies/partitioned-cookies/partitioned-cookies.tentative.https.html?label=master&label=experimental&aligned&view=subtest&q=cookies%2Fpartitioned-cookies%2F> > subtest on Chrome 108. Known issue that will be fixed prior to shipping? That failure is expected since partitioned cookies are not enabled in Chrome 108. Cookies set with the Partitioned attribute in that version will create unpartitioned third-party cookies. Once the feature is enabled in Chrome 109 then the test should pass. > Also the harness is failing on Safari and Firefox, is that just because > the test has a dependency on the Cookie Store API (while CHIPS is > orthogonal from the API)? That is entirely possible. Good catch! I am fixing this and will have a CL up shortly. > If Firefox decided to implement CHIPS but not Cookie Store > <https://mozilla.github.io/standards-positions/#cookie-store> would we be > able / willing to modify the tests to pass on Firefox? I suppose any CookieStore-related test could be guarded on the existence of window.cookieStore, so that those tests are skipped if the browser does not support the API. On Fri, Oct 28, 2022 at 12:00 PM Rick Byers <rby...@chromium.org> wrote: > I'm excited to see this being close to shipping! Minor questions on the > tests below: > > On Tue, Oct 25, 2022 at 5:00 AM Mike West <mk...@chromium.org> wrote: > >> Thanks for the work you've put in through security and privacy review on >> this feature. It's an important step towards our ability to remove >> third-party cookie access, and I'm looking forward to seeing it used more >> widely in the future as we continue down that path. That said, I have a few >> thoughts: >> >> 1. I'd be happier if we'd been able to keep the `__Host-`-like >> restrictions on `Domain` and `Path` (even if not the prefix); that seems >> like a missed opportunity, given that we're going to need to support CHIPS >> into the indefinite future. The patch removing these requirements ( >> https://github.com/privacycg/CHIPS/pull/46) references discussion on a >> PrivacyCG(?) call, but I wasn't able to find minutes. Could you help me >> understand the rationale? >> >> 2. There are a few issues open against the spec that seem like they ought >> to be resolved before shipping. >> https://github.com/privacycg/CHIPS/issues/58, >> https://github.com/privacycg/CHIPS/issues/40, and >> https://github.com/privacycg/CHIPS/issues/2 all seem like they would >> benefit from explicit resolution. Do you think those ought to be considered >> blockers? >> >> -mike >> >> >> On Thu, Oct 20, 2022 at 11:33 PM 'Dylan Cutler' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> *Estimated Milestone for Shipping:* >>> 109 >>> >>> Apologies, I included the OT milestones instead... >>> >>> On Thu, Oct 20, 2022 at 4:57 PM Dylan Cutler <dylancut...@google.com> >>> wrote: >>> >>>> Contact emails: >>>> >>>> dylancut...@google.com, kaustub...@google.com >>>> >>>> Proposal repository: >>>> >>>> https://github.com/privacycg/CHIPS >>>> >>>> Design doc: >>>> >>>> >>>> https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing >>>> >>>> Specification: >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/ >>>> >>>> Summary: >>>> >>>> Given that Chrome plans to deprecate unpartitioned third-party cookies, >>>> we want to give developers the ability to use cookies in cross-site >>>> contexts that are partitioned by top-level site to meet use cases >>>> <https://developer.chrome.com/en/docs/privacy-sandbox/chips/#use-cases> >>>> that don't track users cross-site (e.g. SaaS embeds, headless CMS, sandbox >>>> domains, etc.). Chrome will introduce a mechanism to opt into having >>>> third-party cookies partitioned by top-level site using a new cookie >>>> attribute, Partitioned. >>>> >>>> Since we announced our Intent to Experiment >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_dJFNJpf91U/m/OXzFi_6wAwAJ?utm_medium=email&utm_source=footer> >>>> with CHIPS, there have been some changes to the API: >>>> >>>> >>>> - >>>> >>>> The Partitioned attribute no longer requires >>>> <https://github.com/privacycg/CHIPS/pull/46> the __Host- prefix or >>>> its required attributes. The Secure requirement remains. >>>> - >>>> >>>> We are changing the per-partition-per-domain limit to be based on >>>> the total size (in bytes) of the cookies set by a domain in a particular >>>> partition in addition to the number of cookies. We intend >>>> <https://github.com/privacycg/CHIPS/issues/48#issuecomment-1264126065> >>>> to impose a limit of 10 KB per-embedded-site, per-top-level-site and >>>> increase the numeric limit from 10 to 180. >>>> - >>>> >>>> For sites embedded in top-level domains that are in a First-Party >>>> Set <https://github.com/WICG/first-party-sets>, their cookies' >>>> partition key will no longer be the owner domain of that set. Rather, >>>> the >>>> partition key will always be the top-level domain that the cookie was >>>> created on. >>>> >>>> >>>> Blink component: >>>> >>>> Internals>Network>Cookies >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies> >>>> >>>> TAG review: >>>> >>>> https://github.com/w3ctag/design-reviews/issues/654 (Supportive early >>>> review) >>>> >>>> https://github.com/w3ctag/design-reviews/issues/779 (Oct 19 >>>> specification review) >>>> >>>> Risks >>>> >>>> Interoperability and Compatibility >>>> >>>> Firefox: Positive >>>> <https://mozilla.github.io/standards-positions/#chips> >>>> >>>> WebKit: Supported incubation >>>> <https://github.com/privacycg/proposals/issues/30#issuecomment-1113257336>, >>>> Official position pending >>>> <https://github.com/WebKit/standards-positions/issues/50> >>>> >>>> Web developers: Developers have indicated that CHIPS does solve for >>>> many use cases that depend on access to cookies in cross-site contexts ( >>>> 1 <https://github.com/privacycg/CHIPS/issues/8>, 2 >>>> <https://github.com/privacycg/CHIPS/issues/30#issuecomment-1104225686>, >>>> 3 >>>> <https://triplelift.com/privacy-hub/w3c-proposals-explained-privacy-with-a-side-of-chips/>). >>>> Through incubation, and the Origin Trial, we received feedback to improve >>>> ease-of-use, particularly to allow for easier migration of existing systems >>>> to use CHIPS. We believe we have satisfactorily resolved these concerns >>>> (see changes made listed under Summary section). >>>> >>>> Other signals: >>>> >>>> Ergonomics >>>> >>>> N/A >>>> >>>> >>>> Activation >>>> >>>> This feature introduces a new cookie attribute, Partitioned, which is >>>> opt-in only. Sites which do not set their cookies with Partitioned should >>>> not see any change in the browser's behavior when we ship. >>>> >>>> >>>> Security >>>> >>>> See S&P questionnaire for TAG >>>> <https://github.com/privacycg/CHIPS/blob/main/TAG-S%26P-questionnaire.md> >>>> >>>> >>>> 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? >>>> >>>> This feature does not deprecate or change behavior of existing APIs. >>>> This feature is behind a killswitch. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>> >>>> Yes >>>> >>>> Is this feature covered by web platform tests? >>>> >>>> Yes >>>> <https://github.com/web-platform-tests/wpt/tree/master/cookies/partitioned-cookies> >>>> >>> > I see there is one failing > <https://wpt.fyi/results/cookies/partitioned-cookies/partitioned-cookies.tentative.https.html?label=master&label=experimental&aligned&view=subtest&q=cookies%2Fpartitioned-cookies%2F> > subtest > on Chrome 108. Known issue that will be fixed prior to shipping? > > Also the harness is failing on Safari and Firefox, is that just because > the test has a dependency on the Cookie Store API (while CHIPS is > orthogonal from the API)? If Firefox decided to implement CHIPS but not > Cookie Store <https://mozilla.github.io/standards-positions/#cookie-store> > would > we be able / willing to modify the tests to pass on Firefox? > > Flag name >>>> >>>> partitioned-cookies >>>> >>>> Requires code in //chrome? >>>> >>>> No >>>> >>>> Tracking bug: >>>> >>>> https://crbug.com/1225444 >>>> >>>> Non-OSS dependencies >>>> >>>> Does the feature depend on any code or APIs outside the Chromium open >>>> source repository and its open-source dependencies to function? >>>> >>>> Not anymore than cookies already do now. >>>> >>>> Estimated milestones >>>> >>>> OriginTrial desktop last >>>> >>>> 106 >>>> >>>> OriginTrial desktop first >>>> >>>> 100 >>>> >>>> OriginTrial Android last >>>> >>>> 106 >>>> >>>> OriginTrial Android first >>>> >>>> 100 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> >>>> List of open issues: https://github.com/privacycg/CHIPS/issues >>>> >>>> Chrome Platform Status page: >>>> >>>> https://chromestatus.com/feature/5179189105786880 >>>> >>>> Links to previous Intent discussions >>>> >>>> Intent to Prototype: >>>> >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo/ >>>> >>>> Intent to Experiment: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/_dJFNJpf91U/m/YqP09XbbAgAJ >>>> >>>> Intent to Extend Experiment: >>>> >>>> >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/kZRtetS8jsY/m/ppK4kDbqAwAJ >>>> >>>> >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/MKQODOL0Fso/m/nZXI2dqwAQAJ >>>> >>>> -- >>> 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/CAMCNMFScgacg%3D3ueyRyOtUz4QnoJiYA9BKTryeWp_%2B%3D1Mi6yRg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFScgacg%3D3ueyRyOtUz4QnoJiYA9BKTryeWp_%2B%3D1Mi6yRg%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/CAKXHy%3Dcyb4d07a8PO8LUsSCTR3W2qM_ur43mejN4D_6t2XGc9Q%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dcyb4d07a8PO8LUsSCTR3W2qM_ur43mejN4D_6t2XGc9Q%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/CAMCNMFQf4ZOb1mqnfA3UX3aXVnoDC4M0gg-FLpJ2HAfk1r7UyA%40mail.gmail.com.
