As is, not even researching it, appears very likely that lockdown mode is easy to fingerprint via a browser from information shared in the linked article. Spoofing if functionality is off is not a common thing and would be very hard to do if not impossible if combined with challenge-response like counter-measure from the attacker to confirm the functionality is actually accessible to the end-user.
I think the more realistic threat model here is presented by ad networks and major websites doing typical types of browser fingerprinting, like canvas, fonts, etc. as well as possibly some of the techniques mentioned in the article here, like webGL, JIT JS, etc.
In that case of a limited number of trusted sites that we focus on ensuring compatibility with, spoofing is easier, because we can pay a lot of attention to ensuring that our "middleman" fixes the errors introduced by spoofed client-to-server communications.
Some technologies like WebGL will simply never work on a spoofed site, of course. But for the very limited number of sites when users lose important functionality, they can just turn off Lockdown mode.
If a Lockdown'd phone habitually patronizes malicious websites, the protection will never be enough anyway. So we shouldn't worry about protecting against being fingerprinted by a very malicious website - Lockdown users must simply avoid these, with or without a fingerprinting vulnerability!
If your suggesting Apple should proxy all internet traffic to devices — that is a horrible idea, incredibly dangerous, and a huge step in the wrong direction. To counter the issues I pointed out, Apple would literally have to be able to decrypt all the traffic and act as if they were the user, which is obviously a insane security issue.
As for avoiding malicious websites, again, I don’t believe you understand what advanced attacks look like. Any site can be hacked and if it is, fingerprinting can be used to only attack a very well defined known list of targets. For example, a very well known CEO of a security startup used a limousine service that was hacked after this was discovered and used to launch at attack against them.
Understand your interested in the topic, that’s great, but try to balance your technical familiarity, familiarity with the topic, and the very real threat security breaches pose to very small subset of the world. These features are not intended to counter AD companies, but attackers that in the worst case situation will ultimately kill the target.
iCloud Private Relay already exists.
https://support.apple.com/en-us/HT212614
3rd party description of it:
And again, is it a realistic threat model to imagine that a high volume website, trusted enough to be browsed regularly by Lockdown-paranoid users, will be hacked in such a way as to deliver a fingerprinting attack to browsers, and only that?
I appreciate the sense of superiority that you have, but try to follow along.
The device has the features turned off because they are know to be hard to harden against attacks or worse, have known vulnerabilities. To spoof them being on, a proxy that isolates requests to the functionality that’s off on the device would have to be sent to another device, but accurately responds as if it was on, including specific designed counter-measuring from an attacker to confirm the end user had real-time control over the proxied system. Just makes no sense to have such a complex system and in majority of situations would require another device that would be vulnerable to attack and always near the target and secured device.
>> And again, is it a realistic threat model to imagine that a high volume website, trusted enough to be browsed regularly by Lockdown-paranoid users, will be hacked in such a way as to deliver a fingerprinting attack to browsers, and only that?
Simple answer is yes. Also, it doesn’t have to be a high volume website, just one the target trusts enough to visit.
It's not that complex, it really can be reduced to what the browser already does: attempts to render web pages best for the display, without full hinting from the server-side.
In the end, what I'm getting at is that browsers should start viewing any page in an untrusted mode, and this mode should dramatically limit available fingerprint features to the most minimal subset that provides an acceptable user experience.
You also are ignoring that a challenge-response counter-measures by the attacker would require direct and real-time action from the targeted users; CAPTCHA is a type of real-time challenge-response combined with private information would confirm that the target user is actively using the device being targeted.
If you think you understand something I don’t that’s fine, but I clearly neither understand what you’re trying to communicate, nor agree with what little I believe I do and have repeatedly attempted to explain why and you have repeatedly ignored my points. If I have ignore a material point made by you, please explicitly point it out.
My guy, there's a difference between legitimate confusion and this sort of aggressively refusing to get the point.
Clearly I'm not referring to sandboxing or app privileges, I'm referring to how your browser assumes any site that's able to send it some Javascript should automatically expect that Javascript to run, or WebGL, or WebAssembly, or whatever monstrosity.
Fundamentally the web was built with the assumption that any resource loaded was an intentional act by a user, or by a process directly authorized by a user.
Over time, the internet has drifted to a one-protocol town, and that assumption by the designers of the protocol is breaking down as the protocol becomes everything to everyone. Trust boundaries and user controls are NOT evolving in time with the protocol capabilities, and worse, protocol development has largely become a fox guarding the henhouse as the main browser developers ultimately responsible for defining the de facto protocol suite, Google and Microsoft, each vie for advertiser dollars and market ubiquity by transforming web browsers into operating systems.
And no, lockdown mode should not enable or task users with authorizing file-by-file, line—by-line, etc blacklisted technologies; believe some of the off by default functionalities are able to be whitelist per domain, but might be wrong.
Also, you clearly and repeatedly stated you wanted to simulate running the code to “spoof” devices profile to evade fingerprinting — you, not I are the one intentionally causing issues in this thread, by repeatedly changing your stated intent.
Good luck, stay safe.
This will be instantly defeated by benchmarking the js performance. But disabling JIT is a VERY important step to harden your browser. This is one of these things where you have to actually choose between privacy and security
How common is this behavior for non-malicious websites that a Lockdown mode user is likely to use? It seems to me that if you're loading malicious content from a site controlled by foreign intelligence services, you're probably done whether Lockdown is enabled or not. Preventing more casual profiling from common logs likely to be strewn about in CDNs, etc. is still an important level of protection, I'd argue.
Normal web pages that load ads will attempt to detect "fraud" by connecting back over WebRTC, running benchmarks to see how "valuable" of a user you are (how shit or expensive your hardware is), and running benchmarks to see whether you might be a fake browser/"ad fraud" user running large amounts of sessions at the same time and therefore have slower performance. It's bullshit and should be illegal.
I already dislike webgl leaking the model of my gpu, concurrency leaking memory and cores available, and disk space.
Go visit walmart or really any major site - almost more likely than not it will do this - and watch it attempt to enumerate all of your plugins, connect over webrtc, enumerate performance.* msPerformance, mozPerformance, make a webgl video and ask for unmasked renderer, enumerate thousands of fonts, attempt and fail to spawn piles of ActiveXObject, use "window.msDoNotTrack" as a fingerprinting feature point, enumerate hundreds of browser functions and getters (maxTouchPoints, doNotTrack, hardwareConcurrency, ...) and calling toString() on dozens of specific things like window.RTCDataChannel.toString() and seeing whether it fails in a try/catch, if it returns a function, or if it returns "function RTCDataChannel() { [native code] }" as a string, etc.
The numbers are intentionally imprecise for anti-fingerprinting, but I've seen JS code that treats users as suspicious or bad when your logical core count reports 1-2 but memory is 8+, or a lot of cores and very little memory, or if your device is non-mobile but reporting less than 4 or 8 GB of memory. The assumption is that you are a virtual machine if you're a "desktop or laptop" and have a single or dual core in 2022, for example.
Not only did the kids fail to get off our lawn, look at this giant hunk of poop they left all over it. Eternal September never ends.
--
Other sites and services will also use blocking them as a fingerprinting point. For example, it loads native first-party JS to try and bootstrap the rest of it.
A really simplified example:
Stage 1: on-page script tag, not a separate file, sets up a variable - let's call it "counter"
Stage 2: Load cross-site-tracker.js from obvious-analytics.example.com.
If it fails:
Stage 3: Load QyojK8oIwLjske2JkW9mdJY0Np.js from hqMOBRLccCmEnG9.cloudfront.net; increment a "shady user is trying to hide from us" counter
If it fails:
Stage 4: Load RandomWordsRainbowButterfly.js from N4NqCUJAT9UUXFcwnn.cloudfront.net; increment a "shady user is trying to hide from us" counter
Keep trying this through 3-4 domains, use random s3 buckets, cloudfront hostnames, akamaized.net hostnames. Upload all tracking data as soon as one of them succeeds.
What are you proposing that is not currently provided by https?
Ideally, I'd like to see every resource being served along with a signature verifying its authenticity, origin, and suitability for public consumption.
Users would then be empowered to make the decision whether we wanted to interact with a resource that does not offer these protections, and assume the risk, or simply refuse to load any resource that doesn't positively identify where it's coming from, who made it, and who certifies it as worthy of your consumption.
Though so few sites use it that your browsing experiencing would be awful if you made it mandatory.
Offer a spoof mode, make the Lockdown mode browser look to external websites like it isn't in Lockdown mode. Tricky but doable with some site breakage that can always be fixed by disabling Lockdown mode for sites a user trusts.
Convince as many people to use Lockdown mode as possible. I, for one, don't see any reason NOT to enable Lockdown mode on all my devices. Do you need iMessage URLs sent by randoms to load remote content without your consent?
Above all, lets begin to consider signed web content..