security and privacy protection (e.g. blocking harmful APIs, preventing data leakage and fingerprinting)
+
enriching web app functionality (e.g. filling previously saved passwords, translating text to foreign language, polyfilling missing APIs)
+
+ Injected scripts can also be a workaround when another WebView feature is not available: for example, due to the lack of granular cookie control in native WebView APIs, one method is to inject a script to augment `document.cookie API`.
+
+
+
Stakeholders
+
+
+
WebView vendors: Google (WebView), Microsoft (WebView2), Apple (WKWebView)
+
App developers that need customizations of the rendered content
+
+
+
+
Analysis
+
+ Web extensions have a similar concept of content scripts, however the features provided by the native WebView implementaions are much less versatile and not standardized.
+
+
+ Most platforms implement a basic `evaluateJS()` kind of method, which allows to execute arbitrary JS code in the page context. However, it is limited, and lacks some important features that would make developers' life easier if they were cross-platform:
+
+
Run scripts in isolated world
+
+ It is common for web pages to change JS prototypes and global variables. This can easily affect the scripts injected by the native app. This can lead to security and privacy issues, and is very hard to prevent. Isolated world prevents these collisions by running the content script within its own JS environment, while still allowing it to access the DOM. Moreover, scripts in isolated world are not affected by CSP and other restrictions imposed on the page scripts.
+
+
+
Inject scripts in all iframes, including cross-origin and sandboxed ones
+
+ This is currently a serious limitation on Android, which only allows executing in same-origin contexts. For DuckDuckGo browsers, this makes it very difficult to apply tracking protections, since trackers often operate in a third-party context.
+
+
Inject scripts before all page scripts
+
+ Web extensions have a "run_at" paramenter that controls when the script will be executed. This is crucial for any security and privacy customizations that need to apply protections before any malicious script can take effect. For example, anti-fingerprinting protection augments the APIs, but it only protects from scripts executed after it.
+
+ WKWebView and WebView2 can do this (although API approaches are different), but Android WebView doesn't allow it
+
+
Secure messaging between the native code and injected scripts
+
+ Content scripts often work in combination with the native components and so require communication. For example, in DuckDuckGo browsers scripts use this to read user configuration (which is managed by the Native App), and trigger native UI changes on page-generated events.
+
+ WKWebView provides a convenient API for passing async messages, but Android WebView and Windows WebView2 do not have an alternative. It is possible to achieve a one-way communication by exposing global JS callables, but without isolated world this is insecure, since page scripts would be able to use those globals too.
+
+
Inject scripts in ServiceWorkers and (Shared) Web Workers
+
+ Some scripts are designed to change the JS environment of the page scripts. For example, DuckDuckGo cookie protection deliberately changes the `document.cookie` API to protect against long-lived tracking cookies. However, there is currently no (straightforward) way to do this in Workers, which have access to powerful APIs as well (e.g. Cookie Store API)
+
+ This is currently not possible on any platform
+
How is the issue solved in the Browser, and what’s more is needed?
+
+ In browsers, many of these issues are solved by Web Extension API. A lot of design patterns could be (and already are) borrowed from there. WKUserScript is clearly inspired by, and probably built upon the same technology.
+
+ However, just exposing the WebExtensions API might not always be the right solution: WebViews are embedded in Native Apps, which operate and protect under a different security and performance model. In general, WebView should probably give more raw control than WebExtensions API.
+