Hacker News new | ask | show | jobs
by jesstaa 2498 days ago
I expect that tracking will just move to being proxied server side. It will be more annoying for the people setting it up but services will spring up to help. Little will change in the advertising and tracking space.
3 comments

It's actually pretty hard to do this. You still need some way to consistently identify the same user across different sites. Stateful tracking, fingerprinting, and link decoration are the only ways we know of to do this and we have our sights set on all of them.
Isn’t link decoration an intractable problem? Ban query params and people switch to matrix params. Ban that and they subtly include it in the seo friendly text, band that and…

It just seems somewhat wrong that a browser with a huge market share doesn’t use any standards / rfc process and invents new ways of blocking tracking / breaking agreed upon specifications from release to release in isolation.

We have a partial mitigation and it does not involve stripping query params.

We'll be doing more stuff in standards first / in parallel now that more browsers are actively engaged in reducing tracking.

A lot of the more extreme thing we'll only do for sites that we've classified as a tracker. Other browsers put identified trackers in all kinds of penalty boxes that aren't fully defined by standards yet. (We happen to do the identification using machine learning instead of a curated block list.)

I guess this is what the article’s main point — putting sites on notice that no matter how much they obfuscate their cross-site linking practices, WebKit can always hard code mitigation’s for that site.

If social.example links to blog.example, limit cookie storage to 24 hours, no matter what is in the link.

That annoyance may be enough to keep many actors from just plugging 10 random trackers into their sites, especially when it means running code from less-than-trust-worthy parties on their own servers instead of their user machines.

At the very minimum it aligns incentives better for developers to think about these things.

And with IPv6 privacy extensions IP addresses will also be less useful for server-side tracking.

> especially when it means running code from less-than-trust-worthy parties on their own servers instead of their user machines.

But most will be OK with their servers running Google, Amazon, Oracle BlueKai and Facebook code, the scariest ones by amount of data.

"IPv6 privacy extensions...."

I recall these extensions are just optional. How many implementations actually implement these extensions? I recall Windows 10 had this broken for a year and almost nobody noticed...

They were broken in the sense that the preferred address would revert back to the permanent address. IPv6 still worked.
If the address reverts to the permanent address, than the IP can still be useful for tracking, right?
Yes, that was the issue that was fixed.
They didn't have to run the code, e.g. example.com just has to run a proxy that accepts payloads at analytics.example.com and forwards them to the third party tracking providers.
Could you elaborate on how "tracking will just move to being proxied server side" works vs what we have today? I'm genuinely curious what those services will entail. Thanks.