Challenge: Apps can use WebViews to bypass web security standards, privacy standards, and user choice. #36
Comments
Network requestsThis proposal discusses the use of frames/documents and permitting the site to opt out of that; I think this is a great starting place. I would suggest that resources are just as concerning for a site; resources likely aren't protecting against the browser being the attacker:
CORS is perhaps a better starting place of a security model into this issue; whereby any domain outside of app-bound domains would be treated as requiring a CORS pre-flight; the site then could send the correct headers to opt-out and permit the connection.
See also:
Preventing document loadsBrowsers don't often make OPTIONS requests on navigations, but also this would be the case with the XFO header requirement; the flow would be:
Browsers often avoid stopping rendering of a top level document; I think it would be preferred to re-use the initial document response.
For 'capability URLs' this is particularly important that the browser doesn't re-issue a connection it's already made. Privacy concernsURL parameters could be a concern here, we're going to be allowing TrackerNetworkA App to open connections into another browser.
The browser should try it's best to circumvent smuggling of tracking ID's across this boundary; if in doubt perhaps ask the user if they wanted it to load in their default browser. Browsers use-case@muodov intends to respond here, I think it's worth warranting a carve-out for browsers that happen to use WebViews; I think this is very distinct to apps that use WebViews as supplemental to their core functionality.
Other
Don't forget CSP frame-ancestors. |
|
The privacy issues stem from the fact that the embedder has access to the web content. Giving websites the ability to opt out from being embedded in a WebView seems like a separate issue to me. I agree that iframes are similar to WebViews conceptually, in #31 I recommended leaning on the web's security model and mapping the iframe's same-origin policy to the WebView scenario. It basically boils down to only allowing embedders web content access to 1P domains. However, there's more to be said here since it will invalidate perfectly valid use cases like #4. That can perhaps be mitigated by OS browser permissions, or user permissions. |
|
@aluhrs13 Thank you for raising this issue! As I understand, there are 3 related problems described in the linked articles (sorry if I'm repeating your statements):
I think all of these cases are important and should be addressed here, and we need to consider details and edge cases. It is worth mentioning that on most platforms apps can bundle a rendering engine and circumvent any protections provided by the Webview. This might be better solved on the platform level, out of scope of this CG. As @rayankans and @jonathanKingston noted above, we should consider the “browser use-case”, when the app’s explicit purpose is providing user agency. In this case the concept of 1st/3rd party domains is not applicable.
|
|
What distinguishes a "browser" from a well-behaving app that is embedding HTML content and from a malicious app attempting to steal credentials? There is a lot of risk of this going very sideways for the web without actually improving the security and privacy issues.
Would miniapps be based on web tech stacks if the webview restrictions existed (or were enforced by the webviews in wechat) when they first came around? I think there are things we can do to make the web work better in an embedded context for well-behaved apps in a way that would be good for the web, apps and users but I don't think a technical solution to prevent abuse by malicious apps is particularly feasible (and hasn't been for a LONG time on desktop). GDPR-like regulations, privacy policies and app-store review of those policies may be able to help reign-in questionable use of data by apps backed by large companies but they may not dissuade the authors behind malicious apps. |
Both are higher barriers of entry (cost, engineering time...) than tracking using a standard WebView. It would make this kind of tracking still possible but harder. Also bundling a whole browser engine in an app that has other purposes would/should raise a flag to app store reviewers.
Perhaps not everything needs to be in the web platform, or be integrated gradually, and that's OK? Some highly integrated experiences require a lot of thinking on how to make them work safely between the main app and untrusted origins. We can innovate on improving those integrations and in the meantime the tradeoff between safety and experience would lead to a solution that's less seamless but more trustworthy.
Create their own proxy browser? again this would be a higher barrier of entry than tracking using WebView APIs. I think the goal here should not be to hermetically seal the possibility to track users, which like you say is something app-stores/GDPR/other regulations can do, but at least to not make it a front-door easy platform provided API.
I think we need to do both. Otherwise why would people do anything different if they can have a WebView out of the box that tracks everything the user does? Also, desktop is different because desktop users behave differently. People don't generally browse the web inside Electron apps. |
No, I mean use a webview but proxy the underlying pages through servers that I control, rewriting content on the edge (pretty trivial if you're targeting specific pages). Something like navigating to: and then have That would satisfy same-origin requirements for webview or an app-level networking policy but is trivial to implement. Heck, that's how WebPageTest can re-write production pages for running what-if tests. You can point the browser to a cloudflare edge worker that proxies requests to the actual origin, rewriting content along the way. Do browsers also have some level of tracking restrictions that should be applied? What, intrinsically, makes the field telemetry reported by "browsers" (and used for search ranking by Google) different from any similar data that a well-behaved webview app would gather (say, to improve ranking of shared content in a social networking app)? Clear privacy policies and requirements should apply to all apps - browser or webview-embedding. Raising the bar for malicious apps while simultaneously breaking use cases for well-behaved apps feels like a bad trade-off that still won't actually prevent malicious usage. |
|
Just coining my 2 cents to advocate for the user and the owner of the site here.
For example, proxying evil.com/my-bank.com would not just work in an IAB, it would also work in a malicious browser app that brings its own engine. If the user decided to trust such an app to be his user agent, XFO and CSF will be pointless anyway. I would argue that users generally do not (knowingly) choose IABs, or any WebView-capable app, to be their user agent, and that scenario is what this proposal (also) targets. Regarding legitimate browser apps that use WebViews (DuckDuckGo comes to mind): yes, there needs to be a mechanism to allow those apps to open websites in a WebView even when that site requests the default browser. DDG can be set as default on Android, I would assume the same goes for iOS? So - oversimplified - if an app is set as default browser, it would continue to open the site? |
|
Great discussion everyone, loving all the perspectives. I just wanted to share a quick note from the WebView CG meeting this morning - We agreed that the existence of this challenge and inclusion in this CG makes sense, but that doesn't mean that we need to come up with a solution. Challenges can exist to help future considerations and discussions, not just be addressed with technical solutions. |
Browsers are applications that handle
No. Browsers can be constructed using WebViews or their own engines. Non-browsers, likewise, should be able to use either a WebView or their own engines, subject to restrictions on non-browsers regarding third-party, non-collaborative content.
Browsers are browsers, per the above definition, and can do whatever they like with first and third-party content. Restrictions should only attach to non-browsers in the context of third-party content.
If the counterfactual to non-browser apps stealing traffic to third-party content they do not produce, maintain, or help monetize as effectively as true browsers do is that this third-party content will somehow not be on the web in the future, the mechanism for that is unclear. If the question is about first and second-party content, apps already frequently move that content out of the open web. But nothing about any proposal here would constraint an app's ability to use a WebView to display that content.
Proxy-and-rewrite is possible today. What such a policy would do is to ensure that bad actors are seen by all to be acting badly, whereas today they hide in the shadows of unobstrusive UI and undocumented-but-broken platform implementations.
To the extent that such an app is the user's choice, and that the app handles
|
|
I don't think we're every going to agree on the basics of what software is "allowed" to present web-addressed HTML content to users (and I'm pretty sure it's a hill that many of us are willing to die on on various sides of the argument). I agree that sites should be allowed to prevent their content from being crawled, scraped or otherwise consumed by a service where they don't want to have their content used. I'm not sure solving that for malicious apps is achievable but I'm totally on-board with defining ways that well-behaved apps should honor content owner's wishes (maybe with options for "block" and "block unless you can open in a system-level default browser"). Same goes for applying privacy and data protection rules equally across all apps - browsers and others equally. Where we differ pretty fundamentally is that I see the "web" as a set of well-defined specs on how to:
Restrictions beyond that are artificial gates that we are inventing to restrict how content can be consumed and presented to users and will forever limit the "web" to running within what we think of as a stand-alone browser today (most of which do more than JUST loading links - and many of which expressly choose to violate the specs to better serve their users). Where it matters for this working group is that webviews provide an easy way for apps to get a high-level of consistency and compatibility with the specs above on a given platform and help contribute to a web that works everywhere. If the relationship becomes more adversarial with well-behaving apps in order to push "the web belongs to browsers" then the risks are that the web just won't work as well or as consistently as it would have otherwise. |
|
Some very thoughtful comments here, thank you all. There seem to be some concrete problems such as tracking in IAB and unwanted embedding (see my previous comment), and also some broader discussions such as "respecting user choice" and "what is a browser". Those are also important and could directly affect the security threat model. Should we split these or are there other perspectives on this? Re the browser definition, I was thinking about this point by @pmeenan:
"normal" browsers have an address bar, which is a natural way for users to verify if they are interacting with a trusted origin. Full-fledged WebViews lack the address bar and other UI elements, which by itself may be a concern in scenarios like this. |
+1 |
|
I took a stab of splitting this discussion into separate threads:
I couldn't articulate the "user choice" problem as it feels like something platform-specific, but happy to be corrected. @KrauseFx Is there anything I missed? |
Apps can use WebViews to bypass web security standards, privacy standards, and user choice.
Submitter(s)
Andy Luhrs
Motivation
Ensure privacy and security considerations and designs of the web are upheld regardless of if a browser or another app is serving the content.
Analysis
WebViews are extremely useful for apps trying to host their own web content in an application like many of the use-cases we've discussed. However, many of these use-cases could also be used in a malicious or user-hostile manner such as clickjacking or tracking. We need to ensure that websites have a mechanism to protect themselves and their users.
There have been three very thorough articles covering the problems in this space:
Additionally, many of the cases in the RFC for the
X-Frame-Optionsheader can be applied to WebViews.Related W3C deliverables and/or work items
As mentioned above, the
X-Frame-Optionsheader is a solution to a similar problem.How is the issue solved in the Browser?
There's very few places in a browser similar to this, the closest would be:
X-Frame-Optionsheader.What's needed?
We need to propose a method for websites to opt-out of being hosted in a WebView to protect their content and their users. The posts above have a few reasonable starting points, in short:
X-Frame-Optionsheader (Article 3 above)This CG should go deeper into these problems and potential solutions.
The text was updated successfully, but these errors were encountered: