Bug 213879 – Disable ITP in WKWebView used in hybrid native app

• Status: NEW
• Component: WebKit API

[Daniel Röder]

We have a hybrid native app which uses a native frame around a WKWebView. Inside the app runs a localhost web server to which the WKWebView connects. The locally hosted web site, currently running on HTTPS protocol (using a self-signed certificate, soon to be replaced by a custom protocol), does XHR calls to some backends. Media assets are loaded from a CDN. For Authentication we use cookies, both for the user session information and for the media assets. We do so to avoid access to the credentials from within the app, as both cookies are server side, secure and httpOnly. Additionally, those cookies are also sent to our media CDN to authenticate the user and check media access, without the need to alter media URLs or add any kind of authentication token to them.
With the announcement of enabling ITP for WKWebView this scenario might not be working anymore, as we would face a 3rd party cookie context in that case, which blocks both authentication cookies.
Is there a way to whitelist a couple of backend / CDN domains, so the cookies are not blocked? Is there a way to deactivate ITP for this specific case (localhost) without user interaction.

[John Wilander]

Hi! Thanks for filing!

We try to use “allow list” for what you’re describing.

To better understand what your scenario is, here are some questions:

1) How many domains are involved in your case?

2) Is there kind of a “main domain” and a set of third party domains or does the main domain also change?

3) Do you own or control all of these domains, i.e. are they all part of the same organization?

4) Does the locally hosted content load from https://localhost and will change to [custom scheme]://localhost?

[Daniel Röder]

Hi, thanks for your fast comment. I'll try to answer your questions in the best way possible. 

1) There are round about 5 domains involved.
2) Yes, there is a "main" domain, which is our backend. Usually this does not change and stays fixed, but I would never say never, as there could be external factors forcing us to change it (but not on short term basis)
3) Yes.
4) Currently we use https://localhost, but plan to switch to [custom scheme]://localhost in the (near) future.

If you have any other question and need more details, please do not hesitate to contact me.

[Daniel Röder]

Another question for clarification: You asked directly if we use https://localhost or [custom scheme]://localhost -> are there any differences in the ITP handling for these? Could you guide us some steps we could do now to mitigate the risk of having an App, where users are unable to login? Any hint and suggestion is highly appreciated, as this is a serious business risk for us.

Thank you very much.

[Daniel Röder]

Is there any update on this? We still struggle with getting cookies to work within our hybrid app. We tried to use a proposal given by a Dev on a one on one session during WWDC20. He told us to set app bound domains within plist file to allow cookies for these domains. We tried this with two different frameworks. Unfortunately in neither case a cookie was sent to the desired backend/CDN for authentication. Could you please provide us with feedback how cookies should work in a HybridApp / Shop App example as the ones given here: https://webkit.org/blog/10882/app-bound-domains/ seems not to work? We heavily rely on cookies for authentication for both XHR requests and providing security for media assets delivered with CDNs.

[Daniel Röder]

Update on AppBoundDomains: In regards to this https://developer.apple.com/forums/thread/651138 app bound domains are supposed not to work.

[John Wilander]

Hi Daniel and thanks for filing! There’s an ongoing conversation in this bug: https://bugs.webkit.org/show_bug.cgi?id=213510

[Eric Kampf]

(In reply to John Wilander from comment #6)
> Hi Daniel and thanks for filing! There’s an ongoing conversation in this
> bug: https://bugs.webkit.org/show_bug.cgi?id=213510

Hi John,

(In reply to John Wilander from comment #6)
> Hi Daniel and thanks for filing! There’s an ongoing conversation in this
> bug: https://bugs.webkit.org/show_bug.cgi?id=213510

Hi John - 3 months have passed since any meaningful update on this issue and the one you referenced.  Could you please provide a status update?

[John Wilander]

Hi! There is no update which is why there’s nothing being said in these Bugzillas. We are still interested to hear about further use cases so it makes sense to keep them open.

[Eric Kampf]

I have added my use case to the issue you noted: https://bugs.webkit.org/show_bug.cgi?id=213510.  Several of us have reported the same problem, with similarly structured apps: local web content which makes XHR calls to a remote domain.  Each of these apps is affected because the remote domain uses cookies for authentication. 

FWIW, I would not consider this bug report an accurate measure of the impact.  I have been wrestling with this problem for several weeks now and it took me that long to find my way to this bug report.  Cookie-based authentication is still widely used as is Apache Cordova.  Thus I suspect the number of apps impacted could be far greater than what is reported in this issue.

Can you provide some insight into whether or not this will be addressed in Webkit?  From what I hear, and do not hear, it sounds unlikely.  Either way it would be good to know so that we all can decide if we should pursue other work-arounds.

[Brent Fulgham]

<rdar://71522811>