
WebKit Tracking Prevention Policy - feross
https://webkit.org/blog/9507/announcing-the-webkit-tracking-prevention-policy/
======
Vinnl
One advantage of Google's dominance and their business model being so reliant
on tracking, is that it's become the moat for its competitors: investing
energy into tracking protection is a good way for them to gain a competitive
advantage over Google, since it's a feature that Google will not be able to
copy.

So as long as Google's competitors remain in business, we'll probably at least
have some alternatives that take privacy seriously.

~~~
inapis
That's a very interesting point. But tracking-free services won't really have
a major mindshare with the general public because you really can't compete
with "free."

And there's nothing preventing Google from leveraging Youtube/Gmail/Search to
push out other browsers which have tracking protection. Youtube already plays
less well with Firefox. Gmail isn't exactly snappy on Safari either.

~~~
Vinnl
Yes, competing with Google is still a main challenge. Still, Apple seems to be
managing by providing the browser for free as a value-add when you buy their
hardware, and by preventing other browser engines from running on iOS.

Mozilla's financial dependence on Google is still a major challenge, which
they'll hopefully be able to fix before push comes to shove.

Microsoft unfortunately did not seem to be able to financially justify the
maintenance of their own engine - though then again, their bet appears to be
on Windows integration rather than tracking protection.

~~~
galangalalgol
When MS prevented other browsers from working well in Windows it was slapped
with antitrust. Why is it ok when Apple does it? Is it because macos and ios
don't have the same level of os monopoly that MS had back then?

~~~
Vinnl
I'm not saying it's OK when Apple does it; in fact, I've heavily criticised
that in the past. I do think, however, that plays a role in Apple's ability to
keep WebKit relevant, so it does have positive side-effects.

------
saagarjha
Actual link to the policy: [https://webkit.org/tracking-prevention-
policy/](https://webkit.org/tracking-prevention-policy/). One thing that I
found interesting was these two quotes:

> Our current anti-tracking mitigations in WebKit are applied universally to
> all websites, or based on algorithmic, on-device classification.

> If a party attempts to circumvent our tracking prevention methods, we may
> add additional restrictions without prior notice. These restrictions may
> apply universally; to algorithmically classified targets; or to specific
> parties engaging in circumvention.

Is this trying to say that WebKit will now apply restrictions to specific
parties that the project feels is circumventing tracking prevention? I'm all
for these features, but only if they're applied evenly and in a clear way. The
solution to circumvention should be mitigations against bypasses, not
selective enforcement :/

~~~
om2
We're willing to do specifically targeted mitigations, but only if we have to.
So far, nearly everything we've done has been universal or algorithmic. The
one exception I know of was to delete tracking data that had already been
planted by known circumventers, at the same time as the mitigation to stop
anyone else from using that particular hole (HTTPS super cookies).

This is in contrast to Mozilla and Edge tracking protections, which are based
on block lists to a significant extent. The disconnect.me list is likely to be
trustworthy, but ultimately it is manually curated. We've tried to stay away
from using lists like that.

~~~
davedx
Thank you for doing this work. I don’t know what effect it has on Apple as a
whole but for customers like me it reinforces my loyalty to Apple.

~~~
auslander
Totally true. Thanks.

------
omeid2
It is worth reminding that Google Chrome and Chromium no longer use WebKit but
Blink.

[https://www.chromium.org/blink](https://www.chromium.org/blink)

~~~
winrid
Wow, thanks. Somehow I missed that. Things move so fast.

~~~
Fnoord
Google forked WebKit (itself a fork of KDE Konqueror's KHTML). Blink is from
2013. [1]

I wonder how source incompatible these are? Is it difficult to backport?
Because KHTML was LGPL the source must remain available. Or is it just that
these are API incompatible?

[https://en.m.wikipedia.org/wiki/Blink_(browser_engine)](https://en.m.wikipedia.org/wiki/Blink_\(browser_engine\))

~~~
jefftk
After the fork both WebKit and Blink were able to delete large amounts of no-
longer-shared code. Not half the codebase, but still quite a lot. The fork was
a recognition of their having been growing apart for a long time.

Both groups still watch each other's changes, but it's very rare that a patch
would apply cleanly.

~~~
om2
It is still possible to make changes that are mostly reusable for both, but it
takes some effort, and some parts (JS engine, multiprocess architecture) are
so different that you just have to write it twice.

------
po
_A first party is a website that a user is intentionally and knowingly
visiting, as displayed by the URL field of the browser, and the set of
resources on the web operated by the same organization. In practice, we
consider resources to belong to the same party if they are part of the same
registrable domain: a public suffix plus one additional label. Example:
site.example, www.site.example, and s.u.b.site.example are all the same party
since site.example is their shared registrable domain._

 _A third party is any party that does not fall within the definition of first
party above._

This policy doesn't distinguish between companies that own multiple top level
domains. I understand that it may be technically hard to figure out but at the
policy level are two domains owned by one company really third party to each
other?

Are example.com and example.us really always different first parties? What
about apple.com and iCloud.com? Or those redirect chains that happen after
logging into google such that login cookies are set on youtube.com and
whatnot?

It does say 'in practice' but I feel like this is mistaking a technical
limitation that it's hard to know if two TLD's are controlled by the same
legal entity for a policy.

~~~
om2
We have mixed feelings about this. Most people could probably figure out that
google.com and google.co.uk are owned by the same entity. And probably many
people are aware that youtube.com and google.com are related. But some
entities own hundreds of domain names with no clear lexical relationship. I
doubt a lot of people would expect TechCrunch.com and huffpost.com to be
related and would not really expect to be tracked between the two. So common
ownership might not be enough to give users a reasonable expectation of a
cross-site relationship.

~~~
tuxone
Also, a tracking service could just ask to be CNAMEd to a random subdomain and
become everybody’s “first party”, couldn’t it?

~~~
om2
It could, but access through these various CNAMEs would not give it stateful
cross-site tracking ability, since each would be a different Origin. It would
be providing a hosted first-party analytics/ads/whatever service within the
storage space of the first party.

~~~
randall
Additionally, people who own the sites can use them together via methods like
this, while third parties will have a more difficult time. Bravo.

------
p4bl0
Related to the way they classify between first party and third party (based on
domain names, with its subdomain being the same party), the Public Suffix list
[1] is a resource of great value. It allows to know when subdomains actually
refers to different parties (e.g., xxx.github.io is neither the same party as
yyy.github.io nor as github.io).

[1] [https://publicsuffix.org/](https://publicsuffix.org/)

~~~
quotemstr
The public suffix list is a gross hack. The public-ness of a particular domain
level ought to be returned as part of the DNS response instead of being looked
up out-of-band.

~~~
p4bl0
I understand your point, but the problem is that anybody can make their DNS
response say whatever they want. And you can't even rely on crypto signatures
(e.g. DNSSEC), as the people controlling some DNS records are not necessarily
the same as their users.

For example, GitHub controls DNS for *.github.io so if they wanted to track
people across all GitHub Pages, they could.

Also, the Public Suffix list isn't something that needs to be polled every
time. It is reasonable for browsers to cache it for several days even.

~~~
quotemstr
I don't think we'd in practice see people lying one way or the other about a
particular name level being "public". If GitHub wants to track people across
all *.github.io pages, it can, trivially. It controls the infrastructure,
after all.

~~~
jefftk
_> If GitHub wants to track people across all _.github.io pages, it can,
trivially. It controls the infrastructure, after all.*

If WebKit fully implements what they're describing here then GitHub should not
be able to use their control of *.github.io to track people across those
pages.

~~~
p4bl0
quotemstr was talking about the infrastructure that they control. It's true
that they can track visitors _server-side_ if they want to.

~~~
jefftk
With what WebKit describes here GitHub won't be able to tell the difference
between:

A: a browser visits both foo.github.io and bar.github.io

B: one browser visits foo.github.io, another visits bar.github.io

Both should look identical to github.io, client side and server side.

(This is not the case today, but my reading of the policy is that they
consider all the ways in which it is not the case to need fixing.)

~~~
p4bl0
What about the IP address and the other information that leaks at network
levels that are lower in the stack than what the browser controls?

~~~
jefftk
Many people are behind NATs and so share IPs. This can be millions of people;
see Wikipedia's documentation on IP banning:
[https://en.wikipedia.org/wiki/Wikipedia:Blocking_IP_addresse...](https://en.wikipedia.org/wiki/Wikipedia:Blocking_IP_addresses)

What are you thinking other than IPs? Everything else should be under the
browser's control.

~~~
p4bl0
I don't know. I just suppose that it's not that simple. It is never a good
idea to assume something is safe for good. The TTL of the packet could also be
used maybe?

Also, there are also many people that are not behind a NAT. I've always had a
public IP address at home, for example. Plus NAT may become less used because
_insert rant about NAT and IPv6_.

Anyway, it's good that browsers make all they can to ensure privacy :).

------
pspeter3
Would "Sign In With Apple" be considered a "Privileged Third Party" if they
make sure it works but break other Single Sign On providers as an "Unintended
Impact"?

~~~
eridius
I'm not sure what you mean by this; WebKit Tracking Prevention doesn't break
third-party login. Third-party login works by handing a token back to the
first party, who then stores it directly and validates it on the backend.
After the initial login with the third party, the third party isn't involved
anywhere that the browser can see. And the initial login happens in a browser
window that's navigated directly to the third party, making them the first
party for the login form (and therefore able to access any saved login data
from previous logins).

In fact, this WebKit Tracking Prevention Policy explicitly states that third-
party login is implied consent for the third party to identify the user as
having the same identity in these multiple places.

~~~
geofft
TBH a browser prevents Medium from showing a Google iframe in the top-right
corner with "Hi geofft, I know your name is geofft, please click the login
button geofft," that would be delightful....

~~~
saagarjha
I’m not quite sure about this, but I think Safari will prevent cross-site
tracking in this case until you interact with the thing.

------
akersten
Is there a specific list of the web features that are being restricted? I
couldn't find it in the document, and to me pretty much _any_ web feature
could be used for fingerprinting. It would be good to have a roadmap for
workarounds developers will need to implement to keep legitimate applications
working on Webkit.

~~~
om2
Parties that are motivated to do tracking on the web are very creative. Too
creative to list every feature they could use. That said, our goal is to as
much as possible remove tracking without removing capabilities for non-
tracking use cases.

~~~
akersten
I appreciate the efforts, and thanks for replying. My fears are mostly for
performant web apps (e.g. games, 60hz+ refresh) where timers are inexplicably
inaccurate on one web engine with no documentation explaining why. I hope the
restrictions are more subtle, and I understand the desire to keep them
somewhat secret this early on.

~~~
om2
The limitation on high precision timers isn't due to privacy, it's because of
the Spectre/Meltdown family of attacks. We'd like to lift those restrictions,
at least conditionally, and are looking into it. I appreciate the note about
your use case.

(BTW requestAnimationFrame should give you precise callbacks at the screen's
refresh rate, and is probably better than using timer-related APIs.)

~~~
akersten
Fundamentally Spectre is a privacy issue, just not in the tracking sense here,
right - it's a side channel by which memory can be leaked.

Anyway, the reason I brought up timers is that things like getting the
screen's refresh rate, or measuring how long a canvas render takes with a
particular font, (etc.) are all data points that can be used in a
fingerprinting profile. I worry about the negative impacts of mitigations
against those kind of measurements. I don't think it's possible to catalog all
the various routes by which data could be inferred by timing. If things like
this are in the scope of what Webkit is trying to prevent, I'm fairly nervous.

Off topic, but just for some game industry perspective: often we don't want to
sequence exactly at the refresh rate (especially if it's variable or frames
are being dropped) in contexts like logic loops or physics simulations that
need to happen at specific frequencies regardless of how quickly frames are
drawn. For example, synchronizing a client "tick rate" with a game server's
requires millisecond precision.

~~~
om2
Thanks for the info. For dual use technologies we are considering a machine
learning approach to identifying fingerprinters (as opposed to legit clients).
Also, to my knowledge, screen refresh rate is not currently a top
fingerprinting vector.

As for Spectre, we treat it primarily as a security threat. It can admittedly
be privacy invasive but it would be awkward to use it for tracking.

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

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

~~~
yyyk
"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...

~~~
the8472
They were broken in the sense that the preferred address would revert back to
the permanent address. IPv6 still worked.

~~~
yyyk
If the address reverts to the permanent address, than the IP can still be
useful for tracking, right?

~~~
the8472
Yes, that was the issue that was fixed.

------
millstone
Just want to say thanks. I use Safari by choice and feel good about it, and
this ongoing effort is part of the reason.

------
rale00
So what is going to happen when Apple succeeds in making it impossible to make
any money off advertisements shown to iOS users on the web?

I'm currently imagining a future where publishers start to just redirect iOS
traffic to install their app, where they can actually make money. Good news
for the walled garden, I guess?

~~~
downandout
I came here to say exactly this. Most profits for online ventures come from
retargeted ads, and most businesses lose money on cold audiences just so that
they can build retargeting audiences. As a result, when tracking dies, so does
most online ad spend.

I am really curious what the web itself (outside of apps) will look like in a
world where the quality of content and services implodes because of the
inability of publishers to generate revenue to pay for it. You may have your
privacy, but you may also not have much left to do on the web. This is
definitely a “be careful what you wish for” scenario.

~~~
kibwen
Not to suggest offense, but I wonder how old you are? I may not quite be a
greybeard just yet, but I remember being enraptured by the content on the
internet long before it was caught in the stranglehold of advertisers. Big-
budget affairs would be more scarce, but there would be no dearth of content.

~~~
downandout
I am old enough to have seen the Internet emerge. You were enraptured by
content and services provided by companies that lost billions of dollars,
courtesy of investors, during the dot com era. Those investors provided that
capital in large part because they knew how lucrative it could be if online
advertising became as efficient and effective as it is today. You will not see
that kind of subsidy in the post-ad world.

~~~
saagarjha
> You were enraptured by content and services provided by companies that lost
> billions of dollars, courtesy of investors, during the dot com era.

What about the independent blogs?

~~~
downandout
Of course anyone who wanted to spend their time back then doing what we now
call blogging, who wanted to pay for their own hosting, could have done so.
However, I am not sure that the ability to read the thoughts of independent
bloggers was a major driving force behind the mass adoption of the Internet.
It was quality content and services, subsidized by investors who for the most
part hoped companies could generate revenue from advertising, that drew the
public to the Internet.

~~~
wokwokwok
Yes, and the companies who are making products which are actually good own the
whole ecosystem, end to end, like google and Facebook, and will be almost
totally unaffected by this change or future changes.

It’s _everyone else_ who makes click bait ad spam that will suffer; and
frankly, why should we care?

Gmail isn’t going to disappear.

Kotaku or TechCrunch might... or maybe some of those spam cooking sites.
...but, seriously? The whole internet exist because of personalised tracking >
big marketing spend?

Come on.

You’re vastly overstating the case here: yes, there would be some impact, no
it wouldn’t really make a big difference at this point.

Maybe if you go back in time, it would, but you can’t, so it’s a mute point.

What’s important is where we want to go from here, and personalised ad
tracking driving content farms of fake cooking videos isn’t really the ideal
“endstate” for the internet imo.

...even if some spammy companies I don’t like end up going out of business,
along with some companies I do like.

------
zawerf
I am not caught up on browser engines, but WebKit is mostly just Safari and
iOS browsers right?

~~~
saagarjha
WebKit is also used in a number of other places, such as GNOME Web and
browsers for many consoles.

~~~
om2
Indeed, the Gtk+ and WPE ports, as well as Sony's Windows port, are the most
active after the Apple-maintained ones.

~~~
radicaldreamer
Sony's Windows Port?

~~~
password4321
Thanks to these comments today I am finally running WebKit on Windows for
preliminary Safari compatibility testing purposes.

This blog[1] explains how to get Windows builds[2] from the WebKit Build
Archives on S3 that require Apple Application Support[3].

[1] [https://medium.com/@alSkachkov/how-to-load-the-latest-
webkit...](https://medium.com/@alSkachkov/how-to-load-the-latest-webkit-on-
windows-962a9219c1e1)

[2]
[https://build.webkit.org/builders/Apple%20Win%2010%20Release...](https://build.webkit.org/builders/Apple%20Win%2010%20Release%20%28Build%29)

[3] 7-zip the iTunes installer to extract & install just
AppleApplicationSupport.msi
[https://www.apple.com/itunes/download/win64](https://www.apple.com/itunes/download/win64)

------
wyattjoh
I only with that with the advent of all these different anti-tracking
movements, that there was a clear, documented way for "good faith actors" that
require technology like localstorage.

We've worked really hard to implement a embedded experience via an iframe, but
it's becoming increasingly difficult for our software to walk on egg shells as
to not trigger it being labelled as a tracker (as it is definitely not, we
only utilize localstorage for storing authentication details). Combine that
with the fact that without using cookies, there isn't any way for us to
support AMP sites, which often incorrectly labels us as a third party tracker.

edit: I do realize that the WebKit Tracking Prevention Policy essentially is a
guide of how it works, I'm mostly interested in a "this is how to work within
these defined walls to not be flagged as harmful"

~~~
om2
Sounds like we need to expand WebKit's implementation of Storage Access API to
cover LocalStorage.

------
rpastuszak
The fact that this makes behavioural targeting even harder makes me very
happy.

What makes me even more happy is that this helps to eliminate the argument
stating that 3p cookies can be replaced with heuristics/non-deterministic
targeting. So, instead of assigning resources to just another way of targeting
users (e.g. hacks, fingerprinting) a developer/PM can already say that these
approaches will be prevented in the exact same way. Any further work in this
direction would be pointless.

Ideally, we'd put more focus on contextual targeting, which is arguably more
useful, significantly less creepy and less dubious from the ethical point of
view.

I just wish Microsoft moved in the same direction with IE. So far they've been
more quiet on that subject than Google. That's wishful thinking, I know.

------
awinter-py
does anyone have insight to the webkit governance side of this? is this a case
of apple fighting their ads battle against google in upstream FOSS?

~~~
panic
Google hasn't been involved with WebKit since they forked it to create Blink.

------
1986
Given the definition of cross-site tracking and the note on single-site
analytics in Unintended Impacts, is it safe to say this will impact all site
analytics tools served by a 3rd party (eg Google Analytics, but really almost
all "drop-in" frontend analytics)?

~~~
mobjack
Google analytics still works since it uses first party cookies but you lose
data on repeat vs new visits.

There are ways to make GA work around these limitations, but it requires more
work than just dropping it in.

------
auslander
That surveillance economy strongly reminds me Tobacco industry. It was cool
and trendy until everyone woke up and regulated it to death, as it should be.
GDPR is just the beginning.

------
DiseasedBadger
Good thing Qt ditched awful WebKit for glorious Chrome. Tracking is "mm mm!"
good. It also helps make sure Google's predatory non-compliance and Google-
board optimizations continue to spread through all websites.

#ThanksQt

------
ignoramous
Strange for a page espousing anti-tracking [0] to load media in from
apple.com. Granted Mozilla's page [1] is even a worse offender with google-
analytics and newrelic embeds.

Really makes you think what really drives the underlying narrative for such
initiatives at corporates if not sabotaging competitors? OpenDNS founder,
u/davidu, pointed out that DNS over HTTPS, something that takes aim at
trackers and advocates privacy, also, in fact, had support of BigAdTech [2].

The content blocker ecosystem has been fighting the dragnet for a long time
without expecting anything in return save for examples like Brave and Adblock.
It'd be a shame to see those subject to embrace, extend, extinguish.

> And we will create new web technologies to re-enable specific non-harmful
> practices without reintroducing tracking capabilities.

I wonder what this means. Another standard that AdTech can rally behind? Or,
Apple's way of wrestling control away from AdTech? Remember, not long ago
Apple disallowed 3p browsers for a long time, on AppStore...and they are
likely going to act as gate-keepers here, as well?

> we will typically prioritize user benefits over preserving current website
> practices. We believe that that is the role of a web browser, also known as
> the user agent.

Where have I heard that before? [3]

And now... what about apps on AppStore? When do we get anti-tracking measures
there? Pretty soon, would be really great, because that's a present and clear
danger, in my eyes, wrt privacy... but one that hurts Apple's bottomline?

[0] [https://webkit.org/tracking-prevention-
policy/](https://webkit.org/tracking-prevention-policy/)

[1]
[https://wiki.mozilla.org/Security/Anti_tracking_policy](https://wiki.mozilla.org/Security/Anti_tracking_policy)

[2]
[https://news.ycombinator.com/item?id=18257318](https://news.ycombinator.com/item?id=18257318)

[3]
[https://news.ycombinator.com/item?id=20542656](https://news.ycombinator.com/item?id=20542656)

~~~
Accacin
At least for your second point
[https://bugzilla.mozilla.org/show_bug.cgi?id=697436#c14](https://bugzilla.mozilla.org/show_bug.cgi?id=697436#c14)

~~~
ignoramous
Thanks.

------
anaisbetts
If this tweet is accurate, Apple's choices here are pretty hard to explain as
anything but "leverage / abuse mobile phone monopoly to kneecap competitors",
especially because nowhere in this document does it actually describe how this
makes users' lives better in any concrete, specific way

[https://mobile.twitter.com/Carnage4Life/status/1161779661644...](https://mobile.twitter.com/Carnage4Life/status/1161779661644300293)

~~~
eridius
> _Google Analytics_

Website analytics should not rely on cross-site tracking. Breaking any cross-
site tracking ability of GA is unambiguously good for users.

> _Google Ads conversion tracking_

Apple already proposed a mechanism of privacy-protecting click attribution. If
Google doesn't want to use that, it's because they don't respect your privacy.
Again, unambiguously good for users.

> _Using same login across different sites like Gmail & YouTube_

The only way this is "broken" that I can see is the user has to log in
separately to each site. Which seems fine to me. In fact, this is a good
thing; just because I log into Gmail with one account doesn't mean that's what
I want to use for YouTube.

~~~
1986
I don't disagree with your note on cross-site analytics (though there are some
in my mind valid use cases, such as tracking conversions when the payment
process occurs on a separate domain), but the tracking policy is fairly vague
as to the impact on single-site.

~~~
om2
Our goal is not to break single-site analytics, and if it gets affected as an
unintended consequence, we will try to come up with alternate solutions.

~~~
1986
Noted--thanks for the reply, both here and to my other comment.

