[Webkit-unassigned] [Bug 138169] WKWebView does not support NSURLProtocol-style interception of http or https

[bugzilla-daemon at webkit.org]

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

--- Comment #51 from Maciej Stachowiak <mjs at apple.com> ---
Some replies to issues with a per-WKWebView proxy as a possible way to address some of the use cases for this.

(In reply to Eugene But from comment #45)
> Having *per-WKWebView* proxy setting is useful for Chrome to support some
> Enterprise features that Chrome for iOS lost after moving from UIWebView to
> WKWebView.
> 
> 
> There are some other use cases that proxy setting do not address:
> 
> 1.) Innovate in networking space, like Google did with Speedy and doing with
> QUIC (this requires full support of custom network protocols)

We aren't currently looking to support plugging in new protocols under the http:/https: schemes. We do support HTTP2 (the standardized version of SPDY) on Apple platforms, and I think it's no secret that there is a prototype of IETF QUIC + h3.

> 2.) Better privacy control over cookies, see
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
> (can be done without full network protocols support, but may need new API)

That post is not very specific, so it's not clear what the ask is.

If it's specifically the behavior to treat cookies as SameSite=Lax by default, we're open to doing that, or perhaps something even more strict:
https://trac.webkit.org/changeset/251467/webkit

> 3.) Support WebP (can be done without full network protocols support)

Current plan is to support WebP directly on Apple platforms:
https://trac.webkit.org/changeset/256501/webkit

We may yet change our minds, but in any case, the network stack seems like the wrong layer to add support for new image formats.

> 4.) Change request headers to send the list of chrome experiments to google
> servers (can be done without full custom network protocols support, but
> requires new WKWebView API)

We may add some kind of support for custom headers, but TBH broadcasting extra bits of entropy to Google servers is not an inspiring use case. Also, replacing the whole network stack to add some custom headers to requests seems like massive overkill.

> 
> All these use cases were possible with UIWebView, which supported custom
> network protocols.

(In reply to Simon Brooks from comment #49)
> 
> Few follow up questions to try and understand what the proxy enablement
> would actually allow (disclosure - I work with Ian):
> 
> Would the proxy configuration allow connection to a local proxy? (and if so
> would that work even with ATS enabled with the local proxy not being able to
> offer a valid SSL cert)
> 
> how to chain a further proxy that may require user authentication?
> 
> Would it be better/more consistent to allow the app to participate in a
> per-app VPN type configuration, possibly even using a packet tunnel
> extension provided within the app's own package? I'm not sure that any of
> the other alternatives maintain the background downloading capabilities.

I don't think we have worked out these details. Off the top of my head, ability to do a proxy that MITMs TLS would be a concerning thing to allow, but I can also understand how some use cases would benefit from it. Chaining to proxies that require auth would require passing on the authentication challenge. I'm not sure I understand the background downloading issue.

-- 
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/934342c9/attachment.htm>