Apple has been touting iMessage as "end-to-end encrypted" for many years. "The first widely available messaging app to provide end-to-end encryption by default". Users understandably trust Apple to get this right, and believe that their messages are secure even from Apple. However, that trust is misplaced. Most beliefs users hold about iMessage end-to-end encryption are false.

Belief 1: My iMessages cannot be read by Apple under any circumstances.​

The truth is that in the default configuration Apple can read all of the messages you send and receive. This is not theoretical because they do, in fact, read people's messages and share them with third parties in response to requests. This is not due to bugs in the iMessage prototol or implementation. It is working as intended and documented (but not advertised) by Apple.

Apple can decrypt and read your messages stored in your Messages iCloud backup. This is documented in this table in the "iCloud Backup" row, under "Standard data protection", where the "Encryption" column reads "In transit & on server".

Belief 2: My iMessages cannot be read by Apple if I enable "Messages in iCloud".​

"Look", you might say, "the line in that table for 'Messages in iCloud' says 'End-to-end'. So that means my messages can't be read by Apple, right?"

Unfortunately for you, there is a footnote on that line. Follow it to read in part: "When iCloud Backup is enabled, your backup includes a copy of the Messages in iCloud encryption key". Now go back to the "iCloud Backup" line and note again that it reads "In transit & on server". Yes, this really does mean that Apple can read your Messages in iCloud encryption key from your iCloud backup, and then decrypt your messages. So much for "end-to-end encryption"!

Belief 3: My iMessages cannot be read by Apple if I disable iCloud backup.​

"Hey, but if I disable iCloud backup, then finally my messages are secure, right?" Well, two things about that.

1. Firstly, this is terrible! Apple's restrictive policies for iOS and the App Store prohibit any third party cloud backup solution for iOS. Apple is the only game in town, and if you don't like how their cloud backup works then there's no cloud backup for you! It's a pretty big feature to give up.

2. Even if you do disable iCloud backup, Apple can still read any message you send to a recipient who has iCloud backups enabled, and any message they send to you. Which is practically everyone, since that is the default and intended configuration of iPhones. So in practice, almost all of your messages are still sitting on Apple's servers in a form that Apple can read at any time without your knowledge or consent.

Belief 4: My iMessages cannot be read by Apple if I opt in to "Advanced Data Protection"​

I am glad that Apple offers the "Advanced Data Protection" feature. I think Apple's implementation could be improved by doing what Google did: securing the recovery method using your phone's screen unlock code. This enabled Google to turn on end-to-end encryption by default for everyone with no opt-in required and little risk of data loss.

Because Apple didn't do that, this has the same problem as the previous solution: Apple can still read any message you exchange with practically anyone, since they are overwhelmingly likely to have iCloud backups enabled and overwhelmingly unlikely to have proactively enabled the non-default "Advanced Data Protection" feature.

Common Objections

My iMessages cannot be read by Apple if I enable the optional "Advanced Data Protection" feature and also convince every other person in the world to do the same before we exchange our first message!​

Good luck with that!

The iMessage service itself is end-to-end encrypted​

Some argue that it is technically correct to call iMessage "end-to-end encrypted" because the iMessage servers themselves don't read the messages, it's the iCloud backup servers that do. This is a silly distinction that doesn't matter in practice. It's all Apple software and all Apple servers. Apple has full control, and the integration between different services is one of Apple's selling points. And if you still want to call iMessage end-to-end encrypted even despite all this, the fact remains that Apple can read your messages.

Google is just as bad​

Not in this case. As noted above, Android's equivalent cloud backup service has been end-to-end encrypted by default for many years. Meaning that you don't need to convince the whole world to turn on an optional feature before your own messages can be fully protected. Android is in fact better on this one.

Any other messaging app has the same backup loophole​

This is false. Some do, but some don't. We already covered Google's Messages. Signal does not use unencrypted backups by default, and they recently started offering an end-to-end encrypted backup feature. Telegram messages are not end-to-end encrypted by default, but if you do enable end-to-end encryption then backups are disabled. WhatsApp is more similar to iMessage in that backups are not protected by default, however it is a bit different because the backups are stored by Apple or Google instead of WhatsApp itself, so Meta itself can't read the backups.

Conclusion

I really believe it to be false advertising for Apple to claim "end-to-end encryption" for iMessage when the vast majority of messages are accessible to Apple to read at any time. Most iMessage users probably hold some or all of the four incorrect beliefs listed above. Users put a lot of trust in Apple, and they should be able to believe in the most straightforward interpretation of Apple's statements.

Apple's stated reason for not enabling end-to-end encryption on iCloud backups by default is that it would cause data loss when users lose their devices. But Google's implementation avoids this problem. There has been some speculation that the real reason for Apple's reluctance here is pressure from law enforcement, specifically the FBI. Apple stood up to the FBI in public when they declined to comply with a request to decrypt an iPhone. But in private, they may have caved on the default backup encryption issue.

The world of humanoid robots is exploding, and new demos are coming out seemingly every day. I'm keeping a list updated with every current humanoid effort that has at least a public demo video. You'll see dozens of projects at all scales, from one guy in his garage, to growing startups, to multinational conglomerates. Even if you follow the field pretty closely, I guarantee there will be at least one or two in this list you haven't seen yet. And there's even one you can buy right now! Scroll on to see them all, starting with some of the lesser known ones:

Another omnidirectional treadmill has been making the rounds this week. This one from Disney looks very cool, with a creative mechanism for moving the feet around that has a lot of advantages.

Unfortunately, the real issues with omnidirectional treadmills can't be solved by changing what happens at the feet, because the problem is all in your head. Specifically in your inner ear; your vestibular system. And this problem is unavoidable because it is rooted in the way we walk and ultimately in the laws of physics. So what exactly is the problem? And why does the idea keep getting traction regardless?

See A Satellite Tonight is my most successful side project so far, with 5 million users since launch in 2019. It's been entirely a solo project, and I've used it as a proving ground for a bunch of tech that I wanted to learn. It took dozens of APIs and services to put together the experience I wanted:

In this post I'll describe how it all works. Frontend tech, satellite-related calculations, backend tech, plus a little about my motivations for building the site.

You may know that all numbers in JavaScript are 64 bit double-precision floating point values. This is sometimes convenient and it works pretty well as a default for novice programmers, who are often confused by integer math, and rightfully so when 1 / 2 = 0. Unfortunately, it makes things slow. Doubles take a lot of memory and floating point math is slower than integer math on CPUs. It's also inconvenient if you want to port existing code to JavaScript, because existing code usually expects to use integer math.

Fortunately, there is a way to make JavaScript do integer math, and it works remarkably well!

Shower curtain tension rods are way better than tripods. They are cheap, strong, available everywhere, and designed to look nice permanently installed in a home. They work perfectly installed vertically floor-to-ceiling and take up only one square inch of floor space. Get a cheap camera mount and you're good to go. They also work for non-permanent installation of other small items like baby monitors or security cameras.

I've left a lot of comments on Hacker News since 2009, when I moved over from Slashdot. HN Search is great for finding old comments, but it can't see comment scores, which are private to the author of the comment. I thought it would be interesting to find my highest-voted comments, so I had to scrape my comments from HN myself. Here's how I did it:

I just moved some posts here from an old Blogger blog that I made many years ago. Now that all my posts are here I wanted to redirect the whole old blog to this new one. Blogger doesn't have a built-in way to do it, but it can be done! Here's how:

"Safari on Windows?", you say. "That's impossible! Safari doesn't run on Windows." And you're right! I mean it used to, but Apple stopped supporting Windows way back in 2012. Which is a bummer for web developers who want to test Safari compatibility.

But...