WebKit Tracking Prevention Policy
webkit.org
WebKit Tracking Prevention Policy
1–10 of 254 posts
Re: WebKit Tracking Prevention Policy
#2Is there a specific list of the web features that are being restricted? I couldn't find it in the document, and to me pretty much any web feature could be used for fingerprinting. It would be good to have a roadmap for workarounds developers will need to implement to keep legitimate applications working on Webkit.
Re: WebKit Tracking Prevention Policy
#3Is there a specific list of the web features that are being restricted? I couldn't find it in the document, and to me pretty much any web feature could be used for fingerprinting. It would be good to have a roadmap for workarounds developers will need to implement to keep legitimate applications working on Webkit.
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.
Re: WebKit Tracking Prevention Policy
#4I am not caught up on browser engines, but WebKit is mostly just Safari and iOS browsers right?
Re: WebKit Tracking Prevention Policy
#5Actual 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 may apply universally; to algorithmically classified targets; or to specific parties engaging in circumvention.
Is this trying to say that WebKit will now apply restrictions to specific parties that the project feels is circumventing tracking prevention? I'm all for these features, but only if they're applied evenly and in a clear way. The solution to circumvention should be mitigations against bypasses, not selective enforcement :/
Re: WebKit Tracking Prevention Policy
#6I 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.
Re: WebKit Tracking Prevention Policy
#7Is there a specific list of the web features that are being restricted? I couldn't find it in the document, and to me pretty much any web feature could be used for fingerprinting. It would be good to have a roadmap for workarounds developers will need to implement to keep legitimate applications working on Webkit.
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?
Re: WebKit Tracking Prevention Policy
#8Is there a specific list of the web features that are being restricted? I couldn't find it in the document, and to me pretty much any web feature could be used for fingerprinting. It would be good to have a roadmap for workarounds developers will need to implement to keep legitimate applications working on Webkit.
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.
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.
Re: WebKit Tracking Prevention Policy
#9Actual 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 protections, which are based on block lists to a significant extent. The disconnect.me list is likely to be trustworthy, but ultimately it is manually curated. We've tried to stay away from using lists like that.
Re: WebKit Tracking Prevention Policy
#10Earlier 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.
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.)