A way for websites to opt out from being loaded in a WebView

[muodov]

This issue was initially raised in #36

There is a case to be made that web pages should have a way to opt-out from being rendered in a WebView, similar to how they can forbid iframe embeds. @adrianholovaty surfaced some concerns in Let websites framebust out of native apps:

• some apps try to build their business on unauthorized usage of someone else's IP (by "embedding" web apps inside their native apps)
• in-app browsers often have web compatibility issues, and it's not always clear to the user that breakage may be caused by the WebView and app customizations
• malicious apps may use powerful WebView features to bypass web security boundaries and access user data: Harmful content modifications by native apps #40

[muodov]

The last two concerns (webcompat issues and malicious apps) deserve their own threads IMO, as they sound more like WebView deficiencies rather than something a web app might choose or not.

The solution proposed in the article is to respect X-Frame-Options: deny, and load the page in the "user's preferred browser". I see a few problems with that:

1. the "user's preferred browser" may be also based on WebView (e.g. DuckDuckGo on Android or any non-Safari browser on iOS). Should they be blocked too?
2. some pages may want to be viewed in some native apps, but not the others (e.g. Soundslice app may want to open soundslice.com in their own mobile app, but disallow it in the Instagram IAB). In the web world, this is solved by CSP frame-ancestors with specific list of origins, but native apps have no "origins" at the moment: Relation between web origins and native apps #42
3. If we consider WebView as "embedding", blocking makes sense. On the other hand, if we consider the native app a "browser", this case is very similar to blocking based on user-agent, which is generally regarded as a harmful practice on the web
4. In Web extensions, they explicitly declare access permissions to web origins. This is looked at both during the store review, and by the user in permission prompts. For WebViews, this would mean that we need to somehow connect web origins and native apps: Relation between web origins and native apps #42

[rejhgadellaa]

The solution proposed in the article is to respect X-Frame-Options: deny, and load the page in the "user's preferred browser" [ ... ]

Just to have it mentioned here, Alex Russel proposed using a new CSP frame-ancestors value in his Hobson's browser post:

Content-Security-Policy: \
  frame-ancestors 'system-default';

Upsides compared to X-Frame-Options:

• As I understand, X-Frame-Options is deprecated in favor of frame-ancestors anyway
• Does not repurpose and/or modify existing behavior
• CSP can also be set via a <meta /> tag, not just headers

[pmeenan]

Presumably this opt-out needs to be provided in a way that the Application can not just arbitrarily override. That will probably require putting some webview capabilities behind app store permissions to at least make them explicit.

Anything that can intercept requests or set the HTML content of the webview directly fall into that bucket but it's probably also worth getting some security experts to weigh in.

Ability to configure proxies or app-level VPN and client trust roots (combined allow for arbitrary interception) probably fall into the bucket as well.

[adrianholovaty]

Thanks for creating an issue on this. (I'm the guy who had surfaced the concerns in the aforementioned article.)

In my particular business case for Soundslice, I do indeed want to be able to embed the Soundslice website within condoned native apps — on a case-by-case basis that I control.

Also, for the record, although I suggested X-Frame-Options, I'm by no means married to that solution.