Conversation
It's detectable because it disables features for attack surface reduction and you can detect that those features aren't available. Main issue with their lockdown mode is they shoved a bunch of stuff into it which should just be enabled by default with overly inconvenient stuff.
1
2
3
There's a list of what it disables in the browser at blog.alexi.sh/posts/2022/07/. It's very easy to detect in multiple ways. Since it's all or nothing, you know it's from lockdown mode. If you need a single one of those features, you can't just enable the feature that's needed.
1
1
3
We disable JIT by default on GrapheneOS for Vanadium with a per-site toggle and plan to do the same for WebView with a per-app toggle. It doesn't make any noticeable impact for most sites but for certain very heavyweight sites it's very noticeable. It makes Element Web unusable.
1
1
3
We plan to disable other features by default in the browser with similar per-site toggles. We wouldn't want it to all be tied together.
We take a similar approach in the OS where we deny new USB devices when locked by default, etc. We upstreamed perf being disabled by default.
1
3
All disabled by default, opt-in per-site never globally, is really the only right solution here. It precludes random junk sites you visit fingerprinting based on the set you enabled.
1
It's also a good reason for having content filtering with a standard filter on by default, which we plan on shipping in Vanadium. We haven't gotten our implementation of that completely finished though. It'll use Chromium's internal content filtering supporting EasyList syntax.
1
3
Content filtering is an easy way to fingerprint when it's opt-in via many different extensions and lists.
For users on the same browser and a device similar, it's at least feasible to get rid of nearly all fingerprinting.
Class of device is too easy to detect via JS though.
1
3
Can fairly easily determine available cores, CPU rev and perf class. Memory, available storage space, etc. get indirectly leaked due to things being proportional to them. Resolution, etc. are also relevant. For same browser + similar device model stuff should be the same though.
2
2
A nice example of storage space leaks is that grapheneos.org/install/web will fail in Incognito mode or if the user has under a certain amount of available storage. Firefox/Safari/Chromium allow sites to use up to a certain high storage cap which is lower for private browsing modes.
1
1
The high non-private-browsing storage cap gets reduced to a lower cap proportional to available storage, meaning sites can store a bunch of data to determine how much storage you have available if it's not an extremely large amount. Annoying to detect via the APIs but can do it.