206521 2020-01-21 02:18:44 -0800 WKWebview: Unable to control HTTP Referer policy 2020-02-19 01:43:33 -0800 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build iPhone / iPad Unspecified NEW InRadar P2 Normal --- 1 sam webkit-unassigned beidson krzysztof.modras mjs sam webkit-bug-importer oldest_to_newest 1608970 0 sam 2020-01-21 02:18:44 -0800 In testing we observe that WKWebview currently sends full Referers to all origins (including third-parties) on page load. This this a [known tracking a security vulnerability](https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/) that all apps using WKWebview are susceptible to. There is currently no way (that we are aware of) to override this behavior. 1609548 1 webkit-bug-importer 2020-01-22 08:26:41 -0800 <rdar://problem/58797376> 1620555 2 mjs 2020-02-19 00:16:22 -0800 Would it be satisfactory if WebKit always sent origin-only Referers, instead of exposing a policy? (Safari does this already, but I think it may be tied to ITP, perhaps unnecessarily.) 1620575 3 krzysztof.modras 2020-02-19 01:43:33 -0800 Just for reference - Firefox comes with advanced set of configuration options for referers https://wiki.mozilla.org/Security/Referrer Most important parameters are: - when to send (all requests, on interaction, never) - trimming (removing path/query) - origin control (don't send to 3rd parties) Perhaps changing the default behaviour would be fine, but I'm not aware of all usecases. From privacy oriented web browser (like Cliqz) perspective it's definitely a way forward, but I could imagine some apps could experience breakage or may prefer to have referes. It's more for WebKit team to decide how much of general purpose tool the WKWebView should be.