[minutes] TPAC meeting Sep 16


The minutes of our WebView CG Meeting during TPAC on Sep 16 are 
available at:

There was a related breakout organized on September 14:

Both these minutes are copied as text below.



                             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


           AndrewCumming, AndyLhurs, ChasePhilips, Dom, duga,
           hjrchung, Max_Tsoy, PeterC, QingAn, Rayan, SamWeiss,
           shiestyle, Tatsuya, Tatsuya_Igarashi, wanming_lin,
           WanmingLin, xiaoqian


           qing_an, rayan



     1. [4]Introduction
     2. [5]Introduction on CG report "WebView: Usage Scenarios and
          1. [6]loading a web page
          2. [7]Sharing requests and responses
          3. [8]Integrating webview & native components in a single
          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


    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
    … some vendors in China are trying to design proprietary
    solutions, both in iOS and Android
    … but this is bringing different solutions across miniapp
    … 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

    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

    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
    … 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
    … since it impact use cases

    rayan: good point
    … I'll take an action to improve the doc structure in that

     Origin in a WebView for locally hosted content

    rayan: extremely common use case to load local content in a
    … 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


    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
    … 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
    … 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.
    … 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

    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

    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

    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

     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
    … 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.

       [3] https://www.w3.org/2022/09/14-webview-cg-irc


           AndyLhurs, Brady, brwalder_, cmp, DavidHall, Dom,
           gpellegrino, PatrickMeenan, PeterConn, QingAn, Rayan,


           An_Qing, Rayan_Kanso



     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

    <cmp> Thanks for fixing the Zoom call

    <Andy_Luhrs> Yep, I'm in

    Rayan: different people will have different definitions of a

    Peter: will share perspective on webviews ecosystem across
    … Android has Android WebView, iOs has WKWebView, and Windows
    has WebView2
    … android webview allows to display web content in a native
    … 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
    … Custom Tabs are different, they launched the page in a
    browser, with only limited interaction between the app and Web
    … 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
    … What isn't a custom tab?
    … it isn't a single implementation - it's based on the user's
    … 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

    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
    … 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
    … 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
    … 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/


    <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://


    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
    … 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