Two possibly confusing points about iMessage

Because of the way iMessage encryption works, iMessages do not sync, even if they appear to. Plus, you shouldn’t treat an iMessage archive as permanent.

Say you want to send me an iMessage, and I have three devices. You type in a message, hit send, and then the message shows up on my Mac, my iPad, and my iPhone. Those messages aren’t syncing. You are simply sending three separate messages from your device, each addressed to one of my devices–not one message that gets sent to three devices or syncs between them.

This is a result of the way that iMessage works: it has true “end-to-end” encryption. When you register a new device for iMessage, your device generates a public and a private key. The public key is put on Apple’s servers. The private key never leaves the device. When you try to send a person an iMessage, you check Apple’s servers to make sure you’ve got the public key for each device. You encrypt the message with the public key that corresponds to each device, for each device, and after that, it can be read only on the particular device the message was encrypted for. The message never travels in the clear, and it is never transmitted encrypted by anything other than the public key that corresponds to the private key that never leaves your device.

In other words: If you send a message to me, and I have three devices, you’re sending out three separate strings of random numbers, each going to a different place. No computer in the world, except the one you’re sending the message to, can have any way of knowing what’s inside each message. (I mean, an observer would probably be able to figure out that each message says the same thing. But that doesn’t help actually decoding what any of the messages say.)

The result of this is that if you add a new device to your lineup, there is no way for your message history to appear on that device. Each message that each of your existing devices has was sent specifically to that device. If messages synced between devices, or if there was a central store of messages that any device, including a new device, could read, then the entire security benefit of end-to-end encryption would be lost.

This is also why there is not, and never can be, a web client for iMessage. A web client would imply that a private key is stored on Apple’s servers, instead of on a customer-owned device.

Messaging apps that do not have end-to-end encryption can have all sorts of conveniences–new devices can sync, and you can have a web client accessible from any logged-in browser. But it also means that the company providing the service can read the messages, and turn them over if required to. Even if their systems are not easily structured to allow this, if a service has both the messages and the key required to read them, they are less secure than they are with a system where private keys are never transmitted anywhere or stored anywhere besides on the device that generated the,.

There is one important way, however, where messages are stored off your device, but encrypted in a different way: backups. Once a message has been decoded on your device it is simply considered to be part of your device’s data, no different that a Word document or an image. So if your device backs up–if it’s an iOS device, to iCloud, if it’s a Mac, to Time Machine, or to an online service like Backblaze–the messages leave your device, encrypted only with whatever encryption system the backup system uses. (On iOS, the private key is not backed up. They have specific hardware that hides the private key from anything else on the device. On a Mac, the private key might also be included in a backup, because it’s just saved somewhere on your hard drive.) This weakness would apply to various other encrypted communications apps as well–at some point, the message is decrypted on your device, and what happens to the message after that is another matter. Along with someone gaining physical access to one of your devices, this is probably one of the biggest vulnerabilities in end-to-end encrypted messaging apps. (Even password-protecting and encrypting the app’s message archive would mean that the messages are only as secure as your password.) A more secure solution would probably involve securely deleting your messages after you’ve read them.

Despite how the architecture of iMessage fights against this, people often want to use third-party tools to save message archives and somehow finagle them into new devices or at least be able to access them in another way. Maybe this works, and maybe if there’s important information in your archive you might have to do it, but I would suggest that with chat and messaging apps generally, you should probably embrace ephemerality. Not every digital communication should necessarily be stored for all time. Pick one form of digital communication to keep forever: say, email. If you want a permanent archive of a conversation, conduct it over email, not a messaging app, and if someone sends you an iMessage that you want to keep, screenshot it or save it some other way. If you go into iMessage expecting a permanent, always-accessible archive of all of your messages ever, you’re going to be disappointed, and it’s not the result of Apple just failing to support some feature you think it ought to, but the inevitable result of mathematics and the secure architecture Apple has decided to use for iMessage. And if you really do want a messaging system that, though less secure than iMessage, has all the conveniences that end-to-end encryption disallows, you should probably just use one of those instead.

You cannot send an iMessage to a phone number or email address, even if it appears you can.

iMessage is a private messaging system that has nothing to do with email or the telephone system, where user IDs are strings that happen to correspond with email addresses and phone numbers. iMessage could have used anything for its user ID system, and this is what it chose. Lots of services do the same thing. It’s as if, when you tried to order a hoagie at Wawa, and instead of giving you a number from a ticket or asking you your name, they asked you for your phone number. When they call out your phone number and hand you an Italian Shorti®, you wouldn’t say they were transmitting your Italian Shorti® over the Public-Switched Telephone Network (PSTN) or somehow sending it to your cell phone. Instead, they are clearly using your phone number as an arbitrary unique string; they could have used anything.

iMessage works under the same principle as Wawa in my example: when you sign up for it, it checks to see if you really do control the phone number or email address you give it, both to make sure they are unique to its system and to prevent you from impersonating someone. But after that, when someone sends you an iMessage, they’re not really sending it “to” your phone number or “to” your email address–they are sending the message to an iMessage ID that, looked at merely as a sting of characters, is identical to your phone number or email address.

This is all obvious, so why do I belabor it? Well, as I’ve written about before, there are issues like “Can I text to 911” where these details can have pretty big consequences. But with most systems where you use a phone number or an email address as a user ID, there’s basically no possibility for confusion. I have to log in with a phone number as a user ID to manage my mobile phone service. On most sites on the Internet, I log in with an email address. I don’t see how there’s any possibility for confusion there.

But iMessage silently intercepts text messages! On iPhones, the SMS client is the same as iMessage. If you try to send an SMS to someone, the client checks Apple’s servers to see if that person uses iMessage, and if so, sends an iMessage through Apple’s servers instead of a text message through the phone system. Using phone numbers as user IDs makes this pretty seamless–but it does lead to some problems, and those problems are caused by that same seamlessness. Say, for example, you change your actual phone number. iMessage problems can result from both iMessage not knowing you have the new number, and from the system not knowing that the old number is no longer active. So people might send you messages, and they’re not rejected, but there’s no device they’re delivered to. Or they might try to send an iMessage to your new number, and it fails, since iMessage doesn’t know about the new number yet. Because it’s using your phone number but is not part of the phone system, the two can get out of step. This also leads to the recurring issue where someone switches away from an iPhone and when iPhone users try to send SMS messages to that person, they get send via iMessage instead, and lost.

iMessage would not be as successful as it is unless Apple built it as it did–and it could probably solve most problems if there were some manual way that people can remove their email addresses and phone numbers from iMessage in the instances. One difficulty with this is that it’s not required to have an Apple ID to use iMessage–you can set up an iPhone where the only Apple online service you use is iMessage associated with a phone number. So in that circumstance, if you get a new phone, Apple has no real way of knowing who that phone number belongs to, making a self-serve tool likely a bad idea. But that’s another consequences of the low-friction way Apple chose to design its service, and not my problem to solve.

Apple Music Has Failed at a Goal Not Worth Pursuing

Nearly every serious problem or misunderstanding I’ve seen myself, and reported by others with Apple Music has to do with iCloud Music Library, its confusing attempt to integrate a user’s existing music library of local files with the streaming service, and, more broadly, with this entire concept of a “library.” Just look through Serenity Caldwell’s troubleshooting guide. It doesn’t work right, but even more fundamentally it’s a pointless exercise.

When it comes to Apple Music, the streaming service, your “music library” should just be the Apple Music catalog. You can make playlists from this and save them offline. No further concept of a “library” is necessary beyond this. If you want to have the equivalent of a “library” you should just be able to create a very large playlist that you can view in different ways. You can even have a smart playlist that shows you all the music in your other playlists. Why is Apple trying to replicate the mental model of a record collection in the cloud, and introducing a somewhat baffling extra layer of hierarchy?

But what, you ask, about your lovingly-curated library of music files, with much music that’s not available on the streaming service, or might just drop off of it because of licensing vagaries? Well, Apple should still offer iTunes Match, even integrating it with with Apple Music. You should still be able to upload or match (to DRM-free files) your local music files, have them live on the cloud, and even have playlists consisting of both Apple Music and Match music. This collection of music you own, instead of renting access to, is indeed a “library.” But there shouldn’t be this concept of a unified library consisting of music you own and music you don’t. To the extent the “library” concept makes sense it should be this cordoned-off area for music the user owns that does not mix with DRM-laden streaming-only tracks. Did you know that if you add music to your iCloud Music Library from Apple Music, you can actually edit the metadata? What is the purpose of this feature, other than to be confusing as hell? When I go to the public library I don’t demand the right to re-title books and alter the dewey decimal system.

This wouldn’t solve issues with how iTunes’ scan-and-match feature itself is subject to errors that are hard to track down, but cordoning off the error-prone matching (and limiting it to the desktop) would solve a lot of the recurrent problems. Ideally, iTunes would be maintained as a local file management program that can perhaps upload tracks to the cloud, with extraneous features like iOS syncing gradually taken out of it, and with Apple Music existing as its own set of apps.

As for me, I’ve been happy with Apple Music, once I figured out its quirks, because I’ve totally given up on Apple managing my music. That I currently am just storing in organized folders, like the old days, that I back up to the cloud, not like the old days. (I listen to this music on the go with the very useful app nPlayer.) Apple’s made a fine streaming service, but it has not succeeded in its goal of being a one-stop-shop for every digital music modality, which isn’t the worst thing in the world, because that’s a stupid goal anyway.