Another year, another Apple iOS/iPadOS/MacOS release, right? But shortly before the iOS 16 betas dropped, Apple made an interesting announcement.
Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.
I’ve been reading up on it, and mostly found press releases about it, but I’ve not seen much in the way of actually messing with it. What is it, and what does it do? Well, I’m going to go a bit off schedule here and, between solar posts, do a quick set of impressions on Lockdown mode, with a focus on how it works in the browser - because that part just wasn’t well explained. Is the web still usable with it on? What features go missing? Keep reading!
Actually, before you do: These tests were performed in July 2022, on a 5th gen iPad, with the iPadOS 16.0 Beta installed. If you’re reading this a year later, yes. Things probably have changed.
Lockdown Mode: The Complexity Toggle
This is a bizarre post for me to be writing, because Lockdown is the sort of feature I’ve wanted for ages, and I know other people down my particularly weird rabbitholes who want this sort of feature. As a general rule of thumb, the more I want some esoteric feature, the less likely the tech industry is to implement it. And I can hack it into open source stuff if I care, or find a workaround, but to find such a niche feature in Apple’s offerings is an incredibly weird feeling. And I’ve got some thoughts on that later.
The launch features for Lockdown are listed on Apple’s post about it, but I’ll add my thoughts here.
- Messages: Most message attachment types other than images are blocked. Some features, like link previews, are disabled. GREAT! The SMS/iMessage parsing path is responsible for a lot of the initial entry points, because it’s the interface available to someone who knows the target’s phone number. Email is also a viable path in, but for a phone, this seems to be the weak point. And Apple supports a huge amount of insanity for this path. I mean, who doesn’t want their phone to support a late 90s Xerox encoding scheme for images that you can exploit to make a virtual machine? Only support the common stuff, and the minimal subset required for basic functionality. Plus, link previews are quite useful for an attacker. By sending a message to your phone, I might be able to make it reach out to a server I control, delivering a payload of whatever I want. Turning all this crap off is good.
- Web browsing: Certain complex web technologies, like just-in-time (JIT) JavaScript compilation, are disabled unless the user excludes a trusted site from Lockdown Mode. This is the core of what I’ll be looking at in this post, but as a lot of the various exploits over the years do something nasty with Javascript, going back to an interpreted Javascript seems of some value. But is it fast enough to still be usable?
- Apple services: Incoming invitations and service requests, including FaceTime calls, are blocked if the user has not previously sent the initiator a call or request. Again, excellent. These are all fairly complex endpoints, and the last thing I want an attacker to be able to do is freely request my phone to connect to something they control. This seems a good compromise, really - it’s not hard to work around (“Hey, I tried to Facetime you and it didn’t work, can you Facetime me?”), while still eliminating a lot of attack surface for a random phone number.
- Wired connections with a computer or accessory are blocked when iPhone is locked. I don’t know why this simply isn’t the default. But, again, it’s reducing the attack surface, while not entirely prohibiting the use of the wired port when the user has authenticated.
- Configuration profiles cannot be installed, and the device cannot enroll into mobile device management (MDM), while Lockdown Mode is turned on. Again, great! Configuration and MDM profiles can do almost anything on an iOS device, allowing random applications from not-the-App-Store to be installed, adding SSL certs for traffic inspection, and… really anything. So in Lockdown mode, you can’t add these. Excellent!
Most of these seem fairly straightforward - but the web browsing one isn’t, and so I’ve set out to poke at it somewhat and see how it works.
These tests are using iPadOS 16.0 on an iPad (5th generation). It’s not the fastest device out there right now by far, but it supports iPadOS 16, and I’d expect the relative performance to remain mostly the same across other supported devices.
Enabling and Disabling Lockdown
To enable Lockdown, Settings -> Privacy and Security -> Lockdown Mode. Turn it on. Once it’s on, in the browser, you’ll see a reminder under the address bar that Lockdown is either enabled or disabled.
It’s enabled by default for websites.
But if you want to disable it for a particular site, long press the “aA” menu on the left, select Website Settings, and turn it off.
This appears to legitimately disable it entirely - I don’t see any difference on benchmark performance between “Lockdown not enabled at all” and “Lockdown globally enabled but bypassed for the website.”
Browser Features
Apple claims that certain “complex web technologies” will be disabled. What are they? Good question!
My first stop was https://featurejs.com/ - a quick little library for determining what is and isn’t available.
With Lockdown enabled, the only thing that changes is that WebGL is no longer supported. Yes, this means that your favorite “crazy animated thing website” won’t work in Lockdown mode. So, over to https://browserleaks.com/ for a bit more analysis.
WebRTC
Apple has supported WebRTC for a long while, and with Lockdown disabled, one gets data on WebRTC support. With Lockdown enabled, though? Bazoop. No WebRTC!
WebGL
We know that WebGL is disabled in Lockdown mode, and the lack of support is confirmed here, too.
HTML5 Features
Finally, there’s a page that tests HTML5 features. I compared the JSON with and without Lockdown, and the following features are disabled in Lockdown:
- “HTML5 Audio MP3” goes from “true” to “probably.”
- “WebRTC Data Channel” is disabled.
- “GamePad API” is disabled.
- “WebRTC getUserMedia” is disabled.
- “MathML” is disabled.
- “WebRTC Peer Connections” is disabled.
- “Speech Recognition API” is disabled.
- “Web Audio API” is disabled.
Browser Image Support
How about images? Is there some difference in the image formats supported? Yes, indeed!
There’s a handy little “image format tester” floating around the web from about a decade ago.
With Lockdown disabled, Safari renders most of the images - only failing to support XBM, Photoshop, Targa, and SGI.
But with Lockdown enabled, the list grows. Now, the browser no longer will render TIFF, BMP (24-bit), JPEG 2000, or PDF images.
Wait, you say! PDFs? But I like reading PDFs in the browser! Well, too bad. With Lockdown enabled, you can’t.
You can still read them - they get downloaded and then you can open them by clicking in the downloads list. But they no longer render in the browser natively without user action. I’m not sure if the separate reader process is more sandboxed or not, but no longer can a website shove a PDF down your browser’s pipe to be rendered before you have a say in the matter - and that’s a very good thing!
I will say, though, I’ve noticed missing images on other random websites, including some that I don’t think should be exotic. A random PHPBB forum ends up with a bunch of icons missing. It looks like this with Lockdown disabled.
Enable Lockdown, and a bunch of icons just go missing. I’m not sure what format they are, actually. But you see stuff like this on websites often enough with Lockdown enabled.
Seeing your Lockdown Bypass List
If you bypass Lockdown for a site, you might, at some point, want to revoke that permission without having to go back to the site - and you can do that as well. Settings -> Safari -> Lockdown Mode gives you a list of sites for which you’ve toggled settings, with the ability to alter them from outside the browser, or simply remove them.
And if you want to simply remove all exceptions, you can do that too. Very nice.
Browser Performance
And now for the gigantic elephant in the room… browser performance. Javascript engines have been JIT (Just In Time compilation) for a long, long time now, and it’s fair to say that JIT is responsible for most of the performance of JS these days. Apple states they disable it, and that shows up in benchmarks rather clearly as well. So, how bad is it?
Weeeellll… pretty bad, actually. There’s a very real performance hit, at least in Javascript benchmarks. It’s a 2x-20x hit in performance. But, this doesn’t impact all aspects of web use - the rendering and such are still just as fast as before. Remember, if you trust the site, you can just disable the Lockdown mode stuff.
I’m comparing with a range of stuff I’ve used in previous benchmarks, mostly because I have the data laying around in a spreadsheet. No, this set of comparison hardware isn’t blindingly fast. I don’t care, it’s an older iPad, and the main takeaway should be the performance delta between “Lockdown enabled” and “Lockdown disabled.”
SunSpider is an old benchmark, but it’s still useful for lower power devices, and it’s quick enough to run. The 5th gen iPad, running normally, rocks this benchmark. Enable Lockdown, and performance drops by a factor of ~4.2 - significant. But it gets worse.
JetStream 1.1 is another common benchmark I use for lower performance devices, and the same pattern applies - a substantial slowdown (12.6x slower). No, you’re not reading that wrong. It does underperform the Pi3 on this benchmark.
Finally, Speedometer involves more than just Javascript, in that it tries to render a lot of stuff, quickly. Here, the performance delta isn’t as bad - only a factor of 1.94x slower. But it still beats out all the little ARM boards too.
But before you get too worked up about the absolute performance, remember, this is an old iPad. It’s got an A9 processor. Yes, you’ll see a hit, but newer devices are also a lot faster to start with. This is on the very back end of iPadOS 16 support.
Practical Performance
The benchmarks suck, but how does it work in actual use? I don’t use a lot of very heavy websites in the browser, but that which I do browse still works fine. All I can say is “Try it and see what you think.” You will feel a performance difference, so if you’re of the “Any slowdown is unacceptable!” variety, you won’t like it. And I have found some websites that seem to use image formats that aren’t supported under Lockdown, which is just bizarre to me. I’ll contact their support at some point.
But overall, I’ve not found it to be that much of a problem. Google Maps is still usable in Lockdown, even though zooming is a bit jumpy (2-4 fps vs a smooth zoom). Panning works fine, and everything else works, satellite view works fine… just two finger zooming is impacted.
It really comes down to “How much of the site performance is Javascript bound?” If it’s a Javascript heavy site, performance will be poor. Everything else? It seems to just work with not much in the way of performance impact.
So all I can say is, “Try it and see.” If you don’t like it for a particular site, you can turn it off for that site. 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.
Should You Turn it On?
Yes. Seriously. Turn it on when you have a supported OS and don’t look back.
If you’re in the web dev world, you’d do your users a favor by making sure your websites render properly with Lockdown on, because I’d like to think a lot of users will just turn it on and leave it on. You still have plenty of supported image formats, just stop doing silly things with them.
If you’re in the security world… well, you probably didn’t actually get this far before you turned it on, because you’ve wanted something exactly like this for years. “Not pwning my phone” is of greater value than some animated Memoji with synthetic heartbeats. And link previews are just annoying anyway.
And if you’re anyone else, turn it on, see how much it bugs you. If generic “number of phones enabling” it data is filtering back to Apple, and I have to assume it will, this is a “No, I don’t want all this complex crap ruining what could be a nice, secure little device!” signal to them. Maybe they’ll listen. Probably not.
Why is This a Thing?
Here, I’m off in some really speculative weeds (like most of our modern processors). I don’t work for Apple, I’ve never worked for Apple, so this is all “from the outside.”
But Lockdown is the nearest thing I’ve seen (by a major consumer electronics company) to an admission that you can’t solve problems caused by complexity, by adding more complexity.
To call modern smartphones “high profile targets” is to massively understate the problem. A smartphone, for most people, is literally the keys to your life. It has access to everything. And since it’s on you, it has access to you and your physical surroundings. A constant high bandwidth data connection, good microphones, cameras, a GPS, accelerometers, credentials to most or all of your online life… it’s everything.
As such, there are a lot of people who are very interested in being able to gain quiet backdoor access to it. I reasonably assume that any halfway decent nation-state can get themselves access to any computer they really want. But there are also the various companies that sell these sort of high end exploits to anyone with enough money - which seems to include a lot of nations that don’t have, and can’t hire, the skills to do this sort of work themselves. We’ve seen a steady drumbeat of “zero click exploits” against mobile devices, including Apple’s devices. Often enough, those are then used to “disappear” people who annoy a regime. And that’s just bad for the business of selling privacy.
The cat and mouse game has gone on for a while, but the latest wave of exploits against Apple were rather embarrassing. Various iMessage exploits were being used, so Apple added a sandbox called BlastDoor. And then attackers worked around it. The sandboxing was a classical example of “Solving the problems caused by complexity by adding complexity,” and it didn’t work. Whoops.
So Lockdown is, as I see it, going the other way. Instead of trying to parse all sorts of crazy stuff for a user’s convenience, you simply don’t do those things. Anywhere you can, you reduce the attack surface, and reduce the attacker’s ability to chain things together to create an exploit. But it’s an admission that the complexity of a modern phone operating system (or tablet, or desktop OS) have just gotten too much to handle, so the best path forward is to offer the option to not do those things. And for that, I’m very excited!
This is a companion discussion topic for the original entry at https://www.sevarg.net/2022/07/20/ios16-lockdown-mode-browser-analysis/