muodov
commented
2 years ago We discussed this during the meeting on Jul 6th. At DDG, we hit quite a few limitations on different platforms, Apple providing the most features and Android having the most hard limits so far.
Injecting scripts is a powerful tool that can solve many different problems, and most of the underlying technology is already there for web extensions. My view is that ideally WebViews should expose more low-level and powerful modification features than browser extensions, since it is operating on the OS-native side of things. Besides, on Android and Windows there are alternative WebView implementations that can be more or less restrictive.
@rayankans would you mind sharing some perspective from the Chrome side? DuckDuckGo is struggling with some WebView limitations on Android, and it would be great to hear your opinion.
rayankans
QingAn
aluhrs13
Inject custom JS scripts
Submitter(s)
Maxim Tsoy, Duck Duck Go
Motivation
User scripts (aka content scripts) is a powerful tool that unlocks many possibilities such as
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, DuckDuckGo injects a script to augment
document.cookieAPI.There is a previously closed issue https://github.com/WebView-CG/usage-and-challenges/issues/10, which is similar, but here I try to expand the use case based on our experience.
Stakeholders
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(<string_payload>)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 live easier if they were cross-platform:1. 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. To be clear, isolated world is not a replacement to the main world.
2. 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.
3. 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, DDG anti-fingerprinting protection augments the APIs, but it only protects from scripts executed after it.
4. 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.
5. Inject scripts in ServiceWorkers and (Shared) Web Workers.
Some scripts are designed to change the JS environment of the page scripts. For example, DDG cookie protection deliberately changes the
document.cookieAPI 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)Related W3C deliverables and/or work items
WebExtensions CG
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. I think 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.