├── .github └── ISSUE_TEMPLATE │ └── use-case---issue-template.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── images ├── Load-Native-Page.gif ├── Load-WebView-Page.gif ├── Procedure-of-loading-a-webview-page.png ├── With-same-layer-rendering.png └── Without-same-layer-rendering.png ├── index.html ├── meetings ├── 1st-meeting-agenda-20220420.md ├── 2nd-meeting-agenda-220511.md ├── 3rd-meeting-agenda-220525.md ├── 4th-meeting-agenda-220608.md ├── 5th-meeting-agenda-220706.md ├── 6th-meeting-agenda-220727.md ├── 7th-meeting-agenda-220809.md └── 8th-meeting-agenda-220823.md ├── use_case&issue_template.md └── w3c.json /.github/ISSUE_TEMPLATE/use-case---issue-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Use case & issue template 3 | about: Describe this issue template's purpose here. 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Use case name 11 | 12 | ## Submitter(s) 13 | 14 | ## Motivation 15 | 16 | ## Stakeholders 17 | 18 | ## Analysis 19 | 20 | ## Related W3C deliverables and/or work items 21 | 22 | ## How is the issue solved in the Browser, and what’s more is needed? 23 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # WebView Community Group 2 | 3 | This repository is being used for work in the W3C WebView CommunityGroup, governed by the [W3C Community License Agreement (CLA)](https://www.w3.org/community/about/agreements/cla/). 4 | 5 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All Reports in this Repository are licensed by Contributors 2 | under the 3 | [W3C Software and Document License](https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document). 4 | 5 | Contributions to Specifications are made under the 6 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/). 7 | 8 | Contributions to Test Suites are made under the 9 | [W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html) 10 | 11 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # usage-and-challenges 2 | Documenting usage scenarios for WebView and the challenges they create 3 | -------------------------------------------------------------------------------- /images/Load-Native-Page.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebView-CG/usage-and-challenges/22f8f3479c9e3c4ca07c71bcb79ca11d2d729f31/images/Load-Native-Page.gif -------------------------------------------------------------------------------- /images/Load-WebView-Page.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebView-CG/usage-and-challenges/22f8f3479c9e3c4ca07c71bcb79ca11d2d729f31/images/Load-WebView-Page.gif -------------------------------------------------------------------------------- /images/Procedure-of-loading-a-webview-page.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebView-CG/usage-and-challenges/22f8f3479c9e3c4ca07c71bcb79ca11d2d729f31/images/Procedure-of-loading-a-webview-page.png -------------------------------------------------------------------------------- /images/With-same-layer-rendering.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebView-CG/usage-and-challenges/22f8f3479c9e3c4ca07c71bcb79ca11d2d729f31/images/With-same-layer-rendering.png -------------------------------------------------------------------------------- /images/Without-same-layer-rendering.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebView-CG/usage-and-challenges/22f8f3479c9e3c4ca07c71bcb79ca11d2d729f31/images/Without-same-layer-rendering.png -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | WebView: Usage Scenarios and Challenges 7 | 8 | 27 | 28 | 29 | 30 |
31 |

This document aims to identify representative use cases of where WebViews are being used, regardless of the 32 | platform and type of device they're used on, identify the issues that arise from these usages and determine 33 | whether these issues can be addressed through improvements to the Web Platform, the surrounding ecosystem (e.g. 34 | documentation, testing frameworks) or through other mechanisms.

35 |
36 |
37 |

This is the skeleton of the core document on which the WebView Community Group will focus in its first phase of work.

39 |
40 |
41 |

Introduction

42 |

The WebView Community Group aims to identify, understand and reduce the issues arising from the use of software 43 | components (typically referred to as [=WebViews=]) that are used to render Web technology-based content outside of 44 | a Web browser (native applications, MiniApps, etc).

45 |

This document contains sections describing the use cases that were contributed by multiple authors. Since this 46 | document is a group note, additional use cases will be added in future revisions of this document.

47 |
48 | 49 |
50 |

WebViews

51 |

A native application (or native app) is an application designed to run on a particular operating system. It is 53 | written in native code and leverages native APIs exposed by the operating system. Typical examples include an iOS 54 | application written in Swift or Objective-C and that uses the iOS SDK, or an Android application written in Kotlin, Java or C++ using the 56 | Android SDK. [=native applications=] do not require a dedicated runtime to run as they interface with the 57 | operating system directly.

58 | 59 |

A web application (or web app) is an application written using Web technologies (URLs, HTML, CSS, 60 | JavaScript APIs). [=web applications=] typically run in a web browser runtime. All systems and devices that can 61 | render Web content have at least one system-wide Web browser application, which is either pre-installed 62 | on the device or that users can install.

63 | 64 |

WebViews are software components provided in an SDK that can be used to render Web content directly 65 | within a [=native application=] without having to switch to the [=system-wide Web browser=]. [=WebViews=] are used 66 | in a wide range of scenarios. They all share the same architecture: a [=native application=] embeds and interacts 67 | with one or more [=WebViews=] to render Web content within the [=WebView=].

68 | 69 |
70 |

Types of WebViews

71 |

[=WebViews=] can differ based on the following properties:

72 |

73 |

85 |

86 |

However, in practice, [=WebViews=] are classified into one of two categories with fixed properties:

87 |
88 |
Browser-like WebViews
89 |
These WebViews are straightforward to embed with a simpler API surface mostly targeted at loading the web 90 | page. They are generally not [=flexible=], do not provide [=access to the web content=], but [=share state=] 91 | with the [=system-wide web browser=].
92 |
Fully-fledged WebViews
93 |
These WebViews are used for creating richer experiences and feature powerful integration primitives. They 94 | have full [=UX flexibility=] when integrated within an application, provide the ability to [=access the web 95 | content=] (native and web parts of the application can communicate), and do not [=share state=] with the 96 | [=system-wide web browser=].
97 |
98 |
99 |
100 | 101 |
102 |

Implementations

103 |

The following table contains different [=WebView=] implementations with their different considerations

104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 |
CategoryNamePlatformsDescriptionFeaturesLimitations[=UX flexibility=]Usage Example
[=Fully-fledged=]Android WebViewAndroidDefault WebView implementation on AndroidApps have [=access to the web content=]Same features as in Chrome overall but some Web APIs are not supportedWebView may be resized and mixed with native contentHybrid Frameworks (Cordova, Capacitor)
[=Browser-like=]Custom TabsAndroidAPI for opening [=browser-like=] WebViews on AndroidBrowser navigation and convenience features like password autofillNo [=access to the Web content=]Only minimal customization of the top bar possibleLink preview in social media Apps
[=Browser-like=]SFSafariViewControlleriOS, iPadOSAPI for opening [=browser-like=] WebViews on iOSBrowser navigation and convenience features like password autofillNo [=access to the Web content=]Only minimal customization of the top bar possibleLink preview in social media apps
UIWebView (deprecated)iOS, iPadOS, macOSSoon-to-be-removed WebView API of iOSApps have [=access to the web content=]Some Web standards are not supported. Performance and security wise inferior to WKWebView, 155 | deprecatedWebView may be resized and mixed with native contentHybrid Frameworks (Cordova, Capacitor)
[=Fully-fledged=]WKWebViewiOS, iPadOS, macOSDefault WebView implementation on iOSApps have [=access to the web content=]Same features as in Safari overall but some Web APIs are not supportedWebView may be resized and mixed with native contentHybrid Frameworks (Cordova, Capacitor)
[=Fully-fledged=]WebView2WindowsDefault WebView implementation on WindowsApps have [=access to the web content=]
181 | 182 | 186 | 187 | 190 |
191 | 192 |
193 |

Usages

194 |
195 |
Hybrid apps
196 |
197 |

[=Hybrid apps=] combine elements of [=native applications=] and [=web applications=].

198 |

[=Web applications=] wrapped in a native container are an example of an [=hybrid app=]. This provides 199 | developers with a cross-platform mechanism to build a [=native application=]. When [=fully-fledged=] WebViews 200 | are used, the ability to [=access the web content=] may be leveraged to add native-like capabilities to the 201 | WebView.

202 |

Another example is In-App Browsers (IABs), which is a pattern for browsing links to web pages within a native 203 | application without leaving the application.

204 |
205 |
Browsers
206 |
WebViews may be used to build browsers since they provide the capabilities of a rendering engine. When done 207 | with [=fully-fledged=] WebViews, these browsers can provide more customizable experiences (e.g. privacy-focused 208 | browsers) by modifying the web content.
209 |
Mini apps & super apps
210 |
211 |

WebViews may be used to render the web content of a [=MiniApp=] page.

212 |

Features that are not supported by the WebView, or that run with limited performance (such as maps, videos, 213 | etc.), are typically replaced by native components that take care of the rendering.

214 |

For these reasons, [=fully-fledged=] WebViews are used in the [=MiniApp=] ecosystem, to allow for [=UX 215 | flexibility=] and [=access to the web content=].

216 |
217 |
218 |
219 | 220 |
221 |

Limitations & Challenges

222 |

Individual limitations and challenges linked to specific usage scenarios are detailed in . The following themes have emerged:

224 |
225 |
Performance
226 |
Responsiveness is a critical requirement for applications. There are multiple opportunities to improve WebView 227 | performance, such as for initialization and page loads.
228 |
Inconsistencies
229 |
Behavioral inconsistencies across different WebViews diminish the interoperability of the web since web 230 | experiences will have to be special-cased against WebViews.
231 |
Control
232 |
Especially for [=fully-fledged=] WebViews, some user journeys are unachievable without additional control over 233 | the web content and rendering engine.
234 |
Security and Privacy
235 |
[=fully-fledged=] WebViews ship with powerful APIs that provide [=access to the web content=] without 236 | following usual web security restrictions. This unlocks powerful integration scenarios but can also be used for 237 | malicious purposes such as tracking and phishing.
238 |
239 |
240 | 241 |
242 |

Scenarios

243 |
244 |

Load a WebView Page

245 |
246 |
Submitter(s)
247 |
248 | Qing An, Alibaba 249 |
250 | 251 |
Motivation
252 |
253 | It is quite common to use WebView in Native App development, due to WebView’s benefit of cross-platform 254 | interoperability. But the page loading performance of WebView cannot satisfy Native App well, which means the 255 | loading of a WebView page is quite slower than loading a Native page. 256 |
257 |
258 | The below is WebView page loading, it firstly shows the white screen. 259 | 260 |
261 | WebView page loading 262 |
263 | WebView page loading 264 |
265 |
266 | 267 | But for the Native page loading as shown below, it shows the skeleton immediately, which gives a better user 268 | experience compared with WebView. 269 | 270 |
271 | Native page loading 272 |
273 | Native page loading 274 |
275 |
276 | 277 | Therefore, how to enhance the loading performance of WebView page needs to be addressed. 278 | 279 |
280 | 281 |
Stakeholders
282 |
283 |
    284 |
  • WebView provider: browsers, deciders on how to enhance WebView
    • 285 |
  • WebView user: Native App or MiniApp which rely on WebView to render pages
    • 286 |
  • End user: users of the Native App or MiniApp are indirectly using the pages and functions implemented by 287 | WebView
    • 288 |
289 |
290 | 291 |
Analysis
292 |
293 | The reason of long white screen is due to serial execution in loading a WebView page. The duration of white 294 | screen directly depends on the time cost from routing intercept to JS download & parse & exec as described in 295 | the following figure. 296 | 297 |
298 | Procedure of loading a WebView page 300 |
301 | Procedure of loading a WebView page 302 |
303 |
304 |
305 | 306 |
Related W3C deliverables and/or work items
307 |
308 |
    309 |
  • Resource Hints defines the Prefetch on page 310 | resources
    • 311 |
  • Preload defines provides a declarative fetch primitive 312 | that initiates an early fetch and separates fetching from resource execution
    • 313 |
314 |
315 | 316 |
How is the issue solved in the Browser, and what’s more is needed?
317 |
318 |
    319 |
  • In the Browser: Prefetch, Preload and Next are used to pre-request resources (e.g. HTML, CSS, 320 | JavaScript, Img, etc.), but they are not supported or only partly supported by WebView.
    • 321 |
  • What’s more: how to pre-request the data (JSON, XML, etc.) 322 |
    323 | Take e-commerce App as example. WebView is used to render the page of product list and product info. So, a 324 | request to fetch the data is needed, and the data is described and transferred in the format of JSON or 325 | XML. Sometimes, user info is also carried in the request, to obtain the personalized product info. If the 326 | data can be pre-requested, the performance of loading a product page can be increased. 327 |
    • 328 |
329 |
330 |
331 |
332 | 333 |
334 |

Requests/responses sharing and proxy between Native and WebView

335 |
336 |
Submitter(s)
337 |
338 | John Riviello 339 |
340 | Jiasheng Wu, ByteDance 341 |
342 | 343 |
Motivation
344 |
345 | In a hybrid Native/WebView app, some Native app may load first-party website or third-party website through 346 | WebView. So, the Native app and the WebView may make the exact same calls in first-party business, or Native 347 | app handles the resource request on behalf of WebView and the corresponding response data returned to WebView 348 | can even be different with what is received by Native from the backend server. Also, not all requests want to 349 | be proxied through Native, WebView user want to proxy a small number of requests locally to load offline 350 | resources. 351 |
352 |
353 | Some scenarios: 354 |
    355 |
  1. Document access control: it is expected to manage the access control of Web access documents, allowing 356 | different users to access documents of different levels.
    2. 357 |
  2. Security firewall: In order to meet compliance requirements, network engineers want to audit requests 358 | within the app, and do not allow insecure requests to be sent on the web.
    3. 359 |
  3. Transcoder: In special scenarios, we may need to convert GIF images to JPEG images to send to reduce 360 | traffic, and may also need to translate documents to meet communication needs in different language 361 | scenarios. For example, it's hard for a user to communicating in English. When communicating, the user can 362 | type Chinese and it will be automatically translated into English.
    4. 363 |
  4. Anonymous: Some users may have higher requirements for the privacy of Web access, requiring that 364 | requests within the Web must remove identity features (such as client IP address, From header, Referer 365 | header, cookie, URI session ID), providing a high degree of privacy and anonymity.
    5. 366 |
  5. Reducing network requests: A hybrid app (in the sense that some screens are native code and other 367 | screens are Webviews) may make some of the same network requests (HTTP GET, POST, PUT, DELETE, or other 368 | network connections supported by webviews such as Web Sockets and WebRTC) in both the native screens and 369 | the webview screens. Being able to easily share those responses between native and web (while maintaining 370 | proper HTTP cache semantics) would reduce redundant requests, saving end-users bandwidth and reducing 371 | server traffic.
    6. 372 |
373 | 374 | 380 | 381 |
382 | 383 |
Stakeholders
384 |
385 |
    386 |
  • WebView provider: Apple, Google, deciders on how to enhance sharing between WebView & Native
    • 387 |
  • WebView user: Native Business rely on WebView to send internal request, or load offline resource
    • 388 |
  • End user: users of the App save bandwidth by not having to make duplicate calls
    • 389 |
390 |
391 | 392 |
Analysis
393 |
394 | This is currently even possible in some way, but it is not a recommended pattern. So making this a standard 395 | that is easy to use for both Native and WebView developers would be a win for both groups. 396 | 397 |
398 |
399 | shouldInterceptRequest 401 | in Android WebView provide develop with optional network interception capability. 402 | 403 |
404 | 405 |
Related W3C deliverables and/or work items
406 |
407 | N/A 408 |
409 | 410 |
How is the issue solved in the Browser, and what’s more is needed?
411 |
412 | N/A 413 |
414 |
415 |
416 | 417 |
418 |

Render WebView Components and Native Components in same layer

419 |
420 |
Submitter(s)
421 |
422 | Qing An, Alibaba 423 |
424 | 425 |
Motivation
426 |
427 | Hybrid Native/Webview App and MiniApp often use both WebView Components (text, label, button, image, etc.) and 428 | Native Components (such as video). 429 |
    430 |
  1. Add a map: due to that developing a Web-based map component is difficult and not so good performance, 431 | developers may choose to use the Native map component. Usually, developers cover the WebView with the 432 | Native map component. But very often, the Native map will cover all the Web components rendered by 433 | WebView. And it is difficult to display one or several Web components on the Native map.
    2. 434 |
  2. Integrate a third-party content into WebView: from the business perspective, Native App needs to 435 | integrate third-party advertisements into the some App UI pages which are rendered by WebView. Many 436 | third-party advertisements are implemented based on Native components. How to integrate Native components 437 | with WebView smoothly?
    3. 438 |
  3. WebView interacts with Native component: developers have implemented a fancy UI page based on WebView, 439 | and then the WebView needs to use an extra Native component. How can the Native component interact with 440 | WebView smoothly? Like how to let Native component reuse the event handling and message interaction that 441 | have been implemented in WebView?
    4. 442 |
443 | Unlike WebView Components, the Native Components are rendered by Native App instead of WebView. While Native 444 | Components can bring more features by complementing WebView Components, Native Components also bring issue for 445 | developers due to that Native rendering is independent of WebView rendering. 446 |
447 |
448 | Therefore, Native Component cannot be controlled by z-index property, and cannot overlap with WebView 449 | components, as illustrated below. 450 | 451 |
452 | Without-same-layer-rendering 453 |
454 | Render WebView Components and Native Components in separate layers 455 |
456 |
457 | 458 | But if the Native Components can be rendered in the same layer of WebView Component, AKA in the WebView Layer, 459 | developers can easily control the Native Components as well as the overlapping with other WebView Components, 460 | as illustrated below. 461 | 462 |
463 | With-same-layer-rendering 464 |
465 | Render WebView Components and Native Components in same layer 466 |
467 |
468 | 469 |
470 | 471 |
Stakeholders
472 |
473 |
    474 |
  • WebView provider: Apple, Google, deciders on how to support the same layer rendering
    • 475 |
  • Native App or MiniApp developer: rely on the WebView
    • 476 |
  • End user: users of the Native App or MiniApp are indirectly using the pages and functions implemented by 477 | WebView.
    • 478 |
479 |
480 | 481 |
Analysis
482 |
483 | Currently, Native rendering is independent of WebView rendering. Therefore, Native Component cannot be 484 | controlled by `z-index` property, and cannot overlap with WebView components. 485 | 486 |
487 | 488 |
Related W3C deliverables and/or work items
489 |
490 | N/A 491 |
492 | 493 |
How is the issue solved in the Browser, and what’s more is needed?
494 |
495 | N/A 496 |
497 |
498 |
499 | 500 |
501 |

Inject custom JS scripts

502 |
503 |
Submitter(s)
504 |
505 | Maxim Tsoy, Duck Duck Go 506 |
507 | 508 |
Motivation
509 |
510 | User scripts (aka content scripts) is a powerful tool that unlocks many possibilities such as: 511 |
    512 |
  • content customization (e.g. applying custom CSS, adding UI elements)
    • 513 |
  • security and privacy protection (e.g. blocking harmful APIs, preventing data leakage and fingerprinting) 514 |
    • 515 |
  • enriching web app functionality (e.g. filling previously saved passwords, translating text to foreign 516 | language, polyfilling missing APIs)
    • 517 |
518 | Injected scripts can also be a workaround when another WebView feature is not available: for example, due to 519 | the lack of granular cookie control in native WebView APIs, one method is to inject a 521 | script to augment `document.cookie API`. 522 |
523 | 524 |
Stakeholders
525 |
526 |
    527 |
  • WebView vendors: Google (WebView), Microsoft (WebView2), Apple (WKWebView)
    • 528 |
  • App developers that need customizations of the rendered content
    • 529 |
530 |
531 | 532 |
Analysis
533 |
534 | Web extensions have a similar concept of content 536 | scripts, however the features provided by the native WebView implementaions are much less versatile and 537 | not standardized. 538 |
539 |
540 | Most platforms implement a basic `evaluateJS()` kind of method, which allows to execute 541 | arbitrary JS code in the page context. However, it is limited, and lacks some important features that would 542 | make developers live easier if they were cross-platform: 543 |
    544 |
  1. Run scripts in isolated world 545 |
    546 | It is common for web pages to change JS prototypes and global variables. This can easily affect the 547 | scripts injected by the native app. This can lead to security and privacy issues, and is very hard to 548 | prevent. Isolated 550 | world prevents these collisions by running the content script within its own JS environment, while 551 | still allowing it to access the DOM. Moreover, scripts in isolated world are not affected by CSP and 552 | other restrictions imposed on the page scripts. 553 | 559 |
    2. 560 |
  2. Inject scripts in all iframes, including cross-origin and sandboxed ones 561 |
    562 | This is currently a serious limitation on Android, which only allows executing in same-origin contexts. 563 | For DuckDuckGo browsers, this makes it very difficult to apply tracking protections, since trackers 564 | often operate in a third-party context. 565 |
    3. 566 |
  3. Inject scripts before all page scripts 567 |
    568 | Web extensions have a "run_at" 570 | paramenter that controls when the script will be executed. This is crucial for any security and privacy 571 | customizations that need to apply protections before any malicious script can take effect. For example, 572 | anti-fingerprinting 574 | protection augments the APIs, but it only protects from scripts executed after it. 575 |
    576 | WKWebView and 577 | WebView2 579 | can do this (although API approaches are different), but Android WebView doesn't allow it 580 |
    4. 581 |
  4. Secure messaging between the native code and injected scripts 582 |
    583 | Content scripts often work in combination with the native components and so require communication. For 584 | example, in DuckDuckGo browsers scripts use this to read user configuration (which is managed by the 585 | Native App), and trigger native UI changes on page-generated events. 586 |
    587 | WKWebView provides a convenient 589 | API for passing async messages, but Android WebView and Windows WebView2 do not have an 590 | alternative. It is possible to achieve a one-way communication by exposing global JS callables, but 591 | without isolated world this is insecure, since page scripts would be able to use those globals too. 592 |
    5. 593 |
  5. Inject scripts in ServiceWorkers and (Shared) Web Workers 594 |
    595 | Some scripts are designed to change the JS environment of the page scripts. For example, DuckDuckGo 596 | cookie protection deliberately 598 | changes the `document.cookie` API to protect against long-lived tracking cookies. However, there 599 | is currently no (straightforward) way to do this in Workers, which have access to powerful APIs as well 600 | (e.g. Cookie Store API) 601 |
    602 | This is currently not possible on any platform 603 |
    6. 604 |
605 |
606 | 607 |
Related W3C deliverables and/or work items
608 |
609 | WebExtensions CG 610 |
611 | 612 |
How is the issue solved in the Browser, and what’s more is needed?
613 |
614 | In browsers, many of these issues are solved by Web Extension API. A lot of design patterns could be (and 615 | already are) borrowed from there. WKUserScript is clearly inspired by, and probably built upon the same 616 | technology. 617 |
618 | However, just exposing the WebExtensions API might not always be the right solution: WebViews are embedded in 619 | Native Apps, which operate and protect under a different security and performance model. In general, WebView 620 | should probably give more raw control than WebExtensions API. 621 |
622 |
623 |
624 | 625 |
626 |

Control API permissions

627 |
628 |
Submitter(s)
629 |
630 | Maxim Tsoy, Duck Duck Go 631 |
632 | 633 |
Motivation
634 |
635 | In apps that can load arbitrary web apps, such as WebView-powered browsers, it is desirable to give users 636 | control over website permissions via custom native UI. For example, a browser can prompt a user to allow a web 637 | app to access the camera, and then show an indicator while it's being used. To allow browsers to manage 638 | permissions, we need WebView APIs to: 639 |
    640 |
  • List what permissions have been set for a given site (allow/deny/query)
    • 641 |
  • Programmatically change and reset them
    • 642 |
  • Receive events when a permission is requested or used
    • 643 |
644 | Some examples of permissions include: 645 |
    646 |
  • camera / microphone
    • 647 |
  • geolocation
    • 648 |
  • screen capture
    • 649 |
  • other permissions managed with Permissions API
    • 651 |
652 |
653 | 654 |
Stakeholders
655 |
656 |
    657 |
  • WebView vendors (Google, Microsoft, Apple)
    • 658 |
  • Browser vendors (e.g. DuckDuckGo)
    • 659 |
660 |
661 | 662 |
Analysis
663 |
664 | There's currently no cross-platform approach and support. Most WebViews provide events / APIs for specific 665 | permissions, but the feature parity could be better. 666 |
667 | Some specific examples of limitations: 668 | 683 |
684 | 685 |
Related W3C deliverables and/or work items
686 |
687 | Permissions API 688 |
689 | 690 |
How is the issue solved in the Browser, and what’s more is needed?
691 |
692 | Non-webview Browsers have implement this using internal APIs. 693 |
694 |
695 |
696 | 697 |
698 |

Manage web storage and cookies

699 |
700 |
Submitter(s)
701 |
702 | Maxim Tsoy, Duck Duck Go 703 |
704 | 705 |
Motivation
706 |
707 | Apps loading 3rd-party web content in WebViews may need more granular control over stored data. For example, 708 | DuckDuckGo browsers need this for the Fireproof feature, which allows to make exceptions to the cookie/storage 709 | removal. 710 |
711 | 712 |
Stakeholders
713 |
714 |
    715 |
  • Browsers based on WebView
    • 716 |
  • WebView vendors
    • 717 |
718 |
719 | 720 |
Analysis
721 |
722 |
    723 |
  • Webkit provides APIs to retrieve cookies and local/sessionStorage as opaque tokens that can be filtered 724 | by hostname. This allows selective removal, although it requires some extra code and workarounds to 725 | prevent timing issues (removal is asynchronous).
    • 726 |
  • In Webkit, storage is shared between all WKWebView instances, unless it's "non persistent" (in memory), 727 | which is not ideal for building web browsers.
    • 728 |
  • In Android WebView, it is not possible to inspect cookie scopes. You can retrieve cookie names and 729 | values, but without knowing other attributes it is impossible to override them properly.
    • 730 |
  • Android WebView does not provide APIs to manage localStorage/sessionStorage.
    • 731 |
732 |
733 | 734 |
Related W3C deliverables and/or work items
735 |
736 | N/A 737 |
738 | 739 |
How is the issue solved in the Browser, and what’s more is needed?
740 |
741 | Browsers manage storage using APIs of a specific rendering engine. 742 |
743 |
744 |
745 | 746 |
747 |

The Origin in a WebView for locally hosted content

748 |
749 |
Submitter(s)
750 |
751 | Niklas Merz, Apache Software Foundation 752 |
753 | 754 |
Motivation
755 |
756 | WebViews are widely used for building apps on the dominating mobile and desktop platforms. Up to 30% of apps found in the app stores (Apple 758 | and Google) are built with frameworks like Apache Cordova and CapacitorJS. Those two frameworks use one big WebView for providing app 760 | developers a native wrapper and some plugins for their Web app. App developers build their Web application and 761 | put the HTML, CSS and JavaScript files in one folder. The framework then takes care of building a native app 762 | project and bundling the Web code as a native application ready to distribute via the app stores. 763 |
764 | App developers usually only need knowledge in HTML, CSS and JavaScript and can call native OS features via 765 | plugins. The frameworks provide a bridge that makes these native features available as JavaScript functions 766 | inside the WebView. Because of this, the locally hosted Web application "should just work as published on the 767 | Web". Connections to the backend are usually done via fetch/XHR. Because the origin for the app code is 768 | different than the backend, there is always CORS involved. 769 |
770 | Cordova used to host the bundled Web content via `file://` URLs for a long time. In recent years many apps 771 | needed to switch to a "proper origin" mainly because of two reason: 772 |
    773 |
  1. Web frameworks like React or Angular use their own router framework that relies on the origin and paths. 774 | The just don't work with file URLs.
    2. 775 |
  2. HTTP requests from file URLs have quirks in the CORS handling. If I recall correctly the WebViews 776 | started to set the `Origin` HTTP header to `null` which made it difficult to make requests to backends and 777 | APIs.
    3. 778 |
779 | Therefore Capacitor and Cordova changed the defaults to hosting the content on their "special origins" based 780 | on the fact that Android `https:://custom` and iOS `custom:\\custom` are using different approaches for their 781 | origins in WebViews. 782 | 783 |
    784 |
  • Android has WebViewAssetLoader 786 | that lets you create a "fake" domain to serve files to the WebView. Therefore, you can access local files 787 | via `https://myappcode/index.html` for example. WebViewAssetLoader only allows you to serve GET requests 788 | and access to the HTTP request is limited.
    • 789 |
  • iOS lets you implement a custom URL scheme like `myapp://mycode` and you can access the HTTP request and 790 | response quite freely to implement custom logic around that. This is called WKURLSchemehandler.
    • 792 |
793 |
794 | 795 |
Stakeholders
796 |
797 |
    798 |
  • WebView providers: Apple, Google, deciders on how to support having a standardized origin of web content 799 | hosted by the App for the Webview
    • 800 |
801 |
802 | 803 |
Analysis
804 |
805 | Apps built with this hybrid approach in mind are really dependent on making CORS work and HTTP requests 806 | possible on their own web content. This approach might benefit from a standardized way of providing Web 807 | content from the app to the WebView. This content could be considered secure. 808 |
809 | The most promiment implementations in Android and iOS provided solutions for many problems and solved some of 810 | those mentioned. But there still exist some issues. Some of them are: 811 |
    812 |
  • With some backends it might cause problems that you need to allow two different origins for CORS. 813 | Android only allows `http(s):` with WebViewAssetLoader and iOS only `custom:` etc with WKURLSchemeHandler. 814 | So you can't have one static allow setting for CORS but need its to be dynamic or the backend needs to 815 | allow multiple origins. (Some backends might not allow this.)
    • 816 |
  • Anti tracking features of WebViews might block authentication cookies. Most Apps have gotten rid 817 | of cookies for good but sometimes cookies are still used. Especially iOS implemented a stronger 818 | Intelligent Tracking Prevention in WebViews that blocks many cookies on CORS requests. In some cases even 819 | legitimate authencation cookies to the apps 820 | backend can get blocked and developers either need to switch to a different authentication method if 821 | possible or find workarounds.
    • 822 |
  • Androids and iOS implementations of this "custom scheme API" are quite different. iOS 823 | WKURLSchemeHandler is quite powerful. As an app developer you can use the scheme handler for your custom 824 | scheme like `app://custom` in many different ways to intercept HTTP requests from the WebView and provide 825 | a custom response. From providing local files to proxying requests in the native layer everything is 826 | possible. Androids WebViewAssetLoader is more limited with only loading local files in mind. If you 827 | implement a custom domain you can mostly provide content to GET requests but your access to the request 828 | and response of the HTTP request is limited.
    • 829 |
  • The options to allow/deny traffic to Web content in in Webviews are not really standardized as well. iOS 830 | has App Bound Domains but this has it's own capabilities and limitations.
    • 831 |
832 | So, maybe a standardized APIs for Webviews to load content not found on the Web but provided to the Webview on 833 | a "proper origin" can solve this challenge. 834 | 835 |
836 | 837 |
Related W3C deliverables and/or work items
838 |
839 | N/A 840 |
841 | 842 |
How is the issue solved in the Browser, and what`s more is needed?
843 |
844 | N/A 845 |
846 |
847 |
848 | 849 |
850 |

Define different types of WebViews

851 |
852 |
Submitter(s)
853 |
854 | Niklas Merz, Apache Software Foundation 855 |
856 | 857 |
Motivation
858 |
859 | As more and more use cases are discussed, it might be helpful to define and name the different uses of 860 | WebViews. WebViews can be used in many different ways and some of them are vastly different in terms of 861 | privacy and security implications. It could be a good idea to separate them into different categories to 862 | discuss them better. 863 |
864 | 865 |
Stakeholders
866 |
867 |
    868 |
  • Browsers vendors
    • 869 |
  • App developers
    • 870 |
871 |
872 | 873 |
Analysis
874 |
875 | We can already see these different categories of WebViews with the APIs available on the two big mobile 876 | platforms. Android offers a powerful WebView API and Chrome Custom Tabs. iOS has WKWebView 878 | for a rich WebView API and SFSafariViewController 880 | for a more browser-like experience embedded in native Apps. 881 |
882 | The WebView APIs offer powerful features for example injecting JavaScript or other interactions with the pages 883 | loaded into the WebView. These features require the designers of the WebView APIs and App developers to think 884 | a lot about the security and privacy implications of their design choices. WebViews that allow the user to 885 | navigate the Web freely need to be much more secure and restricted than WebViews that just allow code under 886 | control of the App developers. 887 |
888 | WebViews are used a lot to build the UI or core features of Apps. These Apps could benefit from more control 889 | over the native parts of the App or vice versa the native code might want to have more control over the Web 890 | content. 891 |
892 | The distinction between browser-like WebViews and full WebViews embedded into Apps is the most obvious one but 893 | there are many more like we see with ePub and MiniApps. 895 |
896 | If there are different types of WebViews with different use cases and feature sets App developers could 897 | benefit from more freedom or security and privacy. Browser vendors could roll out powerful features for 898 | developers of Apps built around WebViews but still keep the browsers and browser-like WebViews secure. 899 |
900 | 901 |
Related W3C deliverables and/or work items
902 |
903 | N/A 904 |
905 | 906 |
How is the issue solved in the Browser, and what’s more is needed?
907 |
908 | WebViews and browsers currently always have the same features and restrictions. Different WebView 909 | implementations share different APIs to interact with the WebView content. 910 |
911 |
912 |
913 |
914 | 915 | 916 | -------------------------------------------------------------------------------- /meetings/1st-meeting-agenda-20220420.md: -------------------------------------------------------------------------------- 1 | # First meeting agenda 2 | 3 | 4 | * Welcome! Round of introductions -- 5min 5 | * CG charter: scope and objectives -- 10min 6 | * Logistics: recurring calls, GitHub repository, document edition -- 10min 7 | * Template to collect use cases & requirements, and one use case discussion (https://github.com/WebView-CG/usage-and-challenges/issues/3) -- 30min 8 | * AoB 9 | 10 | 11 | # First meeting minutes 12 | https://www.w3.org/2022/04/20-webview-minutes.html 13 | -------------------------------------------------------------------------------- /meetings/2nd-meeting-agenda-220511.md: -------------------------------------------------------------------------------- 1 | # Second meeting agenda (2022-05-11) 2 | 3 | 4 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3A%22use+case%22 5 | * Kick off the use cases and limitations report draft, https://github.com/WebView-CG/charter/blob/main/charter.md#non-normative-reports 6 | * Review other issues (if we have time), https://github.com/WebView-CG/usage-and-challenges/issues 7 | 8 | # Second meeting minutes 9 | https://www.w3.org/2022/05/11-webview-minutes.html 10 | -------------------------------------------------------------------------------- /meetings/3rd-meeting-agenda-220525.md: -------------------------------------------------------------------------------- 1 | # Third meeting agenda (2022-05-25, 14:00 UTC) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3A%22use+case%22 4 | * Review other issues (if we have time), https://github.com/WebView-CG/usage-and-challenges/issues 5 | 6 | # Third meeting minutes 7 | https://www.w3.org/2022/05/25-webview-minutes.html 8 | -------------------------------------------------------------------------------- /meetings/4th-meeting-agenda-220608.md: -------------------------------------------------------------------------------- 1 | # Fourth meeting agenda (2022-06-08, 07:00 UTC) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3A%22use+case%22 4 | * Review other issues (if we have time), https://github.com/WebView-CG/usage-and-challenges/issues 5 | 6 | # Fourth meeting minutes 7 | https://www.w3.org/2022/06/08-webview-minutes.html 8 | -------------------------------------------------------------------------------- /meetings/5th-meeting-agenda-220706.md: -------------------------------------------------------------------------------- 1 | # Fifth meeting agenda (2022-07-06) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2B 4 | * Review other issues, https://github.com/WebView-CG/usage-and-challenges/issues 5 | -------------------------------------------------------------------------------- /meetings/6th-meeting-agenda-220727.md: -------------------------------------------------------------------------------- 1 | # Sixth meeting agenda (2022-07-27) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2B 4 | * Review other issues, https://github.com/WebView-CG/usage-and-challenges/issues 5 | 6 | # Sixth meeting minutes 7 | https://www.w3.org/2022/07/26-webview-minutes.html 8 | -------------------------------------------------------------------------------- /meetings/7th-meeting-agenda-220809.md: -------------------------------------------------------------------------------- 1 | # Seventh meeting agenda (2022-08-09) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2B 4 | * Review other issues, https://github.com/WebView-CG/usage-and-challenges/issues 5 | -------------------------------------------------------------------------------- /meetings/8th-meeting-agenda-220823.md: -------------------------------------------------------------------------------- 1 | # Eighth meeting agenda (2022-08-23) 2 | 3 | * Review and discuss use cases, https://github.com/WebView-CG/usage-and-challenges/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2B 4 | * Review other issues, https://github.com/WebView-CG/usage-and-challenges/issues 5 | -------------------------------------------------------------------------------- /use_case&issue_template.md: -------------------------------------------------------------------------------- 1 | # Use case and Issue Template 2 | 3 | note: this is the template to submit a Github issue regarding the use case and issue of using WebView in native mobile platforms. 4 | 5 | ## Submitter(s) 6 | 7 | ## Motivation 8 | 9 | ## Stakeholders 10 | 11 | ## Analysis 12 | 13 | ## Related W3C deliverables and/or work items 14 | 15 | ## How is the issue solved in the Browser, and what’s more is needed? 16 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": ["cg/webview"] 3 | , "contacts": ["dontcallmeDom"] 4 | , "repo-type": "cg-report" 5 | } 6 | --------------------------------------------------------------------------------