Hi Dylan, I am working along with Marcelo on this POC. We have been able to make progress.
I see 2 options on chrome://flags partitioned-cookies & partitioned-cookies-bypass-origin-trial Which flag am I supposed to use? One thing I have noticed that seemed odd and wanted to see if thats an expected behavior. We have a small dummy app that just creates a cookie foo-bar and print the value in UI https://dim-connect.herokuapp.com/tile We embed this in iFrame in our Enterprise App. >From Tab 1 - I go to https://dim-connect.herokuapp.com/tile, a cookie fooBar-1 is created with Partition Key of https://dim-connect.herokuapp.com >From Tab 1 - I log in to Our Enterprise App I see a cookie fooBar-2 is created with Partition Key of http://<enterprise domain name>.com So far so good. Now if I go to the Tab 1 and delete cookie fooBar-1, It also seem to delete cookie fooBar-2 Is this expected? On Thursday, March 31, 2022 at 5:21:13 PM UTC-4 Dylan Cutler wrote: > Hey Marcelo, > > M100 is when we are starting the origin trial > <https://developer.chrome.com/blog/origin-trials/> for CHIPS. In order to > use partitioned cookies. You must register for the trial > <https://developer.chrome.com/origintrials/#/view_trial/1239615797433729025>, > and have your server send the Origin-Trial and Accept-CH: > Sec-CH-Partitioned-Cookies response headers to participate in the trial. > > If you wish to bypass the OT opt-in mechanism for local testing, you can > enable the --partitioned-cookies-bypass-origin-trial flag in addition to > the --partitioned-cookies flag. This configuration will allow partitioned > cookies from any site regardless of their origin trial status. > > All of this is documented in more detail on > https://chromium.org/updates/chips. > > Best, > Dylan > > On Thu, Mar 31, 2022 at 4:41 PM Marcelo Portugal <[email protected]> > wrote: > >> Hi, >> >> So I updated Chrome today to version 100.0.4896.60, and now, even when I >> turn on the partitioned cookie flag, my cookie is not populating the >> partitionKey as expected. Furthermore, when I was previously playing with >> it earlier this week on version ~99, although I could see the partition key >> and behavior working, the partitioned cookies would be blocked once I >> changed my settings to block third party cookies. So I am unsure on whether >> I am doing something wrong or if there is a defect with partitioned cookies >> right now. I was trying with the following url: >> https://dim-connect.herokuapp.com/tile >> >> Any help would be appreciated. >> >> Regards, >> >> Marcelo >> >> On Wednesday, February 2, 2022 at 12:07:55 PM UTC-5 Daniel Bratell wrote: >> >>> Thanks for your answers. I hope it works out fine. (You already have >>> Chris' LGTM so your experiment is ready to go) >>> >>> /Daniel >>> On 2022-02-02 17:37, Dylan Cutler wrote: >>> >>> Will this be run as a third-party Origin Trial? As a Finch experiment? >>>> Other? >>>> >>> This experiment will be run as a 3P Origin Trial, >>> >>> So, when the experiment finishes, sites that opted-in to that mode will >>>> lose their cookies and their users will e.g. be logged out, etc? >>>> That seems like a deterrent. Is there a way around that? (e.g. migrate >>>> the cookies to the default 3P behavior when the experiment is done. Not >>>> sure how feasible that is..) >>> >>> The reasoning behind why we didn't do that is that partitioned cookies >>> allow the existence of multiple cookies with the same host key, name, and >>> path to exist in separate partitions. Rather than coalescing these into one >>> cookie (which one is the right one to keep, after all?), we decided to just >>> remove partitioned cookies from clients' machines when the feature is >>> disabled to provide deterministic behavior. >>> >>> The long term plan is to get rid of "tracking" cookies, or more >>>> specifically third party cookies shared between multiple first parties. >>> >>> Correct >>> <https://blog.google/products/chrome/updated-timeline-privacy-sandbox-milestones/> >>> . >>> >>> This will not change anything unless a site explicitly asks for their >>>> cookies to stop tracking people. >>> >>> In the short term, yes, clients with partitioned cookies enabled will >>> support both partitioned and unpartitioned cross-site cookies. Once 3PCs >>> are removed (see link above) then only partitioned cookies will be allowed >>> in cross-party contexts. >>> >>> Eventually the default might change to "Partioned" and another flag will >>>> have to be used to keep tracking users cross sites... In step 4 I assume >>>> "Partitioned" becomes a no-op since that is the only available stage? >>> >>> I imagine when we first turn off 3PC that third parties will still need >>> to explicitly opt into using partitioned state using the >>> Partitioned attribute. If third parties do not opt into this behavior then >>> they will be unable to use cookies at all. But, in the long term, we may >>> have the Partitioned behavior be the default for cross-site cookies. In >>> that case, the Partitioned attribute could just be ignored and eventually >>> deprecated. >>> >>> >>>> If that is right, should this prepare the syntax to allow for step 3, >>>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of >>>> just >>>> partitioned? >>>> >>> I don't think we need the Partitioned attribute to have any other >>> semantic meaning other than a flag saying "I am opting into receiving >>> partitioned 3P state", so we decided to design it like the Secure and >>> HttpOnly attributes (i.e. its presence in the cookie line being "true", >>> it's absence being "false"). >>> >>> Do you have partners ready to start testing this? >>>> >>> Yes, there are a couple partners I know offhand who are interested in >>> testing this. >>> >>> On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell <[email protected]> wrote: >>> >>>> Can you verify that I am getting this right. >>>> >>>> 1. The long term plan is to get rid of "tracking" cookies, or more >>>> specifically third party cookies shared between multiple first parties. >>>> >>>> 2. This will not change anything unless a site explicitly asks for >>>> their cookies to stop tracking people. >>>> >>>> 3. (outside this experiment) Eventually the default might change to >>>> "Partioned" and another flag will have to be used to keep tracking users >>>> cross sites. >>>> >>>> 4. (outside this experiment) Finally tracking cookies are disabled >>>> completely (similar to what Safari has done). >>>> >>>> If that is right, should this prepare the syntax to allow for step 3, >>>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of >>>> just >>>> partitioned? >>>> >>>> In step 4 I assume "Partitioned" becomes a no-op since that is the only >>>> available stage? >>>> >>>> Another question: Do you have partners ready to start testing this? >>>> >>>> /Daniel >>>> On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote: >>>> >>>> Contact emails >>>> >>>> [email protected], [email protected] >>>> >>>> Spec >>>> >>>> https://github.com/WICG/CHIPS >>>> >>>> Summary >>>> >>>> Given that Chrome plans on obsoleting 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 (or First-Party >>>> Set, where the site uses that feature) to meet use cases that are not >>>> cross-site tracking related (e.g. SaaS embeds, headless CMS, sandbox >>>> domains, etc.). In order to do so, we introduce a mechanism to opt-in to >>>> having their third-party cookies partitioned by top-level site using a new >>>> cookie attribute, Partitioned. >>>> >>>> Link to “Intent to Prototype” blink-dev discussion >>>> >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo >>>> >>>> Goals for experimentation >>>> >>>> CHIPS is a new, opt-in technology meant to preserve a set of use cases >>>> (e.g. third-party embeds) that may break once third-party cookies are >>>> phased out while preventing cross-site tracking. We need to validate >>>> whether the proposed syntax and semantics solve these use cases prior to >>>> third-party cookie obsoletion by giving developers a way to test it in a >>>> scaled manner and provide early feedback. We hope to validate ergonomics, >>>> deployability, and backward compatibility. >>>> >>>> Experimental timeline >>>> >>>> The experiment will start in M100 and run from March 31st, 2022 until >>>> June 30, 2022. >>>> >>>> Any risks when the experiment finishes? >>>> >>>> Since Chrome will not send and may delete partitioned cookies when it >>>> is started with the feature disabled, sites that set cookies with the >>>> Partitioned attribute during the experiment will no longer have those >>>> cookies available on clients' machines. >>>> >>>> Reason this experiment is being extended >>>> >>>> N/A >>>> >>>> Ongoing technical constraints >>>> >>>> None. >>>> >>>> Debuggability >>>> >>>> We have coordinated with the DevTools team to surface cookie partition >>>> keys to developers in DevTools. We have added a new cookie inclusion >>>> reason >>>> with a debug string when sites set Partitioned cookies incorrectly. We may >>>> also support surfacing partitioned cookies that are not included in >>>> requests because their partition key did not match the top-level site in >>>> DevTools. >>>> >>>> Will this feature be supported on all five Blink platforms supported by >>>> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)? >>>> >>>> Yes. >>>> >>>> Link to entry on the feature dashboard <https://www.chromestatus.com/> >>>> >>>> https://www.chromestatus.com/feature/5179189105786880 >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6df254c-0b32-4ad2-b0a3-b6413d30cb91n%40chromium.org.
