Use case name
Define different types of webviews
Submitter(s)
Niklas Merz
Motivation
As we discuss more and more use cases it might be helpful to define and name the different uses of webviews. Webviews can be used in many different ways and some of them are vastly different in terms of privacy and security implications. It could be a good idea to separate them into different categories to discuss them better.
Stakeholders
Browser vendors
App developers
Analysis
We can already see these different categories of webviews with the APIs available on the two big mobile platforms. Android offers a powerful webview API and Chrome Custom Tabs. iOS has WKWebView for a rich webview API and SFSafariViewController for a more browser-like experience embedded in native apps.
The webview APIs offer powerful features for example injecting JavaScript or other interactions with the pages loaded into the webview. These features require the designers of the webview APIs and app developers to think a lot about the security and privacy implications of their design choices. Webviews that allow the user to navigate the web freely need to be much more secure and restricted than webviews that just allow code under control of the app developer.
Webviews are used a lot to build the UI or core features of apps. These apps could benefit from more control over the native parts of the app or vice versa the native code might want to have more control over the web content.
The distinction between browser-like webviews and full webviews embedded into apps is the most obvious one but there are many more like we see with ePub and mini apps.
If there are different types of webviews with different use cases and feature sets app developers could benefit from more freedom or security and privacy. Browser vendors could roll out powerful features for developers of apps built around webviews but still keep the browsers and browser-like webviews secure.
Related W3C deliverables and/or work items
How is the issue solved in the Browser, and what’s more is needed?
Webviews and browsers currently always have the same features and restrictions. Different webview implementations share different APIs to interact with the webview content.
Use case name
Define different types of webviews
Submitter(s)
Niklas Merz
Motivation
As we discuss more and more use cases it might be helpful to define and name the different uses of webviews. Webviews can be used in many different ways and some of them are vastly different in terms of privacy and security implications. It could be a good idea to separate them into different categories to discuss them better.
Stakeholders
Browser vendors
App developers
Analysis
We can already see these different categories of webviews with the APIs available on the two big mobile platforms. Android offers a powerful webview API and Chrome Custom Tabs. iOS has WKWebView for a rich webview API and SFSafariViewController for a more browser-like experience embedded in native apps.
The webview APIs offer powerful features for example injecting JavaScript or other interactions with the pages loaded into the webview. These features require the designers of the webview APIs and app developers to think a lot about the security and privacy implications of their design choices. Webviews that allow the user to navigate the web freely need to be much more secure and restricted than webviews that just allow code under control of the app developer.
Webviews are used a lot to build the UI or core features of apps. These apps could benefit from more control over the native parts of the app or vice versa the native code might want to have more control over the web content.
The distinction between browser-like webviews and full webviews embedded into apps is the most obvious one but there are many more like we see with ePub and mini apps.
If there are different types of webviews with different use cases and feature sets app developers could benefit from more freedom or security and privacy. Browser vendors could roll out powerful features for developers of apps built around webviews but still keep the browsers and browser-like webviews secure.
Related W3C deliverables and/or work items
How is the issue solved in the Browser, and what’s more is needed?
Webviews and browsers currently always have the same features and restrictions. Different webview implementations share different APIs to interact with the webview content.