Meeting minutes
Review and discuss use cases
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
What is the "Origin" in a WebView, for locally hosted content? #7
Qing: I've created a pull request (#25) to add the use case to the doc
<ghurlbot> Pull Request 25 Merge use case of issue 7 (QingAn)
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
Qing: Will have to skip since Brady isn't around
#19
<ghurlbot> Issue 19 Define different types of webviews (NiklasMerz) use case, Agenda+
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> Issue 20 Inject custom JS scripts (muodov) use case, Agenda+
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> Issue 23 Control API permissions (muodov) use case, Agenda+
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
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> Issue 24 Manage web storage and cookies (muodov) use case, Agenda+
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