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

11–20 of 254 posts

Re: WebKit Tracking Prevention Policy

#11

Post by om2 »

saagarjha wrote: post #7
om2 wrote: post #3

Earlier quoted context omitted.

Parties that are motivated to do tracking on the web are very creative. Too creative to list every feature they could use. That said, our goal is to as much as possible remove tracking without removing capabilities for non-tracking use cases.

Are there plans to list new limitations and why they are being implemented?

We're working on a list of mitigations that we already have in place. We'd try to keep that updated as we add new ones. The main change here is explaining the conceptual reasoning behind our existing mitigations, and how we will decide on future privacy protections.

Re: WebKit Tracking Prevention Policy

#12

Post by om2 »

saagarjha wrote: post #6
zawerf wrote: post #4

I am not caught up on browser engines, but WebKit is mostly just Safari and iOS browsers right?

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.

Re: WebKit Tracking Prevention Policy

#13

Post by saagarjha »

om2 wrote: post #11
saagarjha wrote: post #7

Earlier quoted context omitted.

Are there plans to list new limitations and why they are being implemented?

We're working on a list of mitigations that we already have in place. We'd try to keep that updated as we add new ones. The main change here is explaining the conceptual reasoning behind our existing mitigations, and how we will decide on future privacy protections.

More explanation of the decision process is a positive in my book :)

Re: WebKit Tracking Prevention Policy

#15

Post by radicaldreamer »

om2 wrote: post #12
saagarjha wrote: post #6

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

Sony's Windows Port?

Re: WebKit Tracking Prevention Policy

#17

Post by akersten »

om2 wrote: post #10
akersten wrote: post #8

Earlier quoted context omitted.

I appreciate the efforts, and thanks for replying. My fears are mostly for performant web apps (e.g. games, 60hz+ refresh) where timers are inexplicably inaccurate on one web engine with no documentation explaining why. I hope the restrictions are more subtle, and I understand the desire to keep them somewhat secret this early on.

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 mitigations against those kind of measurements. I don't think it's possible to catalog all the various routes by which data could be inferred by timing. If things like this are in the scope of what Webkit is trying to prevent, I'm fairly nervous.

Off topic, but just for some game industry perspective: often we don't want to sequence exactly at the refresh rate (especially if it's variable or frames are being dropped) in contexts like logic loops or physics simulations that need to happen at specific frequencies regardless of how quickly frames are drawn. For example, synchronizing a client "tick rate" with a game server's requires millisecond precision.

Re: WebKit Tracking Prevention Policy

#18

Post by anaisbetts »

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

Re: WebKit Tracking Prevention Policy

#19

Post by elgenie »

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

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.

Re: WebKit Tracking Prevention Policy

#20

Post by eridius »

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

> 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 sites like Gmail & YouTube

The only way this is "broken" that I can see is the user has to log in separately to each site. Which seems fine to me. In fact, this is a good thing; just because I log into Gmail with one account doesn't mean that's what I want to use for YouTube.

Post reply on HN