Any time any user hits any page with your javascript[1] in it: record ip address, referer (sic), locale preferences, available fonts, what's in their cache, what extensions they have, and anything else you can get. You can even track if they have certain 3rd party sites blocked.
Then it is a matter of bayesian guessing about who they are. Given that a typical person spends most of their time in only a few specific places (home, commute, work, favorite coffee shop/pub, etc) you can make very good guesses about which person is visiting your page after only a few visits... even if they have cookies disabled.
[1]And if they have js disabled they can't really use your site because js is basically required now. And you can still track that information and advertise to that cohort. How many people hitting the site from these 5 ip addresses, who use chromium, and have no cookies, and have js turned off? One? Well, then they just identified that person
You probably use sites that rely on 3rd-party cookies for single sign-on, too. Stack Overflow, for instance:
https://nickcraver.com/blog/2017/05/22/https-on-stack-overfl...
When you control the full stack on all of your sites it's less of an issue but when you're using multiple vendors SAAS solutions with custom authentication it can be a huge pain.
IMO the Webkit team would make developers' lives much easier if you more clearly articulated that intent; otherwise they have to guess the direction your team is heading and might build something in the short term that ends up breaking.
It is the most sensible and useful policy I have ever seen. Sadly, it can't be done as an extension in the new Firefox model.
The only thing it can't do yet is delete local storage due to the API not being implemented.
Yes, ML isn't magic, but that's irrelevant to the parent's point: the issue is that websites a stable "browser API" to work against so they can know what the user will send back where and when.
If the user is selectively setting cookies based on the results of machine-learning some non-obvious then it becomes that much harder to debug "why didn't this part of the site remember who they were?"
Sites will break without warning for users until some engineer discovers that some ML model told the browser to only set cookies for a particular set of sites determined by IP, domain, "trustworthiness", and a few other factors engineers don't want to think about when designing the app.
If you're saying that you can publish the model openly with the expectation that sites will know you're using it, that's fine, and that's a valid approach, but that has nothing to do with ML per se, and is just another attempt at rearchitecting the browser/server interface with all of its associated issues, and continues the same arms race between sites that want to de-anonymize you.
In short: there's a tradeoff between "hiding information about yourself" and "providing a stable set of expectations for web sites to build off of"; ML can favor one of those objectives but not eliminate the tradeoff and somehow get the best of both worlds. The only way to get the best of both worlds is to rearchitect the API by which browser clients talk to webservers so that it's easy to separate out what you do want/need to tell the server vs what you don't.
> From the very beginning, we’ve defaulted to blocking third-party cookies
For example, opening a site and receiving cookies with it: doesn't work any longer. Receiving cookies after submitting a POST request: keeps working.
This also means that on load the first thing that will happen is an AJAX POST in the background, or the moment you press the mouse on anything on the page in case that gets further restricted.
Obviously shopping sites and similar get whitelisted.
Edit: I just saw your comment in the sibling thread. Guess I won't be interacting with your sites any time soon.
(brb updating my bots and scrapers to use cookies)
Moreover, a browser can easily differentiate an AJAX POST from a user submitting a form.
And I'm not talking about changing anything. On most of my websites if you do a POST without having a session id (which gets assigned on first pageload, a GET), then you are a bot and your POST will be blocked. Byebye. There are many such schemes out there.
Maybe you are thinking about displaying the logged in state for things like Like Buttons or other social widgets that you'd be signed into such as Disqus or Facebook comments?
(This is why some browsers have a setting like "third party cookies after visited in a first party context" - first party for login, third party for logout. But advertisers screwed this up by asking sites to do full frame redirects through them. )
No it isn't.
OAuth2 doesn't specify cookies in the entire spec and definitely doesn't require third party cookies, especially for logout.
Here's the RFC: https://tools.ietf.org/html/rfc6749
Spec: http://openid.net/specs/openid-connect-frontchannel-1_0.htm
Edit: I should say, this spec also doesn't require cookies - you can use HTML5 local storage or another mechanism. In practice however, if you log into a Google service like YouTube, or a Microsoft service like Outlook, or a Facebook third party like Spotify, they use cookies.
Why don't just block third party cookies except where it is enable by the user? I think 100% of the sites I visit use third-party cookies only for tracking.
And of course this is not enough. Using a combination of an IP address and browser fingerprint allows tracking a user without any cookies.
And websites can still track users if they use a redirect through an analytics website (when a user visits a site for the first time he is redirected to an analytics domain, that redirects the user back adding an identifier to URL).