WebKit Tracking Prevention Policy • Hacker News Board

Re: WebKit Tracking Prevention Policy

#31

Post by braythwayt » Thu, Aug 15, 2019, 2:27 AM UTC

anaisbetts wrote: post #18

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

I find it easy to explain that Apple is not using a mobile phone monopoly to X, for any X, by virtue of the fact that Apple does not have a mobile phone monopoly, not even close.

If I want Google ad tracking on my phone, I have a bewilderingly large selection of Android phones to choose from, all of which run on the same mobile networks as my iPhone, work with the same Internet, and all of the apps I consider part of my mobile workflow, like my PagerDuty and my banking app, are available on Android as well as iOS.

I’d say it’s hard to use the words “monopoly” and “Apple” in the same sentence. They don’t have a monopoly in phones, tablets, laptops, desktops, wearables, streaming music, data storage, messaging, calendars, productivity apps, or anything else that I can think of.

Re: WebKit Tracking Prevention Policy

#32

Post by om2 » Thu, Aug 15, 2019, 2:27 AM UTC

1986 wrote: post #25

eridius wrote: post #20

Earlier quoted context omitted.

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

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.

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.

Re: WebKit Tracking Prevention Policy

#33

Post by om2 » Thu, Aug 15, 2019, 2:31 AM UTC

anaisbetts wrote: post #18

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

That tweet is misinterpreting the “Unintended Consequences” section. Those are things we want to keep working, and if we break them, we will create alternate solutions (like Storage Access API for social embeds, and Private Click Measurement for as attribution).

Re: WebKit Tracking Prevention Policy

#34

Post by anoncareer0212 » Thu, Aug 15, 2019, 2:31 AM UTC

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…

You're manually curating a specifically targeted mitigation list, but it's non-public. Mozilla/Edge's approach seems preferable, not problematic

Re: WebKit Tracking Prevention Policy

#35

Post by om2 » Thu, Aug 15, 2019, 2:32 AM UTC

radicaldreamer wrote: post #15

om2 wrote: post #12

Earlier quoted context omitted.

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

Sony's Windows Port?

They maintain a Windows port of WebKit as a reference implementation.

Re: WebKit Tracking Prevention Policy

#36

Post by om2 » Thu, Aug 15, 2019, 2:34 AM UTC

anoncareer0212 wrote: post #34

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…

You're manually curating a specifically targeted mitigation list, but it's non-public. Mozilla/Edge's approach seems preferable, not problematic

We are not presently manually curating a specifically targeted mitigations list. Just saying we might in the future. We did do a one shot rollback of HSTS super cookie abuse in the past, but that’s it.

Re: WebKit Tracking Prevention Policy

#37

Post by 1986 » Thu, Aug 15, 2019, 2:34 AM UTC

om2 wrote: post #32

1986 wrote: post #25

Earlier quoted context omitted.

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.

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.

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

Re: WebKit Tracking Prevention Policy

#38

Post by imbored » Thu, Aug 15, 2019, 2:47 AM UTC

Tracking and privacy should be areas where other browsers go after chrome hard.

Re: WebKit Tracking Prevention Policy

#39

Post by imbored » Thu, Aug 15, 2019, 2:48 AM UTC

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…

If the mitigation’s work fine for reasonable sites then further restrictions on bad actors is entirely reasonable.

Re: WebKit Tracking Prevention Policy

#40

Post by rale00 » Thu, Aug 15, 2019, 2:51 AM UTC

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?