Hi, I'm James Darpinian. I post about various programming topics here, especially related to VR/AR, machine learning, and/or satellites.
You may have used some of the things I've made or worked on such as See A Satellite Tonight, Google Earth VR, and WebGL 2 in Chrome and Safari.
My Claude Code --dangerously-skip-permissions hat turned out even better than I expected! If you are also a fan of this alarming command line flag, you can get it on not just hats but stickers and T-shirts and mugs and a few other things you'll never guess before Clicking Here!
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", they say. Users understandably trust Apple to get this right, and believe that their messages are secure even from Apple. However, that trust is misplaced. Most people's expectations about the security of iMessage are incorrect. Here are four of them.
The truth is that in Apple's intended and recommended configuration of iOS, 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 prototol or implementation. This is working as intended and documented (but not advertised) by Apple.
This Apple support page describes exactly what is encrypted and how. What you need to know before reading this page is that "In transit & on server" encryption is definitively not end-to-end encryption. Apple can and does read information that is encrypted "In transit & on server".
In this table, in the "iCloud Backup (including device and Messages backup)" row, under "Standard data protection", the "Encryption" column reads "In transit & on server". Yes, this means that Apple can read all of your messages out of your iCloud backups.
"Look", you might say, "the line in that table for 'Messages in iCloud' says 'End-to-end'. I have that enabled, 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"!
"Hey, but if I disable iCloud backup, then finally my messages are secure, right?" Well, two things about that.
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.
Secondly, this doesn't even solve the problem. 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.
I am glad that Apple offers the ADP 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, with brute force protection provided by HSMs in the datacenter. This enabled Google to turn on end-to-end encryption by default for everyone. With little risk of data loss, no opt-in is required.
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 through their iCloud backups, since they are overwhelmingly likely to have backups enabled and overwhelmingly unlikely to have proactively enabled the non-default "Advanced Data Protection" feature.
Good luck with that!
Apple sure isn't going to help you out. They could have implemented iMessage to not backup messages from people who enabled ADP, but they didn't. They won't even inform you when your conversation partner has uploaded your messages to Apple's servers in a form that Apple can read. This is not a practical solution.
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. iMessage has a specific integration with iCloud and is in full control of how Apple's iCloud servers store your messages. Ultimately it doesn't matter whether you want to draw artificial boundaries within which you can call it "end-to-end encrypted"; the fact remains that Apple can read your messages.
Not in this case. As noted above, Android's equivalent cloud backup service has been properly 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 backups can be fully protected. Android is in fact better on this one.
Google's Messages app did take longer to implement end-to-end encryption on the messaging service side. But it is implemented today, and now the main reason a message wouldn't be properly end-to-end encrypted in Google's Messages app is when communicating with an iPhone user, because Apple has dragged their feet on implementing RCS features in iMessage. Apple prefers blue bubbles to work better than green bubbles for iMessage lock-in, but that's a whole other story.
This is false. Some do, but some don't.
Users put a lot of trust in Apple, and they should be able to believe in the most straightforward interpretation of Apple's statements. 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. By trusting Apple's misleading claims, most iMessage users probably hold some or all of the four incorrect beliefs listed above.
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. Furthermore, Apple does do end-to-end encryption by default on other critical information that would be painful to lose, such as your account passwords stored in Keychain. So that excuse doesn't seem to hold water.
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 the local storage of an iPhone, which is commendable. But in private, it sure seems like they caved on the iCloud backup issue, leaving a gaping hole in the security of iMessage and iPhones generally.
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: