Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Tracking Prevention Policy

webkit.org

Post reply on HN
Print view View original

191–200 of 254 posts

Re: WebKit Tracking Prevention Policy

#191

Post by mstade »

majewsky wrote: post #153
mstade wrote: post #127

Earlier quoted context omitted.

Isn't WebKit open source though, including this tech?

An open-source program can easily use a closed-source blocking list. For example, the blocking list could be distributed as a list of hashes, and the program hashes the domain name to search for it in the list.

Sure but that's why I asked if the blocking tech was open source as well, but I probably didn't ask it very clearly. I couldn't tell from the linked page whether the tech (whether lists or algorithms) were closed or open, but if it's the latter wouldn't that be enough disclosure?

Re: WebKit Tracking Prevention Policy

#192

Post by tuxone »

om2 wrote: post #157
po wrote: post #148

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…

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 trac…

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

Re: WebKit Tracking Prevention Policy

#193

Post by jefftk »

p4bl0 wrote: post #166
quotemstr wrote: post #165

Earlier quoted context omitted.

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.

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 somethin…

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

The public suffix list historically has been opt-in. If you look at the (human readable) https://publicsuffix.org/list/public_suffix_list.dat you'll see:

    // GitHub, Inc.
    // Submitted by Patrick Toomey 
    github.io
    githubusercontent.com
Major companies have historically wanted to list their user-content domains on the PSL because it helps protect users cookies from other users. It's possible that this announcement changes things, but I think it mostly doesn't.

The main problem with a DNS-based system is just that you would need to get everyone to switch to it, and figure out what to do in the mean time. If ".io" or someone doesn't set the DNS flag then that's a major security issue for everyone under it.

Re: WebKit Tracking Prevention Policy

#194

Post by jefftk »

quotemstr wrote: post #172
p4bl0 wrote: post #166

Earlier quoted context omitted.

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 somethin…

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.

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

Re: WebKit Tracking Prevention Policy

#195

Post by scarface74 »

hesarenu wrote: post #170
scarface74 wrote: post #28

Earlier quoted context omitted.

Simple, the same way that Spotify, Netflix, Amazon (Kindle), DirecTVNow, Sling, and a bunch of other companies do - force people to pay on their own websites to use the app.... Apple doesn’t have an “ad network”.

why can't they do it on their app?

Can I pay the manufacturer of a good directly and walk into a retail store to pick it up?

But let’s not be overly idealistic, the vast majority of revenue in either App Store is from games and most of that is from in app purchases of coins, gyms, loot boxes etc.

Re: WebKit Tracking Prevention Policy

#196

Post by lmkg »

tuxone wrote: post #192
om2 wrote: post #157

Earlier quoted context omitted.

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 trac…

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

This has been a feature of Adobe Analytics for over a decade. Google Analytics doesn't currently offer this as a feature, but some enterprising individuals have explored how to hack it in after ITP 2.1 was announced.

Re: WebKit Tracking Prevention Policy

#197

Post by _jal »

vinay_ys wrote: post #185
om2 wrote: post #9

Earlier quoted context omitted.

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…

This is all good, but I'm not a fan of my browser being remotely controlled by anyone to modify any of its expected behavior to do special/specific things on different websites without my informed consent. Even the browser vendor has to be held to the same high standard (or even higher) of being completely open and transparent about what they and when they do it.

Your requirements are already not being met. All the major browsers self-update, employ lists of sites for special handling, and fail to ask you when those are updated.

Of course, you can disable auto-update, and then you're likely to be remote-controlled by someone you didn't choose.

Re: WebKit Tracking Prevention Policy

#198

Post by yyyk »

the8472 wrote: post #183
yyyk wrote: post #154

Earlier quoted context omitted.

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

Re: WebKit Tracking Prevention Policy

#199

Post by the8472 »

yyyk wrote: post #198
the8472 wrote: post #183

Earlier quoted context omitted.

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.

Re: WebKit Tracking Prevention Policy

#200

Post by awinder »

inapis wrote: post #173
Vinnl wrote: post #159

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 tak…

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.

I think Apple is pretty clearly able to "compete with free" and has shown it's possible to make great money by bundling some costs into the hardware + offering good cloud services with low-friction payments.
Post reply on HN