It’s usually harder to do for admins. They’re usually the ones who do the suspending.

UI designs are rarely exactly the same as the final product. There’s many tweaks that occur after the design is implemented. Sometimes doing exactly what the design requiress is too difficult or requires too many resources.

I’ve presented a few WWDC sessions including two video sessions, though nothing as huge as the keynote or platform state of the union. I can answer most questions you have about the process.

The screens shown in WWDC sessions are usually screen captures from real devices. Development of the slide decks starts with a template deck that has the styles, fonts, and color themes for that year’s sessions. It includes slides that look like the latest devices, with precise rectangles the right size where screen captures will fit. As people develop their sessions they use these slides as placeholders for screenshots, animations and videos.

During development of the OSes the code branches for what will become the first developer seed. Before WWDC, one of the builds of this branch gets marked as ready for final screenshots/videos. The idea is that the UI is close enough to what will ship in the first developer seed that the OS and sessions will match.

Once that build is marked, the presenters take their screenshots and those get incorporated into the slides.

You wrote “It wasn’t just a screen recorder thing”. What makes you say that?

You asked about specialized software. Apple OS engineers have to use what are called “internal variants” of the OSes during development. These have special controls for all sorts of things. One fun thing to look for in WWDC sessions: the status bar almost always has the same details, with the same time, battery level, Wi-Fi signal strength, etc. These are real screenshots, but the people taking the videos used special overrides in the internal variants to force the status bar to show those values rather than the actual values. That makes things consistent. I think it avoids weird things like viewers being distracted by a demo device with a low battery.

it’s sociopaths who lack empathy. And that leaves them behaving like capuchins. The one on the left is upset at the unfairness. But the one on the right doesn’t care at all. It just keeps taking its unfair advantage.

Part of that is the responsibility of the app developer, since they define the payload that appears in the APNs push message. It’s possible for them to design it such that the push message really just says “time to ping your app server because something changed”. That minimizes the amount of data exposed to Apple, and therefore to law enforcement.

For instance the MDM protocol uses APNS. It tells the device that it’s time to reach out to the MDM server for new commands. The body of the message does not contain the commands.

That still necessarily reveals some metadata, like the fact that a message was sent to a device at a particular time. Often metadata is all that law enforcement wants for fishing expeditions. I think we should be pushing back on law enforcement’s use of broad requests (warrants?) for server data. We can and should minimize the data that servers have, but there’s limits. If servers can hold nothing, then we no longer have a functional Internet. Law enforcement shouldn’t feel entitled to all server data.

Nintendo has free replacement for bad Joycons for life. It’s not some planned obsolescence conspiracy.

Side note: Any decent kid tracker thingies that respect privacy?

Apple Watch works well as a kid tracker if they’re old enough to wear it safely, and I think the privacy aspects are very good. It uses the FindMy network, and Apple can’t see the location. There’s a bunch of specifics here. Apple Watch used to require an iPhone, but Apple made it so you can add a kid’s watch to the family so it uses a parent’s iPhone instead.

I haven’t seen any evidence that this is solvable. You can feed in more training data, but that doesn’t mean generative AI technology is capable of using that in the way you describe.

Passkeys are a replacement for passwords. Passwords don’t solve the problem of a lost password, and passkeys don’t solve the problem of a lost passkey. How a site deals with lost credentials is up to them. It doesn’t need to be password + 2FA.

This article is 10 years old.

This is too techno-utopian. There’s also a place for governments. Comprehensive privacy legislation would also change the world for the better. Ignoring that is exactly what the largest invaders of privacy want.

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.

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.

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.

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.

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.

Also delete your expired certificate if you have one (for example after a year)

This is likely a bad mistake. Keep the old cert around.

There’s two possibilities:

The first possibility is that Actalis uses the same key pair for the new cert. This is not a great approach because it doesn’t defend against a leaked key or key overuse. After all, if the key can be trusted longer than a year, the first cert they issued should be valid for longer.

The second, and much worse possibility, is that renewing the cert gets a different private key. This can case data loss. Deleting the old identity means you lose the ability to decrypt any messages that were encrypted using that key! Even if your mail client stores the previously encrypted emails in decrypted form, you may receive a new email from a sender who does not yet have your new cert.

Actalis sends you your private key. This means they have access to your private key, and theoretically could use it to sign and decrypt your emails. A more secure but somewhat more complex system would use a certificate signing request (CSR) instead. In that case, you are the only person who ever has your private key, so only you can sign or decrypt your email.

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