Block lists have limitations, most specifically blocking trackers on the web can break websites.
In UIWebView with usage of URLProtocal.registerClass a custom network handler could be created. At Cliqz we've used this approach to run our Anti-Tracking technology that removes sensitive information from payload on the fly without blocking entire request.
We would like to see a similar capability available in WKWebView, which could be modeled after WKNavigationDelegate but working for all requests not only for top-level loads.
A common critique of having async network handlers (cost of IPC) is that it affects performance negatively. Yet we believe this argumentation should not be used in the feature dispute as the cost is associated to the browser vendor not the OS.
This issue in meant to start the discussion on how to approach the implementation of such functionality and justify it necessity.
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):
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).