Conversation

Sounds more likely this will be used for "disable lockdown to view our site so our malvertising partners can track you better". 😡 FFS don't give them ways to identify & single out users protecting themselves. 🤦 twitter.com/botherder/stat

This Tweet is unavailable.

Rich Felker

@RichFelker

Aug 14

To clarify I'm not blaming

@botherder

but rather Apple for making this detectable from browser.

Replying to

and

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.

Replying to

and

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.

blog.alexi.sh

The impact of iOS 16 Lockdown mode in Safari

A look at how the new iOS lockdown mode affects web performances and features.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

grapheneos.org

GrapheneOS web installer

Web-based installer for GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

1:19 PM · Aug 14, 2022Twitter Web App

Replying to

and

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.