TaviRider

So even with BFU, does the iPhone not connect to the internet? I guess i hadn’t noticed it doesn’t.

Well, it’s complicated. Most of these topics are. In BFU state, an iPhone (or iPad with cellular) with an active SIM and active data plan will connect to the Internet. It won’t connect to Wi-Fi at all. If you have USB restricted mode disabled and the right accessory connected it will connect to an Ethernet network, but that may fail if the network requires 802.1x and the credential is not available in BFU state. Similarly if USB restricted mode is disabled you can use tethering to a Mac to share its network.

For location, there’s two mechanisms. One mechanism relies on directly communicating with the device, which only works if the device has network.

The other mechanism is the “FindMy network” which uses a Bluetooth low energy (BTLE) beacon to let other nearby devices detect it, and they report that to FindMy. It’s a great technology. The way it uses rotating IDs preserves your privacy while still letting you locate your devices. I know that this works when a device is powered off but the battery is not completely dead. I’m not sure if it works in BFU state… my guess it that it does work. But this is not networking. It’s just a tiny Bluetooth signal broadcasting a rotating ID, so it’s one-way communication.

Other than that, I’m not as sure how things work. I believe Bluetooth is disabled by default in BFU state, but I suspect users can choose to re-enable Bluetooth in BFU state to connect to accessibility accessories. I’m not sure about the new emergency satellite communication.

But one thing I know for sure is that Apple has world class security engineers, and one area they work hard to secure is devices in BFU state.

When you first boot up a device, most data on that device is encrypted. This is the Before First Unlock (BFU) state. In order to access any of that data, someone must enter the passcode. The Secure Enclave uses it to recreate the decryption keys that allow the device to access that encrypted data. Biometrics like Face ID and Touch ID won’t work: they can’t be used to recreate the encryption keys.

Once you unlock the device by entering the passcode the device generates the encryption keys and uses them to access the data. It keeps those keys in memory. If it didn’t, you’d have to enter your passcode over and over again in order to keep using your device. This is After First Unlock (AFU) state.

When you’re in AFU state and you lock your device, it doesn’t throw away the encryption keys. It just doesn’t permit you to access your device. This is when you can use biometrics to unlock it.

In some jurisdictions a judge can legally force someone to enter biometrics, but can’t force them give up their passcode. This legal distinction in the USA is that giving a passcode is “testimonial” because it requires giving over the contents of your mind, and forcing suspects to do that is not legal in the USA. Biometrics aren’t testimonial, and so someone can be forced to use them, similar to how arrested people are forced to give fingerprints.

Of course, in practical terms this is a meaningless distinction because both biometrics and a passcode can grant access to nearly all data on a device. So one interesting thing about BFU vs AFU is that BFU makes this legal hair-splitting moot: biometrics don’t work in BFU state.

But that’s not what the 404 Media articles are about. It’s more about the forensic tools that can sometimes extract data even from a locked device. A device in AFU state has lots of opportunities for attack compared to BFU. The encryption keys exist, some data is already decrypted in memory, the lightning port is active, it will connect to Wi-Fi networks, and so on. This constitutes a lot of attack surface that hackers could potentially exploit to pull data off the device. In BFU state, there’s very little data available and almost no attack surface. Automatically returning a device to BFU state improves resistance to hacking.

I’m glad you find this informative. It’s a topic that’s important to me both personally and professionally, and there’s a lot of wrong information out there. But the best and most reliable info is in the Apple Platform Security Guide, such as Activating data connections securely and Direct memory access protections for Mac computers.

In this topic I don’t think there’s any important difference between USB-C and lightning. Both form factors support a bunch of USB protocols as well as some Apple-only protocols, and both have USB restricted mode.

It’s more complicated than that. It’s called USB restricted mode. The lightning port is always willing to do a minimal subset of the protocols that it supports in order to do smart charging. By default most of the protocols it supports are disabled in BFU state. In AFU state it gets more complex than that. Accessories that you’ve previously connected can connect for one hour after the device is locked. This helps keep USB restricted mode from being really annoying if you briefly disconnect and reconnect an accessory.

USB restricted mode can be disabled by a user option (Settings > [Touch / Face] ID & Passcode > Allow Access When Locked > Accessories) or by a configuration profile. Disabling it allows accessories to connect at any time, and generally lowers the security of your device. But in some cases that’s necessary, for instance when you use an accessibility accessory to use your device.

If USB restricted mode is a concern for you, you should consider Lockdown Mode (Settings > Privacy & Security > Lockdown Mode). This changes several settings on your device to make it much more resilient to attack.

On iPhones and iPads there are several technologies available for monitoring and filtering network traffic. Filter network traffic from the Apple Deployment Guide has an overview of the technologies and their trade-offs.

It’s not that simple. iOS has a really sophisticated system for deciding which things to keep in memory and which to evict, and it only does that when it needs more resources. Choosing which apps to kill is based on how recently an app was used, how much of share resources are in use, how often the app gets used, if it’s doing background processing, and other more subtle signals.

Usually if people notice apps being killed when in the background a lot it’s because one of the apps they’re switching to is using a lot of resources, which forces the eviction of other apps.

Yes, device management systems can push apps directly to devices, but the devices have to be managed first. So I think it probably is about the lack of Google Play.

One of the hardest parts of managing devices is getting them enrolled in device management in the first place. Microsoft uses the Microsoft Authenticator app to authenticate users as part of the enrollment process, so they know which employee is using the device and how to configure it. They need a reliable app store to distribute that app, and they need to do it before the device is managed. So usually they rely on Google Play.

An old favorite of mine is Harvest: Massive Encounter. Expand, harvest, defend, optimize, and eventually get wiped out.

Elphaba from Wicked.

Releasing the app on the same day to the Apple App Store and Apple Arcade is a nice win for Apple Arcade.

I’d prefer a commander from Supreme Commander. It can raise an entire military by itself, and it’s much hardier than basic builders. It’s deadly up close. Even if you somehow defeat it, your reward is a nuclear explosion.

And IntelliSync, so you could have the same contacts in your PC and your Palm Pilot.