[O__________O]

Have you ever study fingerprinting, read the linked post that’s the subject of this thread, understand how prior advanced targeting attacks using fingerprinting worked, etc?

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.

[mrex]

How realistic is an "advanced fingerprinting attack", though?

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!

[O__________O]

Sorry, but I don’t understand what technically you describing.

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.

[camyule]

> 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.

iCloud Private Relay already exists.

[O__________O]

Official Apple Support page:

https://support.apple.com/en-us/HT212614

3rd party description of it:

https://blog.cloudflare.com/icloud-private-relay/

[mrex]

I wasn't suggesting proxying anything, just that the browser should attempt to correct errors that it introduces into page rendering when it spoofs feedback to the server.

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.

[O__________O]

If I had a sense of superiority, why would I even be taking the time to attempt to understand what you’re saying, makes no sense.

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.

[mrex]

>Just makes no sense to have such a complex system

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.

[O__________O]

No. Whole point of disabling long list of functionality mentioned in the article is so that — no - code is executed via that functionality on the device at all. You are suggesting something that go against whole point of turning it off. Browser already operates in “untrusted” mode. Apple’s iPhone systems and hardware are not designed to be separated. Even if the hardware was duplicated and completely isolated, the secure hardware would be in close physical proximity to non-secure hardware and as a result would be vulnerable to side-channels leaks and/or attacks.

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.