4 ms·

Intelligent Tracking Prevention 2.1

106 points by alwillis 8y ago

Despegar 8y ago
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-sdks/ https://blog.appfigures.com/shazam-for-ios-sheds-3rd-party-s...
orf 8y ago
This has broken password reset links that Django sends[1]. 1. https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer https://groups.google.com/d/msgid/django-developers/20d7a1d1...
- Nextgrid 8y ago
  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.
  - orf 8y ago
    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.
dillondoyle 8y ago
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.
czr 8y ago
> 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.
KajMagnus 8y ago
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")
- nyuszika7h 8y ago
  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.
  - KajMagnus 8y ago
    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?
c4dna 8y ago
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.

106 points by alwillis 8y ago

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-sdks/ https://blog.appfigures.com/shazam-for-ios-sheds-3rd-party-s...

orf 8y ago

This has broken password reset links that Django sends[1]. 1. https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer https://groups.google.com/d/msgid/django-developers/20d7a1d1...

Nextgrid 8y ago
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.
- orf 8y ago
  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.

dillondoyle 8y ago

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.

czr 8y ago

> 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.

KajMagnus 8y ago

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")

nyuszika7h 8y ago
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.
- KajMagnus 8y ago
  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?

c4dna 8y ago

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.