@vapourisation several apps do inject javascript into the in-app webview to continue the user tracking and data vacuuming. They would not be able to do that if they passed the URL to your default browser.
source: worked in an analytics company and we had to debug fun incompatibilities with the tracking code that tiktok and facebook add into their webview
@mira @vapourisation nope, the evaluateJavascript API [developer.android.com] allows the host process to pass an arbitrary javascript string, as if it was typed in the console. Global variables / functions can also be replaced with addJavascriptInterface [developer.android.com].
These APIs make sense if you want to allow webview content to control native code in the host process, like an electron desktop "app", but they are a arbitrary code execution backdoor when third-party content is loaded.
As the passman authors wrote [github.com]:
- Are you adding something to check if malicious code is executing on the browser?
- No, because malicious code can edit functions that check for malicious code.
These webviews usually use a specific user-agent, but that user-agent will be spoofed the minute we start blocking it.
@quinze yeesh, hadn't even thought of that aspect of it. It was originally mostly FOSS apps (Capy Reader, Voyager) that I was complaining about because it seemed to be set on by default.