Meeting minutes
<ghurlbot> @TPAC
Present Heejin, Brady
Introduction
rayan: [reviewing agenda]
Rayan: I work for Google, co-chair of the group
AndrewC: Meta
SamW: Meta as well
QingAn: from Alibaba, co-chair with Rayan
Max: work for DuckDuckGo
Xiaoqian: from W3C, interesting intersection with WebApps WG
Wanming: work for Intel
Andy: work for MS on WebView2
<rayan> https://
Rayan: the goal of our group is identify and reduce issues arising from the use of webviews across platforms and devices
… the first phrase of the CG was exploratory - outreach to users and implementors of webviews to understand what usages are outthere
… and what issues arising from them
… we received submissions from the community and we agreed on a bunch of them
Introduction on CG report "WebView: Usage Scenarios and Challenges"
CG report "WebView: Usage Scenarios and Challenges"
loading a web page
Rayan: [reviewing document]
… one theme of issues is around performance given the additional cost of loading the rendering engine
… Improvements to these issues can be either through improvement to the Web platform features, or improvement to the webview ecosystem itself
Qing: adding support for existing browser features to the webviews would already help
Rayan: the inconsistencies in WebViews is a recurrent theme
Sharing requests and responses
Rayan: our second use case is about sharing requests and responses among webviews and the native side
… the different webview implementations are inconsistent on this; clearly another perf request
Andrew: there are situations where the native app has a lot more context than the browser context, solving this would be really useful
Rayan: the submitter of this for instance had AI used to predict future requests they woudl find useful to share with the WebView
Integrating webview & native components in a single layer
Rayan: the next use case is mixing webview & native components into a single layer
… e.g. allowing a native video player embedded in a webview
… this has been prototyped
QingAn: in China, mini-apps have a high need for mixing native comopnents & webview components
… ; currently they are many functionalities provided by the native side, but also using many web-provided components
… having a universal way to display the different components without overlap would help
… this is becoming more and more common, esp in the China market
… some vendors in China are trying to design proprietary solutions, both in iOS and Android
… but this is bringing different solutions across miniapp vendors
… this may be done either from the web side or from the webview side - that will be worth exploring
Brady: we have done this on Android and it wasn't pleasant - e.g. with text being obscured by audio controls
… it certainly is a problem that exists
QingAn: in the next steps, we can share more details about how we approached this issue
Inject custom JS
Rayan: by default, injnection is only possible at the top-level frame and with inconsistent behaviors across webviews
Max: all the desired features are available in one implementation or another, but no implementation has them all
… with all very different APIs
… there are also security & privacy concerns around this, but it solves a lot of problems that would otherwise require specialized APIs
… improving interoperability between platforms by discussing a common model
Rayan: re security & privacy - this is a challenge common to many other APIs that modify Web content being rendered
Control API permissions
Rayan: this provides a way to limit what 3rd party content can request access to, e.g. prevening a new article to request geolocation
Max: this can probably be split into different discussions
… in general, when a native app is using a Webview, there is a blurred line on the security boundaries and security model
… native has its own model to manage permissions
… and so does WebView, including the Permissions API
… in the case of our DuckDUckGo browser, we would like to have full control so that our app gets all the OS permissions and we then can manage permissions per web site
… permissions end up being managed very differently across the Web platform
Andy: from the webview2 perspective, the biggest usage is to "force allow"
… e.G. local font access requiring a permission prompt is awkward
dom: permissions model is a key point of integration between native and web
… we will have to distingusih the common model and what is allowed to be controled in what context
PeterC: it may be that auto-grant could be limited to domains that you control
Manage Web storage and cookies
Rayan: this is distinct from injection as you may need to inject cookies ahead of loading the Web page
… this again raises security challenges
… a question is the impact of third-party cookie removal on this issue
Max: it's related, but we also need to ability to selectively *not* clear cookies
… the privacy protections in our DDG browser are context-relative
… e.g. we would reduce the lifetime of a cookie both in 1st and 3rd party contexts
… we need more granular control
Dom: but deprecation of 3rd party cookies may reduce the scope of the privacy/security issue
Max: this type of more powerful features is really dependent on the type of app we're talking
… we build a full-featured browser, which should probably operate under different rules than others e.G. in app browser
Andy: we might want to frontload the types of webviews in our document
… since it impact use cases
rayan: good point
… I'll take an action to improve the doc structure in that direction
Origin in a WebView for locally hosted content
rayan: extremely common use case to load local content in a WebView
… but these are handled very differently across webview ecosystem with impact e.G. on CORS
… this feels like a low-hanging fruit for the CG to provide a standardized approach
… given how relevant it is and it should be relatively simple to spin up an explainer towards alignment
Different type of WebViews
Rayan: that was is more of an overview of the different webviews being available - still missing geckoview
… with information on the platform, the features it has, its limitations on how it can be used, and its UX flexibility
… we've classified those in 2 categories: full-fleged webview, and browser-like webviews
… the former used for full integration with native, when the latter is mostly around showing up a Web page via the browser
… most of our discussions have focused on the former
Slides of the WebView breakout, including an overview of the webview ecosystems
Andy: even if the browser webview isn't in scope, having these in mind is helpful to help differentiate the similar but slightly different use cases
rayan: +1
<QingAn> +1
Rayan: this doc has emerged from discussions in our CG which happens on biweekly basis
Andrew: is this limited to system-level webviews, or would this also include things like geckoview?
Rayan: we would like more info on geckoview, they're in scope
Dom: are there systematic difference between the two levels?
Andrew: they operate under different constraint
… system webviews get provided by default by the platforms
Open github issues
Display and manipulate third party content while blocking third party scripting #16
Brady: epub is essentially a Web site in a zip file
Brady: we cannot disable JS in the 3rd party content we load
… we disable network and put as many restrictions as we can
… but can't fully prevent it from running
… we would like to be able to say "this is HTML content, do not run any JS from that content, only run my JS"
… there are webplatform solutions to this, but given how the content is added to the webview, it's really hard to distinguish my safe content from the content of the 3rd party
… we have to manipulate the content extensively, which at the moment can only be done in JS
Rayan: have you looked into CSP?
Brady: I think this couldn't be within the current framework
dom: ideally we would provide a hook so that the content can then be handled through regular Web platform features
Rayan: sounds like a good topic to discuss with other webview vendors to reduce idiosyncracies across platform
Brady: APple has an ebook reader with similar issues iirc
Max: there was also another W3C group working on epub, focused on the package itself
Brady: right - the epub WG is platform agnostic, you would not have to use a WebView
Max: can you elaborate on the kind of scripts you want to be able to inject?
… in the existing JS injection use case there is a discussion about "isolated" world which may be relevant
Brady: it may well apply
… the scripts may for instance break the content into multiple pages
… change the size of the font (trickier than it seems)
… modify the default font
… change background/foreground colors
… caching some of the data (e.g. for pagination)
… media overlays - highlighting what is being read aloud
Max: lots of DOM manipulation then? if so, that seems related to the isolated world use case
Andrew: there seems to be lots of relation with webextensions
Max: the WebExtensions CG has this API to evaluate JS either in the context of the page or in an isolated world
… not impacted by CSP
dom: +1 in general to try & align with webextensions where possible, helps with convergence & interop
Challenge: Apps can use WebViews to bypass web security standards, privacy standards, and user choice. #36
Andy: overall concept is a challenge facing users more than developers
… how can they determine users understand what they're facing when using a webviews
Rayan: iframe are conceptually similar to webviews - embedded in a native app
… we have security models for iframe, it would make sense to have a security model for webview embeds
… they may benefit from similar considerations around 1st party/3rd party when it comes to powerful features
… these may come in conflict with the browser use case that we need to keep in mind
… there is also discussion of the X-Frame-Options header - that seems like a separate issue
Andy: I was listing this as a general indication of what has been in this space, not suggesting adopting it as is
… the concerns are very similar
… users won't know that there is an iframe that can be read by the wrapping app
… Webkit has app-bound domains which is an interesting approach in this space
… Alex Russel described a proposal to clarify policies from browser usage
Andrew: pushing back on the iframe similarities - in that situation, the Web is both the embedder and the embeddee in that situation
… X-Frame-Options doesn't really apply
… we wouldn't want to disable specific browsers
PEConn: Andy mentioned app-bound domains in iOS, Android has something similar
… is this something that should be standardized?
rayan: there has been attempts in that space, e.g. first-party-sets
… or the Web Apps "related apps" manifest hook
… one of the issue is with app-bound domains is that it needs stronger provable relationship
dom: there is a number of places where we should focus first on model before focusing on an interoperable technical surfacing of that model
rayan: +1
Andy: part of my position has been that we need awareness of the challenge, but it may not need to have a solution in this CG
Rayan: this is a challenge that intersects with a lot of the other issues we have
… it feels pretty critical to unblock some of the security & privacy discussions
Max: I don't think we're going to solve this issue right now
… there are multiple parts to this
… re x-frame-options - I'm not a fan of that, even in the Web world, it proves to be insufficient
… there are better and more flexible options in the Web world
… about app-bound domains, the problem that an app developer can choose "random" origins - it's similar to WebExtensions
… this issue has at least 3 parts:
… * a web site owner not wanting to be presented in a webview
… * giving the choice to the user of where the content be rendered
Andrew: +1 to Max
… wouldn't want to include this use case in our scope, it would prevent web-view based browsers
acomminos: +1 on breaking up the issue
… app-bound domains is a huge limitation for a full-fledge browser
dom: I think the idea is that app-bound domains is that they would be useful, but not for the "browser" use case
rayan: I think we all agree that app-bound domains wouldn't work for browsers
… I like the model of WebExtensions, with a carveout where
dom: what's our next step for #36? will be split it up?
Max: I'm happy to work on splitting it up
dom: what about #16?
Brady: I'll check if this the isolated world is a workable solution
type of usages
Andy: it would be interesting to make progress on the different type of usages à la miniapps, epub, in-app browser
… as discussed in #34
<ghurlbot> Issue 34 Clarification around Web Bundles, WebViews, and MiniApps? (aluhrs13)
Andy: a Venn diagram of how they relate one withanother
Chase: I'm working on webviews for isolated web apps
Qing: I haven't had the time to work on the mini-apps intro yet
… miniapps use webviews simply for rendering purposes
… the logic is similar to serviceworker to manage multiple webview pages
… the question about origin has also been discussed in the miniapps wg, with input from the TAG
… there is agreement that miniapps should follow the web security model, and we're trying to figure out related issues
Rayan: I'll ping the relevant people to make progress on this issue
… and restructure our doc to surface these questions
Discussion of next steps for the CG
Rayan: the CG has been in the exploratory phase
… is now a good time to dive into solution space?
… interested in opinions from WebView vendors - would this be interesting to get input from this CG?
Peter: would be happy to review things
Andy: 100% happy to give feedback; would be happy to consider prioritizing standardized solutions in this space
Rayan: so it would be useful to start iterating on solutions and reach out to other webview vendors
QingAn: +1
… our CG should still welcome more use cases and keep updating the CG report
… as we iterate on solutions, we should think about the potential standardization opportunities in W3C
dom: in terms of outreach, sharing our report with W3C WG chairs and relevant CGs (e.g. webextensions) would be useful
… keeping track of issues we identify in existing tech and deriving "best practices" to share with groups would be god
Rayan: QingAn and I will meet to organize our work to start solution space
QingAn: this should include update our charter to reflect this expanded scope
dom: +1