Profile picture
Ted
, 40 tweets, 11 min read Read on Twitter
The first talk is @johnwilander, a @webkit engineer at @Apple who will talk about privacy by default on the web. #usesec19
@johnwilander @webkit @Apple This talk will go through specific privacy issues. Agenda:
- Cross-site tracking
- How we are preventing it in Safari
- The way forward for the web platform
@johnwilander @webkit @Apple 60-70% of your browsing history is outside your control, and can be reconstructed using tracker data. It can be manipulated and handed over by anyone.

A visual consequence of ad is retargeted ads: ads that follow you around the web after you've shown interest in a product.
@johnwilander @webkit @Apple Another consequence of cross-side tracking is malicious micro-targeting; which allows the bad guys to target specific vulnerable sub-parts of the population with malware or propaganda.

"Cross-side tracking is bad for people."
@johnwilander @webkit @Apple He reads a quote by a tech journalist, sitting next to an ad executive. The executive told him that he would gladly put ads on his website, but only for a small amount of time, to put cookies on readers' devices. He can then target them on cheaper websites.
So the argument is that cross-site tracking actually creates value *loss* for good publishers.

This is also the origin for clickbait, and fake news — it doesn't matter if you enjoy good content, all that matters is that you click on the website so ads can put a cookie.
So in summary, cross-site tracking is bad for the web.

What to do about it? Let's consider imaginary browser security settings.
Security settings could be things like "suggest strong passwords", "highlight the registrable domain", "use same-origin policy", "modern cipher suites"… OK, no that doesn't make sense. You don't want to ask the user that. You want them one by default!
Safari's cross-site tracking works this way: privacy is on by default.

(This presentation is so slick, omg — living up to the Apple standard right there :D)
Timeline for privacy default:
- 2003 started third-party cookie blocking: drop them if the cookie doesn't exist already. However, it doesn't prevent them from being first-party for a short period of time to see the cookie jar.
- 2013: partitioned storage and cache, to avoid cookie equivalents. This also wasn't enough.
- 2017: intelligent tracking prevention deletes tracking cookies by default
The goals of ITP:
- prevent the cross-site tracking we see today
- don't block ads: this is on by default, we don't want to make that decision
- don't use a blocklist, it'd be a management nightmare
- don't break the web and create a bad user experience
That means we need cross-site trackers on-device, and maybe delete cookies on device.

How does classification work? With statistics: count how many third-party scripts you see, how many redirections (ads), and subframes.
An initial stage of data collection (curating all domain names by hand and counting stats on them) showed that these categories were good predictors of what domains are doing cross-party tracking.

Can we just delete all of their cookies?
Hmmm, not really: some sites were both trackers and popular websites. You don't want to break them.

So they decided to use an additional signal: user interaction. If there's no user interaction, you can delete cookies and website data.
Is there is user interaction, you restrict but keep the cookies for a certain amount of time.

Time for a live demo!
The speaker loads news websites in Safari, with ITP debug mode active.

A bunch of domains, classified as trackers, appear on the console, and corresponding cookies are deleted.
What happened since them? An arms race, that led ITP enhancements.

They observed two counter attacks: HSTS supercookies, and something based on links.
HSTS supercookies are a super fun and evil technique and you should absolutely read about it. It abuses a security feature of HTTP to create unique fingerprints:

security.stackexchange.com/questions/7951…
It's way worse than cookies, because it's global! Anyone can check for this. The transparency story is also way less terrible.

How to fix this? They forbade 3rd parties to set HSTS, and only allow 1st-parties to set HSTS for a small subset of subdomains.
HSTS is also not applied for third-party requests for which ITP blocks cookies.

The second evil technique is link decoration.
Some social networks were not happy with ITP, so they added a unique ID in links as additional URL params (something like "?clickID=1234"), and then read that information with a third-party script on the destination website.
How to prevent this?
The logic is that if:
- there's a navigation from a domain classified by ITP
- the landing URL has a query string of fragment
then cap the page client-side cookies by 24h.
What's the way forward? We need to address the needs of the web to prevent the arms race from going further.

And remember, there are legitimate uses for third-party cookies, for example embedded, subscription-based videos.
To allow for this type of use case, you can wait for user interaction and allow the embedded content to ask the user for permission to use the cookie. But you only allow that to happen if the user visited the website. (That's the Storage Access API)
There's a live demo for this, too, and this is also being implemented in Edge and Firefox.
Another important use case to serve is ad-related: ad click attribution. It's vital for advertisers to be able to learn how effective their campaigns are. How many people bought a product after seeing an ad?
Can we let them retrieve that information, without identifying users? We also don't want Apple to sit in the middle of this matching.
The proposed solution, Private Click Attribution, works in three steps:
1. Store ad clicks. Safari will remember which ads were clicked on.
2. Match conversions against stored clicks.
3. When a contribution happens, allow an HTTP redirect to the advertiser website.
The advertiser sees information like "someone clicked on campaign X", and then "someone who clicked on campaign X bought thing Y"
but there's no linkability between these two events.
The speaker ends by saying that privacy protections should be on by default, that fixing cookies is not default, and hoping that other browsers follow.
Audience question about fingerprinting and IP tracking; Apple is trying to limit entropy on the Web platform, other browsers are also going this route. No clear answer for IP, this is a hard problem.
Question from @LeaKissner: how does the private click attribution thing prevent fraud?
Answer: it's an open question, currently being discussed. Look at the GitHub repo for more info.
@LeaKissner Question about the dialog that asks about the cookie: will users understand it? Answers: we designed with the intention of being understandable; it's hard.
@LeaKissner Q: what prevents me from giving every user a distinct ID?
A: we restrict this to 6 bits of entropy. You can only track 64 campaigns at once, and 64 types of conversion. They're discussing giving a bit more flexibility, limiting to 12 bits in total.
@LeaKissner Q: what about redirects?
A: we'll pick that up and cookies will be deleted.
@LeaKissner Q: are tracker companies part of the conversation, or are they just seen as adversarial?
A: we believe that cross-site tracking is bad for the web. We acknowledge that there are legitimate use case and we try to propose solutions for those.
@LeaKissner Q: can we have ITP part of the standard?
A: we haven't proposed it as part of the standard, but it's all open-source (including the ML model). Firefox built something similar, Edge has something in beta. Maybe at some point there'll be standardization?
@LeaKissner Q: There are a bunch of browsers thinking about the privacy side of things. Are there particular groups that are good at collaborating with you and deserve a shout-out?
A: The ones you mention (Brave, Firefox) are doing great things.
@LeaKissner That was a great talk! Thanks @johnwilander for engaging with the academic community! #usesec19
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Ted
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!