Intelligent Tracking Prevention 2.1 | Hacker News Reader

Intelligent Tracking Prevention 2.1

webkit.org

106 pointsalwillis10 comments

> Safari removed support for DNT so that users are not presented with a misleading and ineffective privacy control that, if anything, only offered additional browser fingerprinting entropy

Predictable, but still a bit depressing to read.

My appreciation to the WebKit team for working so diligently on behalf of their users.

ITP is great for protecting privacy on the web but doesn't do anything for native apps. Apple needs to crack down on third party frameworks that developers are distributing in their apps. I hope this is a sign of an upcoming policy change.

https://blog.appfigures.com/shazam-for-ios-sheds-3rd-party-s...

I'm wondering if anyone has real world experience implementing or moving from document.cookie to http only cookies? Or any stats on lost cookie coverage for iOS devices?

We're currently about to push an update to our system that uses a http only cookie on the shared 'action' domain and writes non-sensitive JWT to client domains for pre-fill and sending action data to CRM/ESP with document.cookie

Now, I am leaning towards rethinking the client side and potentially just move everything to hosted subdomains so we can set http only JWT on client domains - would echo out a JS var with the user so JS can still access instead of document.cookie. Critically this JWT contains not login / donation / sensitive info I assume it's publicly accessible even though we dont have 3rd party JS outside of GA on these domains.

I guess could just keep current setup with identity http only cookie on separate domain and just return JWT in a JSONP/cors request only send it back for 'verified' domains. But that seems hacky and adds http trips (and critically for pre-fill etc want it to be instant not flickered), though would be a lot easier than managing a bunch of subdomain cname stuff.

This has broken password reset links that Django sends[1].

1. https://groups.google.com/d/msgid/django-developers/20d7a1d1...

This breaks when the password reset link is passed through click-tracking services. Seems like a good thing - you shouldn’t be leaking password reset links (which are almost equivalent to passwords themselves) to email stalking providers.

After clicking a password reset link Django performs a redirect to a change password form. The initial link tracking redirect still occurs, it's the second (domain-internal) redirect that is the issue.

What will be the ads & tracking companies' next step? Maybe they'll want to serve tracking cookies as Secure and HttpOnly, as if they were login cookies? o.O (to prevent the tracking cookies from getting deleted after 7 days: "Client-Side Cookies Capped to 7 Days of Storage")

It's not that simple if I understood correctly. The trackers can only set first-party cookies on other websites via JavaScript, and cookies set via JS cannot be HttpOnly.

What I had in mind, is that the ads & tracking companies, would want to integrate/add some of their code server side, to be able to set HttpOnly cookies. Crazy next step?

Too many cookies per site makes for a fat browser cache. Sites issuing cookies have no incentive to clean up the ones that they no longer use. It does make sense to consolidate into a single set per site, and tech allows that without losing anything.

Reply on news.ycombinator.com