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