[Webkit-unassigned] [Bug 205718] WKWebView control over network requests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=205718

Maciej Stachowiak <mjs at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com

--- Comment #2 from Maciej Stachowiak <mjs at apple.com> ---
See also https://bugs.webkit.org/show_bug.cgi?id=138169

(This is perhaps a dupe but with a more specific use case.)

Another possible way to handle this use case would be to directly support payload filtering in WebKit. I'm not totally clear on what this entails, but if it's a good way to protect privacy, we'd likely take patches.

If this post describes the system in question (and is up to date), I think the only thing here that would be a delta relative to current WebKit is stripping suspected IDs from outgoing URLs (and perhaps someday POST data):

https://cliqz.com/en/magazine/how-we-at-cliqz-protect-users-from-web-tracking?pk_campaign=privacyawareness_cliqz-anti-tracking_techblog_en%20

I say this because ITP + Storage Access API already provides a good balance of preventing tracking with cookies while supporting embedded widgets, so only the other two vectors remain an issue.

I think we'd be more likely to accept patches to support this functionality in WebKit (perhaps as a default-off feature if it doesn't seem right for other clients) than to support full network stack replacement or relaying of all network requests to the UI process for modification before they hit the network. (Not the final word, but that's my quick evaluation).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200219/550ad1e8/attachment.htm>