Web views

[martinthomson]

Other libraries, like the Android, iOS, and Windows WebView libraries, are designed to support many kinds of applications. Because some of these applications include only their own content, WebView libraries are not meant to be user agents on their own, and they do not implement the user agent duties.

-- https://w3ctag.github.io/user-agents/#ua-as-software

I think that this misses something. A WebView is not necessarily a user agent, but an application can use a WebView in order to become a user agent. In many ways, these applications are more user agents than Android's Custom Tabs, which is the user agent rather than the application that embeds it.

The line followed by the Facebook app on Android and iOS is an instructive case to consider. I argue that this is a user agent. Facebook might not like that characterization, because their use of the WebView is limited. (They might also not like the potential legal implications of being designated as a user agent.)

I don't think that you need to agree regarding the status of Facebook's app as a user agent, but you do need to say that the application is a user agent more directly than this:

Ultimately, an embedding application is responsible for following the user agent duties if it, or any part of it, acts as a user agent. This can be straightforward if the application only browses external content through a user agent library. Developers need to take extra care to follow the user agent duties when using a non-user agent WebView to implement an in-app browser .

[martinthomson]

(Expansion of stuff from meeting notes)

Point is clear enough on the libraries not being responsible, but need to expand on embedding app being responsible:

1. Sometimes just embedding one of these libraries causes the app to become a user agent, even if that wasn't their intent. That's a warning. This happens if the embedding application allows navigation and other actions that the library might take on its own.
2. The bright line assumed right now is that access to external content is where the application moves from using the web as a way to access certain capabilities into being a web user agent. Might not be the only way. Also, there are cases where the URL might change, but it is still not fully capable as a web user agent. Just as some content on sites is sourced from third party vendors (for DoS mitigation, login, payments, and more fancy stuff that are generally tricky to get right for small site owners), you can imagine sourcing content from multiple places to provide a single coherent application that uses web technology as a way to build something more efficiently.

More fundamentally, applications are often user agents, even if they stick to a single purpose. They are just limited in scope and therefore not web user agents in the sense this document cares about. Where they become user agents in a meaningful sense is when they expose some of the more significant capabilities of the platform. Navigation between sites under different adminstrative control might be top of the list as the defining characteristic of the web. However, there are things that are less clear: form controls, reinterpretation of content (for accessibility or otherwise), and powerful features like payments.

[imsenyu]

Here’s my perspective based on observed usage scenarios of WebView in mobile SuperApps, which may help inform the discussion on duties.

From the perspective of technical capabilities, WebView is commonly used for:

• for MiniApp pages (though many vendors also use Flutter or other native rendering engines);
• for regular web pages;
• for limited-size cards (non-fullscreen), a rapidly growing scenario in areas like AI/Agent/ChatBot.

From the perspective of content provider, WebView content can be categorized as:

• first-party content, as the SuperApp’s own services;
• third-party content (such as MiniApp) from an app store within the SuperApp, where the pages and data come from legally independent third-party providers;
• open web content accessed via QR codes, links, etc., opened within the SuperApp.

The current discussion appears to focus more on the second perspective (content provider)—i.e., what responsibilities the vendor should bear when users access content through WebView.

• first-party content, representing the company itself, follow internal governance policies;
• third-party MiniApps have their own legal entities, and the SuperApp acts as an app store to regulate and manage them.
  When certain permissions are required, user authorization will be requested through the SuperApp's interface.

Specifically, for open web content accessed within the SuperApp, common measures include:

• show the domain in the page (e.g., in an address bar or top drop-down area);
• intercepting risky operations (e.g., page redirects, clipboard access, payments) based on a risk rule set (e.g., a blocklist maintained by the SuperApp) and prompting users about potential threats.

[imsenyu]

Summary: #39

• Webview: risky navigation warning #40
• Webview: embedded area indicators #41
• Webview: continuous capabilities style #42
• Webview: avoid multiple permissions at once #43