Re: [w3ctag/design-reviews] Cookies Having Independent Partitioned State (CHIPS) (#654)

Thanks for a bunch of people chiming in from Google so quickly. 

1) As mentioned, yes this is a side channel. It may use "existing side channels" - but this is Google saying, "we aren't getting rid of 3rd party cookies, we are actually going to evolve them, but going to not mention the evolution or the overall 3rd party cookie deprecation when explaining this new proposal)." 

1a) Please explain in these types of proposals HOW they relate to other proposals. This should be communicated as, "The CMA told us we needed to evolve 3rd party cookie deprecations, so we looked at what FireFox is doing for half-measures, and are modeling that. We still intend to keep the 3rd party deprecation timetable that we've discussed, and when the privacy sandbox is deployed, these techniques will no longer work - we are proposing an interim measure that would provide new/slightly safer tracking methods for 18-24 months, and assuming that FireFox stops their practice, Google may follow that. But for now, the company Google is paying billions to default Google search for, is acting like a policy blocker for one of our worst data sharing proposals in 2021 that conflicts with other privacy sandbox messaging." 

2) A double key cookie does NOTHING if that cookie is accessible to an entity via Javascript, because they can read the cookie, and then fire off a request with that value back to the 1st party or other new 3rd party partners. If CNAME mapping protections aren't deployed with this, and other JS restrictions for the value stored in a double-keyed cookie, then it might as well be a single  key -- this doesn't stop the partner who controls the key from sharing that value with new partners. In fact, the specs @ https://github.com/WICG/CHIPS#partitioning-model literally mention First Party Data sets, which is a CNAME-tracking-loophole, the middle ground to make it slightly safer, but not a solution at internet-scale at all.

2a) It's 2021 and Google and other browsers are still pretending like "Corporate Entity Lists associated to which browsers they own is a safe practice for building internet policies" -- first party lists and efforts to give special data sharing access to major corporations who own dozens/hundreds of domains, proves that Google is favoring itself and companies exactly like itself. 

3) I hope regulators are watching how these proposals are shared in a a place like github, with tons of details missing, when the folks at the CMA and other regulatory bodies have asked for Google to be extremely clear about these proposals, the timelines, what each if shifting, and also requiring that these proposals be viewed through the lens of other public promises from Google about efforts to stop tracking. 

3a) These types of proposals are market manipulation, and when this proposal "Gets press" - a bunch of "Open Internet" stocks will jump up at the news that Google is looking at half-measures all of a sudden, and not only has shifted from the timetable for full 3rd party cookie deprecation, but ya'll are now looking at policies that FireFox deployed, largely because it's a far weaker data protection policy than full 3rd party cookie blocking. 

4) Looks like data privacy activists need to start focusing their attention on Firefox and the "half measures" that have been deployed there, which are now being used as policy blockers for Google to deploy similarly less safe half measures. 

I'll let other folks ask questions and dig into this -- Google should stop putting huge policy shifts like this behind "proposals" and put them on the corporate google.com blog pages. It's clear this "3rd party cookie deprecation half measure" will be deployed, ya'll aren't asking for feedback or going through any standards reviews that could keep this from being deployed, and as mentioned, stocks are going to jump from this news, and many folks at Google and working at Google Ventures would know about these shifts and how they would impact competitor stock prices. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/654#issuecomment-872477676