> If you can’t stand the impact on performance or image rendering, well, maybe Lockdown isn’t for you. Apple claims only a tiny fraction of users will need it, though I’d argue an awful lot of users will want it.
Of course, I want it! (I already go through many other inconveniences for privacy and security).
> Should You Turn it On?
> Yes. Seriously. Turn it on when you have a supported OS and don’t look back.
Amen! I’ll be telling some laypeople to turn it on and try it out (along with instructions on how to turn it off selectively or completely).
Already pointed out this issues in a prior point here 14-days ago:
https://news.ycombinator.com/item?id=32006436
From that comment: “If Apple is logging if this feature is on and sending it back to Apple, it will result in targeting from nation states even if this feature is “invincible” - which I have no reason it is; basically, nation states demand list of users subject to its jurisdiction.”
Obviously there are likely other ways to fingerprint Apple devices with lockdown mode on, but to me, at the point you need “lockdown mode” likely should realize the doing so will likely make you more of a target.
If Apple tracks users that have both lockdown mode and iCloud on, all a nation state with jurisdiction has to do is request list of users with both on; having lockdown mode on might even qualify as justification for a search warrant and legally hack anyone using it, which is already the case for Tor:
https://www.nolo.com/legal-encyclopedia/what-does-rule-41-sa...
Find it horrifying that Apple has this feature, but makes no effort to inform users about the risks of iCloud; in my opinion, if you have lockdown mode on, iCloud should not be option, should trigger an off boarding from iCloud and wiping of any data on iCloud; also pointed this out in comments here:
https://news.ycombinator.com/item?id=32006436
To me, as is, lockdown mode sounds like a honeypot:
The point of this feature, is to protect you, who live and are an upstanding citizen of [a country that is in the same vague "Western" political network as Apple itself] — but who have something that other nation-states want, like trade secrets — from APTs launched across the internet by cyber-privateers tacitly sponsored by those other nation-states.
Under such a threat model, who cares if Apple has your fingerprint, and if the US government can get said fingerprint? If you're a US citizen and in this situation, the US government probably very likely already have a close working relationship with you, having likely tasked the NSA to work closely with you to ensure that your "key industry" company doesn't suffer any GDP-damaging attacks.
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..
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.
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
What are you proposing that is not currently provided by https?
Apple (and most for profit entities), tend to exclude themselves from their definition of "privacy".
You have to explicitly opt into any logging in apple apps and the OS itself (iOS or macOS). Apple clearly goes to great lengths to ensure that they cannot access your information and data, and very clearly distinguishes stuff that is inaccessible to them from stuff that is encrypted but that they can technically access decryption keys.
A result of this is of course that we get people complaining about apple not restoring their data.
What you're doing is demonstrating how effective Google, Facebook, etc have been in convincing you that real privacy isn't actually possible, solely to protect it from legislative action, because their business models depend on violating it continuously
Recall that Google deciding to trawl through the content of your email (assuming gmail) is why emails from amazon no longer include any details about the order.
Or how "AI" required Google and Facebook, et al having access to everyone's pictures and information.
The fact that G and FB have taken a "fuck our users" approach, doesn't mean that's how every company operates. The fact of the matter is that >75% of google's revenue comes from selling you out, and >90% of facebook's. >80% of apple's revenue comes selling hardware, the remainder from selling services and I assume store royalties (I'd be interested in the break out). You don't have to invade everyone's privacy to make money, it's just G and FB have chosen that approach every time the option is presented to them.
In fact, if a company can decrypt your data then it becomes possible for a hacker of said company to also decrypt that data - a fairly solid reason IMO for either not collecting, or ensuring only the user can access info, unless absolutely necessary for functional or legal reasons.
Looking at non-consumer security mobile phones (like the one from Boeing) or those that are modified to be secure (like the Blackberry used by Obama) they all seem to employ this less-is-more approach to security.
In other words, what's the minimum tolerable feature set we can offer without further compromising security? It follows from the question 'why use a phone at all? If there is a functionality the client can't do without, then how do we provide just that without any security downside?'
It's a sensible approach which means Apple has just entered this market. Not in a big way yet - phones are made in China, modem chip firmware security has a long way to go. But lockdown is just beginning too and it shows Apple understands this is serious.
But all this is just defense. Next step is the entire industry. Finfisher is done - next up: NSO, Candiru and Darkmatter, their investors, suppliers and scumbag employees before they dissolve/rebrand and scurry back out of the light.
The fascinating this is that this parsing would happen on a process which even _has_ privileges to trigger any exploits. Parsing a message should be done far far away from the core OS operations, high in userspace, by a sandboxed process that can't break anything.
Based on previously seen exploits, it seems messages are handled by rather privileged processes. I wonder if there's a reason for that (e.g.: special messages can trigger privileged operations?)
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
From the conclusion of the second post, which analyses the sandbox escape:
> Perhaps the most striking takeaway is the depth of the attack surface reachable from what would hopefully be a fairly constrained sandbox. [...] The expressive power of NSXPC just seems fundamentally ill-suited for use across sandbox boundaries, even though it was designed with exactly that in mind. [...]
(The above is severely cut down, reading at least the entire conclusion or even the whole post is worth it)
https://googleprojectzero.blogspot.com/2022/03/forcedentry-s...
I have. Mostly in the context of how this grandiose sandboxing scheme was just bypassed. Again.
- It would be really nice to be able to disable Lockdown Mode for specific people in iMessage the way you can for specific websites in Safari. I'm guessing you can't because the sandboxing isn't implemented the same way it is in Safari...but maybe that should be fixed!
- Disabling WebRTC in Lockdown Mode is probably an overall win, but it may result in certain web-video-conferencing tools not working. In most cases, the correct answer will be "then install the app for that instead", but it may result in a few issues. On the other hand, users can also disable LM for those sites (and I like that you can do it easily, so I could do it temporarily and then flip it back off afterwards).
- It will be interesting to see if the ability to turn this on is a feature available in MDM. I can imagine companies mandating that users traveling to certain areas of the world must have LM MDM-force-enabled on their phones at all times instead of taking a burner phone.
- I wonder how the prohibition on wired accessories will work if the phone is unlocked when the accessory is plugged in. As an example, with LM enabled I could plug my phone into my car and use CarPlay, but does it then turn off when the phone locks? I'm assuming not, but if you're going full-bore-privacy-protections, there's an argument there that it should actually just disable the port fully when the phone locks (and that's certainly the easier option to code).
That only solves a few of the possible issues a content-free burner phone solves, though. I sure wouldn't travel to those bits of the world with a regular device with all my information on it. Rubber hose cryptography is a thing.
twitter did this too a while back, they made a big show of how they're supporting tor now, and now whenever i click a link to a tweet via tor, it redirects me to their frontpage.
thanks, can you stop supporting tor now please, so I can use the site with tor again?
It's a '<meta http-equiv="onion-location"' tag, and it points to the base URL even on the blog pages. I'll get that fixed to point to the actual page of interest (should be easy enough in Jekyll to just re-render things). It's handled client side in your browser, so you should be able to tell the browser to ignore that.l
But as far as I can tell, the Onion address is up and operating.
It seems any time a post of mine makes the HN rounds, I get some other weird corner case of my site pointed out, and it does improve things over time! Jekyll makes it easy to just re-render the site with changes like this too.
I'd missed that in testing - I went to the root domain, and it redirected properly and let me browse to pages, but I never went directly to a post, on a browser that wasn't already aware of the redirect. Thank you so much for pointing that out!
The list of lockdown features don't seem to explicitly list that in-house app sideloading is disabled - is it? If not, then this mode seems like security theater from Apple, in that it doesn't actually lock down the parts of the attack surface that are actively being leveraged. How about instead, or better yet alongside this, Apple explains how they granted entry in the Enterprise program to the spyware company, and what measures they're taking to prevent it from happening again.
Im pretty sure that iMessage is one, if not the most targeted parts of the iOS ecosystem for practical exploitation. Disabling link previews and restricting the formats that are rendered likely renders this much more difficult.
The side loaded app would likely have to target non technical people as i'm pretty sure side loaded apps require lots of clicking through and trusting of certificates to get to run on a phone.
(From the article)
So this would have prevented Hermit as you'd need to install a new configuration profile to allow sideloading of applications from that source.
Are you sure that's true? I haven't seen a Hermit sample firsthand, but from everything I've read about it targets did not need to install an MDM profile, they simply needed to click a link. Looking at Apple's distribution guidelines - https://support.apple.com/en-bw/guide/deployment/depce7cefc4... - MDM is listed as one option, and simply going to a link is listed as another:
> There are two ways you can distribute proprietary in-house apps: > > Using MDM > > Using a website
It seems like the latter was used, so I don't think installation of a custom profile was required, which brings me back to my original question of whether Lockdown would have prevented it.
Obviously with the new EU legislation mandating support for unrestricted malware of this kind, that's kind of a moot factor in EU and EU-adjacent markets.
"What is Apple doing to prevent any government contractor from being able to use enterprise apps?"
Which is what you're actually asking. "Spyware" sounds like you're conflating with its traditional meaning of being a general consumer malware/virus plague. This is software made by companies that provide services and support for [among others] intelligence agencies, etc for actual targeted spying.
If you disagree with that being the actual question, then you're saying that having access to the enterprise is dependent on Apple auditing your entire company, its corporate hierarchy, its owners, and its executives - at least. That isn't going to be cheap, it isn't going to be fast, I'm sure you'd not be happy as a company to find distributing internal apps suddenly requires regular expensive audits, or as an employee to discover your employer now required you to agree to background checks, etc by Apple.
The whole, and it seems only, reason for the enterprise program was so companies ("enterprises" in marketing) could have internal apps that didn't have to pass the App Store review process.
It would have been vastly easier to convince a victim to install a piece of software from the App Store, but that would not have worked because despite naysayers the App Store as a first step in platform security works. Otherwise there would be unending stories of malware on HN :D
Enterprise-signed apps require an explicit (and non-obvious) action from the user when running for the first time.
I firstly don't believe this is true at all, plenty of high-level targets are not tech savvy; but more to the point of Lockdown mode, you could then say the same thing about most of its other features ("High-level targets are likely to already be aware of the dangers of doing $thing_Lockdown_prevents").
This requires an atypical install/launch process that you'd hopefully trigger some sense of "this isn't right" - similar to the macOS complaints when you choose to run an unsigned app.
It's super hard to make an exploit work when you don't know what options your target was compiled with.
Also, simple things like swapping malloc implementations or changing some parameters of malloc will pretty much make your device immune to state sponsored attacks.
Also, anytime you see an application crash, record all crashdumps - since they will contain evidence of a failed exploitation attempt.
That's an amazing marketing spin. It's not their admittance of failure of engineering to make the features secure, no, it's a groundbreaking security capability! To be fair, I do appreciate that they acknowledge the problem in the first place and are trying to do something about it.
For example, I'm assuming "configuration profiles cannot be installed" will only to apply to unsupervised devices. Otherwise it could make Supervised Mode rather, erm, tricky !
Also "Allow access to USB accessories when device is locked" option has already been available in Supervised Mode for years.
So I wonder if Lockdown Mode is more removing some of the "supervised only" restrictions from certain options (e.g. the "USB when locked" is currently "supervised only" option, but it looks like Lockdown Mode will bring this option to all users).
Overall, I think this is a good move by Apple though even if some of the details remain to be seen.
<Insert rant about how I miss my Windows 8 phone because it had less crap on it here.>
The only thing I saw in the writeup that I can imagine normal people over 25 missing is web font icons, and maybe emailing PDFs around to sign with iMessage. (Though those come in as jpegs from cameras or PNG screenshots half the time anyway...)
Also, since you can turn it off for specific domains, it's easy enough to re-enable WebGL for some site, while still having Lockdown mode apply to all the random ad serving backends and such you come across. If you're not someone who might be specifically targeted, I think that's entirely reasonable. Secure by default, drop the security level somewhat, by concrete actions I've taken, for some site I want to do something more on.
At some point, I'd assume attackers will try to get people to turn it off so they can attack, but you've made an awful lot more noise by that point.
They do not.
The page preview included in Messages is created on the sender side. On those occasions the sender can't create a preview you get a "click to load preview" message instead of a preview with the url. In other words, nothing more than just sending the url in the first place. I'm curious what "disabling link previews" actually means in lockdown.
Hence I want clarification on what is involved here.
[edit: s/server/sender/]
Here is some irony: the linked article caused Safari on my iPhone with beta iOS 16 and Lockdown Mode to immediately crash every time I visit the page (about 5 tests trying to load the page). I have not seen that problem in any other web site.
How do 2 locked down phones that have not done so before do a facetime call? As neither one will accept the others call.
I am not sure why BMP is excluded specifically in lockdown mode. Isn't BMP 24bit simply a bit chunk of bytes filled with uncompressed rgb pixels? It don't even have any specific logic required to render. All you need is fill the render buffer with pixels.
It's been a while since the last bug in the JIT itself - fuzzing tends to uncover those pretty quick.
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
It exploited an archaic Xerox format parser to make its own virtual machine, and then went out from there.
So I'd agree, throwing anything on a webpage (or incoming message) into the "Can you parse this weird thing?" pipeline is a bad idea!
Right out of the box, smartphones are more secure than mainstream personal computers (running Windows, macOS or Linux) that are connected to the Internet.
