Intelligent Tracking Prevention
webkit.org
webkit.org
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).
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.
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.
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.
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.
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.
> From the very beginning, we’ve defaulted to blocking third-party cookies
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
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.
As with many things in ML and NN, the premise of the tech is that it won't be a 100% perfect solution, but it'll hopefully be good enough or better than what you have.
... for now. It's just a matter of time before analytics and tracking will move. Just like maps has moved to google.com in order for search to also get access to the current location (which is a permission I'd gladly give to maps, but not to the search engine)
Probably not an issue for most of the users, but for those who don't use it very often, they'd get logged out. Not sure Google wants that.
As such, if a company with a non-add business attaches a tracking business to their existing domains, they can circumvent the deletion policies.
On a side note though, it seems Apple is doubling down on making decisions for its users. This is one example, another is do not disturb when driving. These sort of features make a lot of assumption and use complex logic to decide for users, even when the users don’t need that. I think that’s concerning.
All of the reports I'm reading say DNDWD is opt-in.
But I agree it is a concerning trend. The situation is analogous to government-mandated morals. While I might be expected to welcome legislation that enforces my beliefs on the rest of the population, I personally would prefer that the government stayed completely out of making these decisions at all, because it's only a matter of time before they make a decision that does not match my beliefs.
Right now isn't it a cat and mouse game of holding many domains/subdomains, and passing the cookie flag across them. It seems technically possible to cancel out the protections of ITP. However, deciding cookies can never be used outside of 3rd party context may mean I have to make some additional logins to services from time to time, but have much better tracking protection.
Is my assessment faulty?
It's been the long-standing default of Safari to block 3rd-party cookies. As is described in the excellent post this links to, there is some functionality that 3rd-party cookies enable that can be beneficial. They use single-sign-on as an example.
But social network widgets (Like buttons, comment form) would break without third-party cookies.
OAuth is typically a user-initiated action, like "Sign in with GitHub" or "Sign in with your domain" (https://indieweb.org/IndieAuthProtocol).
Though I think SSO should be possible with OAuth — maybe with a hidden iframe that does the auth process, or something with CORS requests… Or maybe a custom redirect-based protocol would be better.
Some of the things that would break without third-party cookies are social network widgets - you would be unable to like some post or add a comment using Facebook login on a third-party site.
Is this really the intended outcome?
(It's nice to see Brave have an effect, though.)
Maybe don't pay for clicks, only pay for sales.
I suspect few users would object to a single web property remembering them across multiple visits.
Of course bots can simulate visiting different websites and even logging into them if that is profitable.
To me it looks more like Overengineered Tracking Prevention to be able to shovel in 'Machine Learning Classifier' for buzzword compliance.
Besides, there is some value in getting widespread blocking. When you're the only one who blocks, that's a signal. When Apple's new doodah blocks mostly-the-right-thing for 10% of the users, that's quite different. You get to be part of a crowd.
Invalidation is hard. Once you accept you have to tread down the road of accepting and deleting cookies and local storage I see no reason to wait 30 days. Why not purge them right on (tab)closing?. If you really care about privacy that is. Which could have been set to be default on the next update btw.
HN has no such partners, of course. But many other sites do, and correlate cookies in order to tie devices together.
So what's the difference? Not everyone has enough time to waste to manually manage exceptions. So they're trying to make it smarter. If it works 90% of the time, it's still a big win, and you can still handle the remaining 10% yourself.
I am very happy to hear this "classification" happens on-device. I am curious how opaque it is. I assume, like the rest of WebKit the classifier is open source? In Safari, both desktop and mobile, is there a way to see which domains/cookies are blocked/purged or what the time remaining on them is (assuming I don't revisit the page)?
Also, I assume this can easily be beaten be smart ad networks. "Hey, publisher, just use our JS snippet which loads your first-party cookie we may have set previously and then loads a JS URL with that identifier as a query param in the URL along with other fingerprinting info, and we may set that first-party cookie after load too."
I would personally love the option to not send any third party cookies not on the same domain as the frame (or maybe an opt-in) on a per-site basis as I can only see it breaking social logins and other lazily-dev'd items like comment board integration (most SSO uses redirects anyways). Surely if a website wanted to offer its own domain's cookie store, it could (just like you can with local storage).
This kind of contract can do in both ways. The user can set up a permission set to give to the website. If the website balks then the user can go somewhere else or negotiate with their own principles how much they want to be "the product."
What's preventing ad networks (or whoever this is meant to protect against) from gaming this system?
I would like to see a clearer comparison as well.
and static block lists https://www.eff.org/files/cookieblocklist_new.txt
I really want Safari to have easy integration points to make a good cookie whitelist interaction using plugins.
Sure it's painful the first few days having to gradually build up that list, but like little snitch, once you're passed that stage, you just set it to say no to any new domains setting cookies.
Then users could cooperate to build cookie whitelists...
Only when scripting is enabled.
Hopefully the new EU law coming into effect next year will allow website visitor to sue the website owner for tracking him with google analytics without express consent and not allowing to opt out.
Why I say that? 1. No retargeting adv. 2. No site-to-site tracking 3. Less chances of identifying you uniquely.