- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 19 Sep 2022 15:44:59 +0200
- To: public-webview@w3.org
Hi,
The minutes of our WebView CG Meeting during TPAC on Sep 16 are
available at:
https://www.w3.org/2022/09/16-webview-minutes.html
There was a related breakout organized on September 14:
https://www.w3.org/2022/09/14-webview-cg-minutes.html
Both these minutes are copied as text below.
Dom
----
WebView CG @TPAC
16 September 2022
[2]Agenda. [3]IRC log.
[2] https://github.com/WebView-CG/usage-and-challenges/issues/35
[3] https://www.w3.org/2022/09/16-webview-irc
Attendees
Present
AndrewCumming, AndyLhurs, ChasePhilips, Dom, duga,
hjrchung, Max_Tsoy, PeterC, QingAn, Rayan, SamWeiss,
shiestyle, Tatsuya, Tatsuya_Igarashi, wanming_lin,
WanmingLin, xiaoqian
Regrets
-
Chair
qing_an, rayan
Scribe
dom
Contents
1. [4]Introduction
2. [5]Introduction on CG report "WebView: Usage Scenarios and
Challenges"
1. [6]loading a web page
2. [7]Sharing requests and responses
3. [8]Integrating webview & native components in a single
layer
4. [9]Inject custom JS
5. [10]Control API permissions
6. [11]Manage Web storage and cookies
7. [12]Origin in a WebView for locally hosted content
8. [13]Different type of WebViews
3. [14]Open github issues
1. [15]Display and manipulate third party content while
blocking third party scripting #16
2. [16]Challenge: Apps can use WebViews to bypass web
security standards, privacy standards, and user
choice. #36
3. [17]type of usages
4. [18]Discussion of next steps for the CG
Meeting minutes
<ghurlbot> [19]@TPAC
[19] https://github.com/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> [20]https://webview-cg.github.io/usage-and-challenges/
[20] https://webview-cg.github.io/usage-and-challenges/
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"
[21]CG report "WebView: Usage Scenarios and Challenges"
[21] https://webview-cg.github.io/usage-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
[22]WebView Breakout minutes
[22] https://www.w3.org/2022/09/14-webview-cg-minutes.html
[23]Slides of the WebView breakout, including an overview of
the webview ecosystems
[23]
https://drive.google.com/file/d/19-3Q54IZEKpjb_dXgNSeT_xyjSSnVute/view?usp=sharing
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
[24]Open github issues
[24] https://github.com/WebView-CG/usage-and-challenges/issues
[25]Display and manipulate third party content while blocking third
party scripting #16
[25] https://github.com/WebView-CG/usage-and-challenges/issues/16
Brady: epub is essentially a Web site in a zip file
<ghurlbot> [26]Issue 16 Display and manipulate third party
content while blocking third party scripting (bduga) use case
[26] https://github.com/WebView-CG/usage-and-challenges/issues/16
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
[27]Challenge: Apps can use WebViews to bypass web security
standards, privacy standards, and user choice. #36
[27] https://github.com/WebView-CG/usage-and-challenges/issues/36
<ghurlbot> [28]Issue 36 Challenge: Apps can use WebViews to
bypass web security standards, privacy standards, and user
choice. (aluhrs13) use case, Agenda+
[28] https://github.com/WebView-CG/usage-and-challenges/issues/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?
<ghurlbot> [29]Issue 36 Challenge: Apps can use WebViews to
bypass web security standards, privacy standards, and user
choice. (aluhrs13) use case, Agenda+
[29] https://github.com/WebView-CG/usage-and-challenges/issues/36
Max: I'm happy to work on splitting it up
dom: what about #16?
<ghurlbot> [30]Issue 16 Display and manipulate third party
content while blocking third party scripting (bduga) use case
[30] https://github.com/WebView-CG/usage-and-challenges/issues/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> [31]Issue 34 Clarification around Web Bundles,
WebViews, and MiniApps? (aluhrs13)
[31] https://github.com/WebView-CG/usage-and-challenges/issues/34
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
----
WebViews - Usages & Challenges - TPAC 2022 breakout
14 September 2022
[2]Agenda. [3]IRC log.
[2]
https://www.w3.org/events/meetings/93376b45-77db-4261-8183-bc4721ae10b2#agenda
[3] https://www.w3.org/2022/09/14-webview-cg-irc
Attendees
Present
AndyLhurs, Brady, brwalder_, cmp, DavidHall, Dom,
gpellegrino, PatrickMeenan, PeterConn, QingAn, Rayan,
Tove
Regrets
-
Chair
An_Qing, Rayan_Kanso
Scribe
dom
Contents
1. [4]WebView Status USage and Challenges
2. [5]WebView Challenges
Meeting minutes
Rayan: we'll discuss the WebView CG, give an overview of the
webview ecosystem and give a perspective on usage and
challenges of WebViews
<Andy_Luhrs> Is the Zoom call working? I'm seeing "The host has
another meeting in progress"
<brwalder_> I'm having trouble joining the Zoom meeting
Rayan: the WebView CG was launched a few months ago to identify
usages of WebView across platform, identify issues that emerge
from it, and how they could be addressed, while raising
awareness
<cmp> Thanks for fixing the Zoom call
<Andy_Luhrs> Yep, I'm in
Rayan: different people will have different definitions of a
WebView
Peter: will share perspective on webviews ecosystem across
platforms
… Android has Android WebView, iOs has WKWebView, and Windows
has WebView2
… android webview allows to display web content in a native
apps
… doesn't come with chrome or navigation controls
… 80% of android app use a WebView of some sort
… a WebView doesn't have an address bar, fancy browser feature
(e.G. autofill), or doesn't have all web platform features
… in some cases these features don't fit well in a native
context (e.g. the push api)
<Joe_M> Can the presentation link be put in the chat? It's a
bit hard to see from the back.
Peter: they're not isolated browser context - the embedding app
can see and modifty everything
… they're not a comprehensive toolfit to build browsers
… Using WebView Beta you can highlight WebView usage with a
yellow background - helps identify their usage in many native
apps
… Custom Tabs are different, they launched the page in a
browser, with only limited interaction between the app and Web
content
… The Custom Tab provides a middle point between launching a
complete separate browser (which can create a distracting UX)
and using a WebView to render any Web content (given the
limitations of WebView in terms of features support and
security)
… What isn't a custom tab?
… it isn't a single implementation - it's based on the user's
browser
… it dpoesn't allow tight integration with native
… may be a bit confusing for users on whether they're in the
app or the browser
… Android WebViews and Custom Tabs are at the extremities of a
spectrum of Web/Native integration
@@@: is a custom tab always fullscreen or can it appear along
the native app?
Peter: we're looking into allowing experimentally for
half-screen
khushalsagar: not losing the context of the native app can be a
motivation for using WebView
Peter: on iOS there is WKWebView very similar to android
webview
… WKWebView have app-bound-domains sinec Sep 2020, that allows
to set a webview for a tight integration for up to 10 domains
… right now, an opt-in, without technical control on what web
sites you claim integration with
… There is also SFSafariViewController, which is similar to
Custom Tab
… recommended to load content you don't load
… for Web views on Windows, there is WebView2 similar to
android and iOS webviews
WebView Status USage and Challenges
Rayan: reviewing some of the outcomes of the community group
[6]WebView: Usage Scenarios and Challenges
[6] https://webview-cg.github.io/usage-and-challenges/
Rayan: we're meeting on Friday if you want to join our
dsicussions
… Among our finding is a classification of webviews into 2
categories, "fully-fledged" vs "browser-like", along to what
Peter described
… the latter usuallly have a simpler use case - content you
don't own, so we focused on the former
… (suggestions on better names are welcome)
… 1st use case is around hybrid apps
… either Web apps packaed as native apps
… and in-app browsers
khushalsagar: why using packaged apps vs a PWA?
Rayan: usually to get more control
Rayan: Another use case is browsers - like the DuckDuckGo
browser
… for an opiniated browser
… Another use case is also mini apps and super apps - for which
there is a dedicated CG
… many more: advertising, epub readers
WebView Challenges
Rayan: many identified challenges
… one theme is performance: when using a webview, it creates
latency for launching
… you may also want to pre-cache content to accelerate loading
… solutions could come either from the Web platform (through
e.g. servier worker) or from the native side
… Integration of native components also falls in that category
… Another theme is inconsistencies
… WebViews don't have uniform support of Web platform features
… locally hosted content get handled differently across Web
views (e.g. in terms of origins)
… JS injection, network interception, degguability tend not to
be consistent either
… Last theme is around control: toggling features, permissions,
3rd party resources
… This tends to be controversial given security & privacy
concerns that can arise from them
… Please join the WebView CG
<masaki> Could you share the slide URL?
<rbyers> [7]https://drive.google.com/file/d/
1lqUnum9Pbd8wGPjlPZ_Lqbb_HTsMcEeR/view?usp=sharing
[7]
https://drive.google.com/file/d/1lqUnum9Pbd8wGPjlPZ_Lqbb_HTsMcEeR/view?usp=sharing
<masaki> Thanks!
Reilly: in Chromium, we have an HTML tag implementation that we
are in the process to write an explainer for
… the Web embedding itself would be a useful exercise to
identify potential usages and issues
Rayan: definitely useful to consider
BenS: you mentioned app-bound domains - any plans to do
something similar in Chrome?
Rayan: we're looking into it
dom: intersections between native policies and limiting
security exposure will be part of the next phase of the CG
Rayan: definitely expect to see work in that space emerging
Brady: is there participation from other vendors?
<PEConn> Slides with the links working this time: [8]https://
drive.google.com/file/d/19-3Q54IZEKpjb_dXgNSeT_xyjSSnVute/
view?usp=sharing
[8]
https://drive.google.com/file/d/19-3Q54IZEKpjb_dXgNSeT_xyjSSnVute/view?usp=sharing
Rayan: we have participation from Microsoft so far
Jason: I'll see if we can get Mozilla involved
khushalsagar: what about weblayers?
rayan: weblayers is experimental, provides a full-fledged web
view
… it adds better support for more web platform features
… it doesn't come with any particular restriction
Received on Monday, 19 September 2022 13:45:03 UTC