<dom> Slideset: https://
Dom: Goal is to identify what role W3C should play in making WebViews work better for the web
… WebViews are used in native apps to render web content
… W3C develops browser technology that is also used in WebViews. I think they do matter. More than 10% of web content is rendered in web views
… Looking at the MiniApp ecosystem, webviews are a critical part
… WebViews not only matter, but are critical to the future of the web
… WebViews enable web technologies to have a bigger impact, and more reach
… Story may be less positive in practice
… Security, e.g, spectre attack, browsers have been rearchitected, but this protection isn't available in WebViews
… End user privacy protection
… Also they don't work with browser-specific UI such as permission prompts
… I was surprised at how much content is rendered through WebViews. There may be little awareness among web developers that their content would be rendered in a WebView
… Automated tooling, testing, documentation
… , Why are WebViews popular in native apps? One use case is rendering ads
… Simpler to reuse existing web infrastructure, so many ad networks recommend using WebViews
… If you already have web content and you want to have a native app
… Federated login is simpler to enable in a WebView, but this brings questions about security and privacy and data storage
… In-app browsers integrated into apps such as Facebook and Pinterest
… Embedded systems such as TV sets
… WebViews on Android doesn't have shared storage, for example. The CustomTab and Trusted Web Activity approach delegates rendering to the actual browser on the platform
… It's similar on iOS. WebViews not recommended for general web content. There's a dedicated WebView for web-based authentication
… It's a complex space for developers to navigate
… There's also WebView usage on Desktop, e.g., the Electron framework
… In conclusion, intersection with W3C work: W3C launched the MiniApps WG this year. Active W3C work on improving web advertising
… May need a discussion with groups that use native UI such as permission prompts
… Web developers may not be aware of webviews. Would a Content Security Policy approach help?
… WebViews creates a new stakeholder, security and privacy that are assumed in browsers
… What are potential next steps? Is further discussion needed?
… We could launch a Community Group, liaise with existing Working Groups
… We could organise a workshop. It's a rich and complex space with lots of use cases and intersection with W3C work
… So longer discussion in a workshop could help
… I welcome any other suggestions you might have
Andre: I'm a devrel engineer at Google, working on web on Android
… With Chrome Custom Tabs the goal was to get apps using the system browser. It was successful to some extent
… But a small number of big apps still prefer to use WebView. They know the user intent when linking to web content
… Should we have different use-case specific groups?
… TV-specific apps. Some use WebView. YouTube has Cobalt, which is based on v8 and Blink, a different technology
Dom: I agree, splitting by use case could be valuable
Alan: We're one of the bigger organisations using WebViews. We have two big use cases. A semi super-app, an app that opens services in a webview. Most of our web services use that approach
… The other use cases is stand-alone apps that use WebViews. They're updated on a different period than the application, so the WebView content can be updated more regularly
… Also login integration
Dom: In the first category, super-apps. Are you hosting third party content?
Alan: It's both, e.g., our news app is an integrated WebView. But we also integrate a maps services as a MiniApp, branded differently to the in-house content
Andre: In the super-app use case, is the content hosted by you or the third party? Is there a verification or validation step for the miniapp?
Alan: For the most part, the things we host the content we develop in-house, and third parties host their content
Michael: A suggestion for how to focus this work: need to keep in mind solving user problems, so need to identify what the problems are and document them
… There's a lot of usage of WebViews for different purposes. How can we best solve some of the problems?
… Messaging clients, such as LINE? It's for messaging, playing games, reading news, e-commerce, entertainment
… Similar to Facebook Messenger and WeChat
… Problem areas: identity in the super-app. The user of the super-app doesn't have access to the identity information in the system browser
… So when the user follows a link to the news site, the WebView isn't aware of their identity
… Can we figure out a way to securely share identity information?
… Also payment credentials, expose from system browser to the super app
… In-app purchases, e.g., in games. Its difficult to discover games, then users can't get push notifications or access their social graph
… The user has information in the system browser, need to expose it into the super-app hosted WebView
… Suggest focusing on those big user problems
Dom: The web has gained operating system level integration with WebViews, how to rearchitect browsers to expose other aspects beyond rendering (data storage, identity management)?
Michael: Security or privacy issues with making platform data available to WebViews?
… Can't only solve through technical solutions. Needs changes from platform providers such as Android and iOS
<dom> Hobson's Browser - How Apple, Facebook, and Google Broke the Mobile Browser Market by Silently Undermining User Choice
Michael: Read Alex Russell on this
… It's going to require engagement with Apple and Google on what's best for users
… They way you can contribute, if you're not technical, is in this area
Andre: Agree with that. At Google we've been thinking about identity and payments
… When users navigate a link in an in-app browser, are they aware and do they trust the super-app?
… User's aren't given choice of whether the in-app browser or the system browser is used
… Some users prefer to keep their browsing history separate, some prefer to keep it all together, but users aren't given a choice
… We should include those who build those experiences, such as Facebook and Pinterest
Dom: So it's not just a technical question, also policy and business considerations
… We can focus on user pain points. Is this something W3C should work on, e.g., in a workshop or Community Group?
<pchampin> +1 to have W3C work on this
Michael: I think a CG is a good idea. Not sure we need a workshop, as they take a lot of time to prepare
… Community Groups are quick to create, doesn't require anybody's permission as it's community-driven
… W3C dedicates staff time to Working Groups, but not for all Community Groups
… If the CG is aligned organisationally with W3C we dedicate staff time, so we may get management support for that
… We'd need someone willing to chair the group
… If people are interested, we can help explain what's involved
Dom: There's some interest from participants. Any comment on the MiniApp ecosystem?
… (no comment)
Chris: in the media & entertainment IG, there is some interest in miniapps
… or the kind of super-apps/Webviews approach for TV apps
… this might be an area we would like to explore
… incl things like cobalt
… our industry would be interested in that certainly
Qing An: We have interest in WebView. There are lots of things we need to enhance, I'm curious about the direction in W3C. Is the direction to enhance WebView capability to bring better performance?
Dom: We seem to have converged on launching a W3C Community Group that focuses on reviewing where webviews are used, and pain points
… In terms of better performance or native integration, the CG could also look at that
Qing An: We've identified several issues from our implementation experience. Native app functionality provided by the webview, we're doing that now on the native app side
Dom: After TPAC I can look at setting up a CG. Get in touch if you're interested. We'll also run this session later in the week
… Thank you all