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

221–230 of 254 posts

Re: WebKit Tracking Prevention Policy

#221

Post by geofft »

quotemstr wrote: post #174
saagarjha wrote: post #66

Earlier quoted context omitted.

> Non-contextual advertising still exists, but it's perceived as less effective, so there's a lot less money in it. I don't know if that perception is correct, but I do remember back when a common complaint from people was that the ads they saw weren't relevant to them. As far as I’m aware, the current state of advertising is people either being too creeped out by ad suggestions to buy anything or still feeling like…

> As far as I’m aware, the current state of advertising is people either being too creeped out by ad suggestions to buy anything or still feeling like they’re getting bad recommendations. Given the massive revenues that advertising generates, how could you think this judgement (which I'm sure accurately reflects how _you_ feel) applies universally?

There's an old saying in marketing that half of your advertising money is wasted, you just don't know which half.

It's entirely possible for most people to find advertising either useless or creepy and for significant amounts of advertising revenue to nonetheless exist. And even if ads work some small fraction of the time, they can still be genuinely profitable for the advertisers.

Re: WebKit Tracking Prevention Policy

#222

Post by 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"

Re: WebKit Tracking Prevention Policy

#223

Post by rpastuszak »

andykx wrote: post #42
rale00 wrote: post #40

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?

It is not impossible to advertise without tracking users.

Contextual targeting is fairly kosher and can be genuinely useful. Let's hope changes like these make the current approach less feasible, cost-wise.

Re: WebKit Tracking Prevention Policy

#224

Post by w1nst0nsm1th »

om2 wrote: post #9
saagarjha wrote: post #5

Actual link to the 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…

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…

It’s hard to swallow but after switching from Windows to Debian to Macbook, from Android to iOS, I'm now an unwillingly Apple Fan.

Knowing Apple is willing to protect my privacy is one of the main reason I stick to it and not to Android (despise the fact I love the unix/linux like ecosystem) or (f@ck@ng) Windows.

Re: WebKit Tracking Prevention Policy

#225

Post by p4bl0 »

jefftk wrote: post #216
p4bl0 wrote: post #204

Earlier quoted context omitted.

quotemstr was talking about the infrastructure that they control. It's true that they can track visitors server-side if they want to.

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

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?

Re: WebKit Tracking Prevention Policy

#226

Post by jefftk »

p4bl0 wrote: post #225
jefftk wrote: post #216

Earlier quoted context omitted.

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

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?

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

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

Re: WebKit Tracking Prevention Policy

#227

Post by kitsunesoba »

ignoramous wrote: post #144

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

The App Store requires apps to obtain user consent before doing any kind of tracking and only allows one method of identifying users (advertising ID), which the user can reset whenever they feel that apps are getting too creepy with their tracking. While there have been other ways to fingerprint users, Apple has been aggressively pursuing each avenue and closing them off.

Re: WebKit Tracking Prevention Policy

#228

Post by om2 »

jefftk wrote: post #190
Fnoord wrote: post #136

Earlier quoted context omitted.

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)

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.

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.

Re: WebKit Tracking Prevention Policy

#229

Post by om2 »

mstade wrote: post #191
majewsky wrote: post #153

Earlier quoted context omitted.

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?

The linked page is primarily based on tech in the WebKit open source tree. However, some protections depend on support in underlying layers. WebKit's strategy is to use the platform-native versions of things like the network stack and font loading.

Re: WebKit Tracking Prevention Policy

#230

Post by om2 »

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?

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.
Post reply on HN