Meeting minutes
ghurlbot, use WebView-CG/usage-and-challenges
<ghurlbot> dom, OK
Review and discuss use cases
#12
<ghurlbot> Issue 12 Sharing HTTP requests/responses between Native & Webview (JohnRiv) use case, Agenda+
QingAn: this use case is about sharing http requests & responses between native & webview
… or use native as a proxy for the WebView
… I've described the scenarios associated with this usage
… 1st four are articulated around proxy with access control, firewall, ...
… the last one is more directly related to sharing request/response
Niklas: +1 to this use case - I've had to do this kind of native proxy to work around CORS issues
QingAn: +1 on this being a valid use case
… is there agreement on adding this to the document?
… any objection or further comment?
Rayan: using to bypass the CORS / security model for the Web shouldn't be something we push for
… we should maintain the privacy / security pillars of the Web
QingAn: could you comment to that effect in the issue?
dom: how would do e.g. a podcast app without overriding CORS?
rayan: I just want to make sure we discuss the situation rather than accepting CORS-override as a default
… there are alternatives that are worth documenting at the very least
… will bring it to the issue
#16
Brady: this comes up frequently in the digital publishing world
… we have 3rd party content from publishers or from users
… we want to display it in a WebView for rich display
… but we don't want any script to run - we don't want to have to trust them
… but we still want to manipulate the content (e.g. to change fonts, margins)
… which typically would be done through script injection
… you can't turn off JS to run yours, but you don't want to run the 3rd party JS
dom: wouldn't Content Security Policy enable this?
Brady: maybe, I don't know
… our approach has been to remove as much as JS as we can, but that's never going to be perfect
dom: we should add Content-Security-Policy to the related W3C deliverables
brady: a solution that I like is exposing the DOM & CSS OM to native code so that I don't have to write JS - but probably lots harder to do
QingAn: I think Android and iOs have private interfaces to achieve this
dom: another approach might be to hook Subresource Integrity to control tightly which scripts get executed
QingAn: a similar issue has been brought up in the context of mini apps
… I'll ask some miniapps folks to chime in with their use cases in the issue
Rayan: supports this as a valid use case
… +1 to Dom that CSP can support this
QingAn: is CSP supported in WebViews?
Rayan: it should be in Android at least
QingAn: Mini-Apps use OS WebViews and other customized views; some miniapps vendors do not support CSP through their webviews
Rayan: this also relates to Web Platform compat in WebViews
#17
<ghurlbot> Issue 17 Render WebView Components and Native Components in same layer (QingAn) use case, Agenda+
QingAn: it's common for hybrid & mini apps to mix native and WebView component, e.g. many hybrid apps prefer to use their native video component for better performance
… this means the rendering is done by the native app instead of the webview
… this enables more features due to the native abilities
… but it creates rendering issues for developers
… e.g. z-index property can't be applied to the native component
… it would be good if the native component could be rendered in the same layer as the webview instead of a different layer
… e.g. with the native component treated as a DOM node that could be better controlled by the developer for layout
… there are private solutions that address this problem e.g. by mini-apps vendors
… having a solution provided directly by default webviews would help
… this is a widely encountered issue in the miniapps world
Rayan: hybrid merging of layers feels more like an OS feature than a WebView feature
… is the proposal to make the native component part of the DOM?
QingAn: yes
… when we start looking at solutions, I can share how miniapps deal with this through private solutions
Rayan: that would be very interesting
<QingAn> ?
#7
<ghurlbot> Issue 7 What is the "Origin" in a WebView, for locally hosted content? (lrosenthol) Agenda+
Niklas: I've worked with Apache Cordova; Android and iOS have different approaches to using local content
… it used to be that you would use file:///
… but to help with dealing with cross-origin, they introduced two different approaches
… iOS uses a custom:// scheme, where Android uses a custom domain name
… having a unified approach would help
QingAn: are you suggesting a standardized URI scheme for this?
Niklas: yes
QingAn: would locally hosted content considered secure? or are there security risks associated with it?
Niklas: in the context of Apache Cordova, you're in full control of the content that gets shipped through app store
… from my experience, it should be safe
Rayan: +1 - it should be considered as first party
… having the ability to standardize its origin would hlep
s/help
QingAn: +1
… should we suggest a standardized scheme for locally hosted content in the solution space?
[room: yes]
QingAn: should we merge this with #15?
<ghurlbot> Issue 15 Third party cookies and cross origin ressource sharing in webviews (NiklasMerz) use case
Niklas: #15 is a derivative - we should probably focus on #7 for now
<ghurlbot> Issue 7 What is the "Origin" in a WebView, for locally hosted content? (lrosenthol) Agenda+
QingAn: could you add use cases to #7 then Niklas?
dom: having a well-defined origin will also help with using CSP for third-party filtering
#10
<ghurlbot> Issue 10 UserScript injection in WebView (Token-LiMing) use case
Qing: we can close this issue
AOB
Dom: the Winter CG (Web Interoperable Runtime) CG launched recently, with possibly some overlapping interests
Dom: also TPAC schedule has been announced, including our meeting slot for WebView CG
Draft of WebView: Usage Scenarios and Challenges
QingAn: currently only one use case, will add others we've agreed on
… building up for something to share at the upcoming TPAC