- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 26 Jul 2022 17:08:06 +0200
- To: public-webview@w3.org
Hi,
The minutes of our WebView CG call held today (July 26) are available at:
https://www.w3.org/2022/07/26-webview-minutes.html
and copied as text below.
Dom
WebView CG
26 July 2022
[2]Agenda. [3]IRC log.
[2]
https://www.w3.org/events/meetings/a329378b-e308-4930-8c45-c33691570d96
[3] https://www.w3.org/2022/07/26-webview-irc
Attendees
Present
AndyLuhrs, BartoszGalek, Dom, Francois, JohnRiviello,
MaxTsoy, NiklasMerz, QingAn, Rayan, ThomasSteiner
Regrets
-
Chair
QingAn, Rayan
Scribe
dom
Contents
1. [4]Review and discuss use cases
1. [5]What is the "Origin" in a WebView, for locally
hosted content? #7
2. [6]#16
3. [7]#19
4. [8]#20
5. [9]#23
6. [10]#24
2. [11]Next meeting
Meeting minutes
[12]Review and discuss use cases
[12]
https://github.com/WebView-CG/usage-and-challenges/issues?q=is:issue+is:open+label:Agenda+
Qing: we're planning to publish a stable version of the use
cases document for TPAC and take advantage of TPAC to share it
more broadly
Qing: today we'll continue our discussions on the issues
[13]What is the "Origin" in a WebView, for locally hosted content?
#7
[13] https://github.com/WebView-CG/usage-and-challenges/issues/7
<ghurlbot> [14]Issue 7 What is the "Origin" in a WebView, for
locally hosted content? (lrosenthol) use case, agreed use case,
Agenda+
[14] https://github.com/WebView-CG/usage-and-challenges/issues/7
Qing: I've created a pull request (#25) to add the use case to
the doc
<ghurlbot> [15]Pull Request 25 Merge use case of issue 7
(QingAn)
[15] https://github.com/WebView-CG/usage-and-challenges/issues/25
Niklas: thanks for integrating my feedback in the PR
… I come from the mobile perspective - there may remain input
from e.g. the epub perspective
Qing: I've asked for further input on that; maybe we can merge
this after one or two more weeks of feedback
Andy: I can contribute the desktop perspective here if useful -
coming from Microsoft
Qing: absolutely! additional comments / suggestions, and
additional github issues would be welcome
#16
<ghurlbot> [16]Issue 16 Display and manipulate third party
content while blocking third party scripting (bduga) use case,
Agenda+
[16] https://github.com/WebView-CG/usage-and-challenges/issues/16
Qing: Will have to skip since Brady isn't around
#19
<ghurlbot> [17]Issue 19 Define different types of webviews
(NiklasMerz) use case, Agenda+
[17] https://github.com/WebView-CG/usage-and-challenges/issues/19
Qing: this was brought up in our last meeting
Niklas: I summarized a list of webviews and their capabilities
- this could provide a good start for discussions
… this is also coming from the mobile perspective, could use
some desktop perspective
andy: will be happy to add the desktop perspective
Max: +1
… we at Duck Duck Go, we're working WebView2 and it definitely
deserves its own section
… there is also GeckoView - not sure if Mozilla is
participating in this group, may be interesting to reach out to
them
Qing: this will prove useful to categorize our use cases as
input to WebViews vendors
… having input from vertical use cases (e.g. ecommerce) on how
these webviews apply to their scenarios
#20
<ghurlbot> [18]Issue 20 Inject custom JS scripts (muodov) use
case, Agenda+
[18] https://github.com/WebView-CG/usage-and-challenges/issues/20
Max: Rayan raised the question about injecting scripts play
with the security model
… there is an emerging agreement that injecting JS is important
and many products rely on this
Qing: the main controversy is around 1st vs 3rd party content
injection
… Max, you provided examples of where injecting 3rd party
scripts is useful
Max: I'm not sure we should talk about 3rd-party
… the script is embedded by the app itself
… the examples I give are based on real-life usage
… there are platform-specific limitations: in webkit webview,
injected scripts are isolated from the page script
… this exists in Chrome extensions, but not in Android WebView
… Another limitation is that sometimes you can't inject scripts
in every context
… e.g. 3rd party iframe nested inside the page, in Android
WebView the native app can't inject scripts there
… for us DDG, this is a big limitation to our injected privacy
protections
… whereas this is possible in WebView2
… there is inconsistent features provided across platforms
… which I think can be improved
dom: +1 on not describing these as 1st vs 3rd party - injected
scripts are part of the UA in this example
… we should identify if the different limitations across
platforms are based on different policies (vs just bugs)
… if they are different policies, it would be useful to
document them, and possibly see if we can create directions for
these policies to converge on
… e.g. based on the type of use cases (e.g. any-content browser
vs specific-content rendering)
Rayan: JS injection can't be available in all webview platform
- e.g. customtab that integrate with the existing browser
storage
… in contexts that allow for it, it makes sense to offer this
consistently across environments (e.g. service worker)
… security concerns is a reason for limiting what can be
injected
… which varies hugely across use cases
… definitely need to inject everywhere for a browser, but not
quite so if you're only rendering 1st party content
Max: it would be useful to have an analysis of that perspective
and what specific issues arise from this
… also, is it a blocker to add this to our report?
Rayan: not a blocker - but that's a key issue for us to discuss
… e.g. signing via a webview shares the credential with the
host app
… there are ways for apps to declare which origins they're tied
to
Andy: WebView2 has a drastic different attack surface than
Android - once you can run an executable on Windows, injecting
JS is the least of your worries
dom: +1 on tying use cases with specific security policies -
e.g. if you ask "UA-type delegation" (with gives full script
injection) you would likely get additional scrutiny in app
store review on Android
Rayan: in any case, +1 on merging this as a valid use case
Qing: we'll label it as such
#23
<ghurlbot> [19]Issue 23 Control API permissions (muodov) use
case, Agenda+
[19] https://github.com/WebView-CG/usage-and-challenges/issues/23
Max: this was a follow up to another issue - the use case is
that sometimes you want to control more granuarly what kind of
permissions are granted to web content
… for cases where a browser would prompt user content (e.g.
geolocation, camera, screen capture)
… this is limited across platforms, and inconsistent
… ideally, we would like to see some way to control this - via
events when something happens, or an API to read the current
state (whether permission has been granted or not)
… or program control on permission states
… For our case (a browser), we would want to replicate what
other browsers can do - with a UI to manage permissions, react
to prompts, etc
Andy: e.g. the local font API is restricted in a browser
context, but doesn't need these restrictions in a native app
… overall, 3 issues in WebView2: we have to play catch up with
the permission spec as it evolves
… we had to go beyond "granted" / "deny", with "in use" or with
screen sharing bringing additional complexity
dom: so we would need a more unified model of these underlying
considerations - they aren't unified today since they're not
exposed directly to Web developers in a browser context
Andy: probably
Max: maybe WebView could adopt the same underlying model in
permission spec
Andy: there is a permission registry emerging that lists the
various axes of complexity
[20]Permissions Registry
[20] https://w3c.github.io/permissions-registry/
Qing: I'm hearing agreement this is a valid use case
Andy: +1
<dom> Dom: +1
Rayan: +1 - it also deals with the OS permission integration
Qing: Does that extend to hybrid apps, beyond in-app browser?
andy: I have hybrid app use cases
#24
<ghurlbot> [21]Issue 24 Manage web storage and cookies (muodov)
use case, Agenda+
[21] https://github.com/WebView-CG/usage-and-challenges/issues/24
Max: (I still have a few more issues to file)
Max: this one is about dealing with cookies & web storage
… our browser has a lot to do with privacy protections for
which cookies & web storage are essential
Andy: accessing the value of cookies is debatedly worse than
injecting JS - stealing cookies can enable impersonating
… is this a similar threat to the one we discussed earlier with
Android WebView?
Rayan: this is indeed doable with Android WebView at the moment
… cookies aren't persisted at the moment, which is somewhat a
mitigation
… this is another case of an API that should be tied to a
specific set of use cases
Niklas: iOS can have a shared cookie storages across native
http requests and webviews
Max: the DDG engineers liked a lot the cookie manager in
WebView2
… I can add more details, but not sure it's needed to determine
whether this is a valid use case
… the 3 points I've put in the document are probably the most
significant bits
… Any specific details you would like to see added?
Qing: any input on whether to accept it as is?
Andy: I think the baseline use case is ability to clear cookies
(e.g. to logout/wipe data)
… another typical need is when auth is done in the native app
and want to share a secret for future interactions through
their webview
… without sharing it with other webviews
Qing: we can try to define a more granular set of cookie
management operations (clear, update/modify)
… as a preliminary step before making a decision on the use
case
max: I can take stab at our needs from a DDG perspective if
that helps
Next meeting
Qing: on Aug 9 at 7am UTC
… if all goes well, we can have our stable report by end of
August
Received on Tuesday, 26 July 2022 15:08:28 UTC