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)?
WebKit Tracking Prevention Policy
21–30 of 254 posts
Re: WebKit Tracking Prevention Policy
#22If 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...
Preventing Google ad tracking? Nothing of value is lost. Besides, Apple has had a built in content blocking framework since iOS 8 that allows third party ad blockers. I’ve been blocking Google’s ads for years.
Re: WebKit Tracking Prevention Policy
#23If 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...
Unfortunately, under the current interpretation of US anti-trust law (thanks Robert Bork!), leveraging monopoly to knee-cap competitors is a-OK if it doesn't directly hurt consumers. The chances of anti-trust law returning to an interpretation that protects competition under the current judiciary are nil.
How is Apple blocking an ad network “anticompetitive” when Apple’s only ad platform is within the App Store?
Re: WebKit Tracking Prevention Policy
#24Would "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"?
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.
Re: WebKit Tracking Prevention Policy
#25If 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...
> 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.
Re: WebKit Tracking Prevention Policy
#26Earlier quoted context omitted.
WebKit is also used in a number of other places, such as GNOME Web and browsers for many consoles.
Indeed, the Gtk+ and WPE ports, as well as Sony's Windows port, are the most active after the Apple-maintained ones.
the browser in Steam client also uses webkit
Re: WebKit Tracking Prevention Policy
#27Earlier quoted context omitted.
Unfortunately, under the current interpretation of US anti-trust law (thanks Robert Bork!), leveraging monopoly to knee-cap competitors is a-OK if it doesn't directly hurt consumers. The chances of anti-trust law returning to an interpretation that protects competition under the current judiciary are nil.
How is Apple blocking an ad network “anticompetitive” when Apple’s only ad platform is within the App Store?
Well, how does a competitor make money on iOS without giving Apple a 30% cut of app installs and in-app purchases and/or using their ad network?
Re: WebKit Tracking Prevention Policy
#28Earlier quoted context omitted.
How is Apple blocking an ad network “anticompetitive” when Apple’s only ad platform is within the App Store?
Well, how does a competitor make money on iOS without giving Apple a 30% cut of app installs and in-app purchases and/or using their ad network?
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”.
Re: WebKit Tracking Prevention Policy
#29Earlier quoted context omitted.
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.)
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 mitigatio…
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.
Re: WebKit Tracking Prevention Policy
#30Given 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)?
Depends on whether these drop-in solutions track cross-site, and whether they strictly limit data collection to the context of the first party site.