Vanadium
Vanadium copied to clipboard
GrapheneOS
figure out how to make safe_browsing_mode=3 (local database for mobile) work as an optional feature
I obtained an API key for Safe Browsing, but simply building safe_browsing_mode=3 and the API key in the build configuration doesn't work. It does appear to attempt to make API requests, but they fail and show up as errors in the API usage metrics. Using the API manually via curl with the API key does work.
This is a very low priority especially since we'd need to obtain a substantial increase on the standard Safe Browsing API limit and I have little interest in getting in touch with them to get that.
@thestinger quoting your comment from another issue:
I would like to take an approach like Brave for Safe Browsing, although not using the Play Services implementation on mobile. The standard Safe Browsing retrieves a database based on a truncated 4 byte (32-bit) hash of the URL. This intentionally has many collisions and ends up downloading a database of many URLs. Brave proxies the connections through their own servers in order to provide a better privacy policy too. The existing implementation isn't privacy invasive unless the user opts in to reporting (and I've disabled doing that) or enables Scout which is still allowed but I want to remove that preference as it doesn't make sense to use it with a non-official Chrome browser and it just doesn't fit Vanadium.
Their Safe Browsing implementation for ad blocking is likely to figure out which sites should have it enabled, using this existing database system. I simply want to disable that part of it and apply the filters globally across sites, so that dependency may not be particularly relevant with this disabled. I'd also want to retrieve the filters from my own servers and maybe they should be signed. I'll need to look at how they implement it.
With recent news (https://blog.google/threat-analysis-group/countering-threats-north-korea/) I have been thinking that perhaps we should invest more into this; how much do you know about the Safe Browsing API? (I do not have much information); would it be an option to export its content (unlikely because of ToS) or use a different third-party database/service? The solution I would prefer most is one where the database files (clear of copyright issues) are served as simple files via CDN, and perhaps browser could even fetch only sections using HTTP range requests (multiple random ones would be preferable to increase privacy).
@csagan5 One option is making our own remote proxy. We've implemented one for the attestation remote provisioning service used as part of Android's new hardware-based attestation approach, which we plan on shipping in GrapheneOS for the next release with a toggle for disabling our proxy:
https://github.com/GrapheneOS/grapheneos.network/commit/e74841e08934b1af547b9c931e5e0843f60ddbce
Their article about this new service: https://android-developers.googleblog.com/2022/03/upgrading-android-attestation-remote.html. It's already intended to be privacy preserving but by having a remote proxy we really reinforce that because our remote proxy won't be able to decrypt the data specific for batches or devices or specific devices (provisioned public key in the secure element) and their servers won't get an IP (or any other relevant data) so even if they did break their rules and internally shared the data, it wouldn't matter.
It should be fairly easy to set up a similar proxy for safe browsing. The main issues that I've found are that Safe Browsing as it exists in Chromium for Android depends on Play services in order for it to be shared across apps. For example, the WebView supports it with apps deciding if they want to use it:
https://chromium.googlesource.com/chromium/src.git/+/master/android_webview/browser/safe_browsing/README.md#opt_in_consent_requirements
It's available for other apps to use via a standard API too.
GrapheneOS users can currently use it in Vanadium if they're using sandboxed Google Play since we aren't currently removing all of the Play services SDK partly since FIDO authentication support depends on it, although we need them to whitelist Vanadium in their internal browser whitelist since only apps authorized explicitly by a domain can use FIDO by default with this database allowing specific browsers to use it.
You can try both curl -H 'Content-Length: 0' -X POST https://remoteprovisioning.googleapis.com/v1:fetchEekChain -v | xxd and curl -H 'Content-Length: 0' -X POST https://remoteprovisioning.grapheneos.org/v1:fetchEekChain -v | xxd to see that it works properly (xxd comes with vim and converts to or from a hex dump for hex editing in vim, which is useful simply to dump this as hex in a readable way).
GrapheneOS users can currently use it in Vanadium if they're using sandboxed Google Play since we aren't currently removing all of the Play services SDK partly since FIDO authentication support depends on it, although we need them to whitelist Vanadium in their internal browser whitelist since only apps authorized explicitly by a domain can use FIDO by default with this database allowing specific browsers to use it.
There was a Bromite feature request about this: https://github.com/bromite/bromite/issues/1433 The solution proposed there needed some work and perhaps even its own separate project.
The main issues that I've found are that Safe Browsing as it exists in Chromium for Android depends on Play services in order for it to be shared across apps.
I didn't know that, thanks; so it would require a separate native client in the codebase? (similar to what must be there in Android code already) I guess Vanadium would not have this problem if it can allow Play Services for this service as well.
Documentation here says:
Note: this is only relevant for the GMS-based implementation in downstream WebView targets.
Does it mean that the browser has a non-GMS implementation?
The browser uses Play services for Safe Browsing an Android but in theory it can be changed to do that itself and it looks like they did partially implement it but my understanding is that it's essentially legacy cruft that's unused and likely requires a fair bit of changes to work.