- 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