
Intelligent Tracking Prevention 2.1 - alwillis
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
======
czr
> 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.

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

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

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

1\. [https://groups.google.com/d/msgid/django-
developers/20d7a1d1...](https://groups.google.com/d/msgid/django-
developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer)

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

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

