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 <brat...@gmail.com> 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
>>
>> dylan...@google.com, kaust...@google.com 
>>
>> 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 blink-dev+...@chromium.org.
>> 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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45ad1d72-56e0-422f-9e94-ef58b5dbefb1n%40chromium.org.

Reply via email to