I actually can't believe they screwed this up and injected the malware as js into the loaded site where it could be observed introspectively, rather than just doing the spying from the native code in the browser that site js can't see. I'd assumed they'd done the latter.
Conversation
I guess the missing step in my reasoning was that it's much harder to find programmers that unethical with qualifications to maintain modifications to the browser engine than ones who can write js-injection junk.
1
1
7
Replying to
If they're using WebView they can intercept requests and modify content with a standard API. API is usually used for content filtering.
github.com/GrapheneOS/Pdf
We moved to using it in our PDF Viewer app so that we could set security headers unlike origin being asset: or file:.
1
1
You can intercept and handle the request in the app with your own response provided. It's stream-based and you could simply use it passively where you record all request headers / bodies and also response headers / bodies. Meant for content filtering or partially local sites.
1
2
WebView was not really intended for building browsers but rather rendering content like HTML emails, local web content, building components of the app based on web content or embedding your own site. Possible to use it like a browser or make a browser but it's not the proper API.
Apps that are not poorly written or doing sketchy things use developer.chrome.com/docs/android/c. Opening a site in a custom tab opens it in the user's default browser as an activity on top of your app, so it acts as if your app opened it. It's the user's browser isolated from your app.
1
3
You can tell if apps are using custom tabs as they're supposed to be doing because the UI is provided by the OS and browser. Has a menu to move the custom tab UI to a browser tab instead but it's just a UI distinction. The app only gets to customize the UI theme, etc. a tiny bit.
1