Meeting minutes
Locally hosted content #2
Niklas: this is a proposal to find a common denominator across webviews to expose local content to WebViews - based on what's in iOS and Android
… right now, the different implementations have different limitations, different choices (e.g. origins)
… having a single API would benefit developers
Rayan: seen feedback; most of it around origins
Discussions around the explainer
Rayan: how would the app affect the origin? would app Foo be a different origin from app Bar?
… myapp://
Niklas: they would be different origins
Rayan: Android today treat these as different origins
Niklas: OK, so it's worth clarifying in the explainer
Rayan: there is also ongoing work to standardize custom schemes
Intent to Ship: Support URLs with non-special schemes
Rayan: there seems to be alignment with GeckoView and Webkit behind this proposal
Rayan: assuming there is convergence, does that affect your preference on option 1 vs option 2?
Niklas: not really; with HTTPS, you can use CSP / CORS and get more Web foo
Rayan: a lot of the considerations also need to take into account how Web site to work; at the moment with custom schemes, CSP / CORS will break
… that's an important consideration for this API
… my hesitation with HTTPS, it doesn't feel right to use it to serve your own content
dom: I wonder if we could use a magic HTTPS origin à la localhost
Rayan: what happens if you have a custom scheme and want to load resources? do you rely on the interception API?
Niklas: in iOS, any request on that custom scheme gets intercepted (usually a simple mapping to the filesystem)
Rayan: any impact on performance / latency?
Niklas: this hasn't been an issue in the apps I've worked on
Dom: where would we go next after we converge on these discussions?
Rayan: there is interest on Android WebView once there is more clarity on https vs custom schemes
… Andy from the Windows webview is also participating in the discussions
Niklas: I'll ping my contacts on WebKit webviews
Controlled Frame explainer FYI and review
Rayan: this is a WebView for the Web
… different fenced iframe, only available for isolated web apps
… it comes with guarantees - it runs outside of the context of the embedding web app, works as if it was a top level context
… there is exploration to provide WebView-like APIs to control web content
… hence the intersection with our CG
Rayan: they're seeking feedback on the explainer from the CG
Qing: this is only for isolated web apps - not for hybrid apps?
Rayan: correct - it wouldn't work on any web site
… only for isolated web apps where resources are packaged in a web bundle
Niklas: I used to work on a Web app that used iframes extensively for a widget system
… it would be cool to have full control over the embedded pages when combine frames in your main app
… I need to get a better understanding of isolated web apps
Rayan: the explainer details how it differs from iframes and why it is necessary
AOB
Rayan: there is ongoing work on a device attestation API - which is particularly useful for WebViews
… e.g. a banking app wanting to ensure they're running on a non-compromised device
… it relies on a trusted source that gives signed tokens on whether the device has been root, whether the app is trusted, etc
… expect an explainer coming in this space to the CG
Dom: may be worth surfacing that use case in our usage doc
Rayan: note that this would be a Web Platform feature, not just for WebViews - it has utility in anti-fraud contexts
… but let's wait to see the explainer when we can react with a more detailed proposal
Niklas: looking forward to this, in particular a clearer sense of the use cases