Google delays third-party cookie demise yet again
41–50 of 112 posts
Re: Google delays third-party cookie demise yet again
#42Earlier quoted context omitted.
But isn't that a direct by-product of Chrome being owned by Google. If Chrome was made by an independent company regulators couldn't care less if they disabled third party cookies.
We honestly can't know whether the regulators would care, or whether they would be making different decisions. But that counterfactual seems totally irrelevant to the claims the GP was making?
Re: Google delays third-party cookie demise yet again
#43Dear CMA, Can you please let Google do the right thing and disable third party cookies like every other browser vendor.
Dear Internet user, third party cookies are also used be embedded web applications in services such as salesforce. Cookies are not only used for tracking, but also as an example, secure session allowing the bank to secure your login and also the person on the phone when call in helping you via their login. There are decades worth of applications created that likely will not be fixed…
I have 3rd party cookies as well as all ads and trackers blocked and have no major issues. On the odd occasion a site doesn't work, it doesn't get my business/attention. Non-technical people should be afforded the same protections.
Re: Google delays third-party cookie demise yet again
#44Re: Google delays third-party cookie demise yet again
#45https://privacysandbox.com talks about advertising, but not "logged in elsewhere" functionality. Does Youtube or Google have something ready, or will all Youtube Premium subscribers see ads on embedded videos?
Re: Google delays third-party cookie demise yet again
#46Earlier quoted context omitted.
It is annoying, but Firefox asks if you want to allow to use the 3rd party cookies for specific domain. Example of how it looks: https://hacks.mozilla.org/files/2021/02/Screenshot-2021-02-0...
In the example, the 3rd party is a sub-domain name. Are sub-domains treated the same as unqualified, "second level" domain names? https://en.m.wikipedia.org/wiki/Domain_name
So for example:
a.foo.com sets cookie X (Set-Cookie: X=value;)
a.foo.com sets a cookie Y on foo.com (Set-Cookie: Y=value; domain=foo.com)
b.foo.com can read Y, but can not read X
Re: Google delays third-party cookie demise yet again
#47Earlier quoted context omitted.
That seems a bit too conspiracy theorist, especially considering most people have 3rd party cookies on and teams has been around for a long time now (I assume before Google announced removing 3rd party cookies) I think the answer is more banal in that some of their oauth flow runs in a different domain from the main application. I think this is tied to wanting to reuse part of oauth flow in the desktop application.
The auth flow for Teams has always been very buggy so that is a good guess.
Re: Google delays third-party cookie demise yet again
#48It would be good to stabilize and have widespread support for CHIPS before disable 3rd party cookies entirely, there are use cases beyond advertising for these. https://developer.mozilla.org/en-US/docs/Web/Privacy/Privacy...
What are the use cases beyond tracking that make the tradeoff worth having 3rd party cookies?
Re: Google delays third-party cookie demise yet again
#49Why don't they just unilaterally disable third-party cookies by default without providing any replacement? The only slightly valuable functionality that would be lost would be authentication in comment widgets like Disqus. Ah, right, the makers of the world's most popular web browser are also the world's most profitable online advertising company, that's why.
It's explained in the article, and below in this thread. They legally cannot due to intervention from the CMA.
Re: Google delays third-party cookie demise yet again
#50Earlier quoted context omitted.
That seems a bit too conspiracy theorist, especially considering most people have 3rd party cookies on and teams has been around for a long time now (I assume before Google announced removing 3rd party cookies) I think the answer is more banal in that some of their oauth flow runs in a different domain from the main application. I think this is tied to wanting to reuse part of oauth flow in the desktop application.
The auth flow for Teams has always been very buggy so that is a good guess.