It does make iOS slightly more inconvenient, such as when adding each other on iMessage. And it severely reduces JavaScript performance in Safari. I think Apple wants to avoid making iOS feel slower or clunkier than Android. And zero-day spyware is usually targeted towards important individuals, not used for mass surveillance, so it indeed is a smaller risk to individual people.
I'd prefer a third mode that compromises between the two, perhaps letting you lower your security for a few minutes when you need the extra functionality. For example, Safari could detect when JavaScript is being slow and pop up an offer to re-enable JIT.
I would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.
That fact that Apple blended iMessages, SMS text messages, and email into an extremely confusing mess may also be the reason for so many security issues related to iMessage. Perhaps not directly responsible for this particular NGO exploit, but I find iMessage's logic and behavior bewildering at times.
For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But if you stop using iMessage, then you can no longer send a normal SMS to someone with whom you've communicated before using iMessage. The Messages app will tell you, "You must enable iMessage to send this message", even if it's an SMS text message to a normal phone number! Why shouldn't that work?
To be able to again send SMS text messages to someone you used to talk with is to disable iMessage of course, then sign out of Facetime (who could imagine that as a necessary step?), sign out of iCloud, reboot the iPhone, and wait some minutes to hours to days until you are "deregistered" from iMessage. I'm talking about the same phone with the same SIM chip. The problem can become much worse if you've switched phones or SIM card.
The source code for iMessage must be a nightmare having integrated SMS and email and a new messaging system all together.
There is no email (the protocol) in iMessage (the app). You can use somebody's email address as the recipient for an iMessage (the protocol). No email is ever sent.
You can type in a contact with an email address by just their name and send an email from iMessage. I have done it to contacts accidentally many times.
I think sending SMS to emails and receiving SMS from emails is a functionality of the mobile network. You should be able to do that in any app that can send/receive SMS.
The point is that those other apps don’t use email addresses as the handle to contact someone. If someone iMessages you, the iMessage might (appear to) come from their phone number, or it could (appear to) come from their email. If you have an iMessage contact that’s just an email and you iMessage them, it works fine. If you try to then add Android users to your group chat, everyone gets SMS and the iMessage user with an email handle gets an empty body email from AT&T with an attachment containing the SMS as a plaintext file. And then this user gets another empty email for every reply to that group text.
I'm fairly certain that "text to email" is a feature of MMS - I've used it a few times years before iPhones were around.
I don't remember if MMS is enabled by default in iOS but theres a toggle to disable it, and realistically there's very minimal real world use-case for MMS these days.
Yes, it’s an MMS feature. But iMessage makes it way too easy to “text to email” inadvertently when you start a group chat with some non-iPhone users. MMS sucks but it’s the universal way for iPhone and Android users to communicate without needing everyone to be on the same third-party messaging platform like WhatsApp. In my US-centric personal experience, there is no universally accepted messaging app you can be certain that everyone is on.
Oh, I have never come across that because I have avoided MMS like the plague ever since WhatsApp/Signal/any other cross platform messaging option with media capability became available.
On Apple's end, iMessage also supports email addresses as a user identifier (and it's the only one you get if you don't have an iPhone with an assigned phone number).
It's still not sending emails, though. The iPhone Messages app sends SMS, MMS, and iMessage; email is the responsibility of the Mail app.
The point is that iMessage lets you send to any contact and it’s not clear if it will send to their iMessage, which uses email as an identifier, or to their actual email inbox through mms.
It is clear in a non group conversation, since the contact will show up in a blue color in the “to” field.
In an MMS, it could be unclear, but only if you choose to put an email address in the “to” field. If you know it is an MMS, and you only use phone numbers, then it will not be an email.
> For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But if you stop using iMessage, then you can no longer send a normal SMS to someone with whom you've communicated before using iMessage. The Messages app will tell you, "You must enable iMessage to send this message", even if it's an SMS text message to a normal phone number! Why shouldn't that work?
To be able to again send SMS text messages to someone you used to talk with is to disable iMessage of course, then sign out of Facetime (who could imagine that as a necessary step?), sign out of iCloud, reboot the iPhone, and wait some minutes to hours to days until you are "deregistered" from iMessage. I'm talking about the same phone with the same SIM chip. The problem can become much worse if you've switched phones or SIM card.
That’s simply not true. I just turned off iMessage and instantly switched to the Message app and sent a SMS to someone I have a iMessage chat with and it worked without any problems
Don’t use SMS instead of iMessage though. Then all your texts will be sent across the network without any kind of decent encryption. And WhatsApp is almost unusable unless you consent to uploading all your contacts to Facebook. (IIRC this was the red line that got crossed that caused the WhatsApp founder to quit FB post-acquisition.)
Signal is a good recommendation, but you won’t be able to convince 100% of people you need to interact with over text to use Signal. You might convince friends and family, but not acquaintances or random people who might need to text with (like your electrician etc.)
Given the tradeoffs, iMessage is pretty good for day-to-day messaging.
It's a tradeoff. Do you want messages from strangers to run through a bunch of parsers that historically had problems, or do you want to take advantage of your peer group using iMessage.
I'm outside the US, so I don't even need to consider. Nobody here uses iMessage, even the people with iPhones.
It works but it shows phone numbers rather than contact names and you can’t assign a name to a number without giving access to your entire contacts … it ticks me off.
That is because iMessage has the same function as the night men in the Eagles song Hotel California:
"Relax,” said the night man, “We are programmed to receive
You can check out any time you like but you can never leave"
Somehow fittingly that song is about the excesses of American culture ... also about the uneasy balance between art and commerce [1] according to one of its authors, Don Henley while also having been interpreted as being all about American decadence and burnout, too much money, corruption, drugs and arrogance; too little humility and heart and a metaphor for hedonism, self-destruction, and greed ....
> I would argue that iMessage is way to problematic to be used safely, at all.
Maybe I'm missing something but every single time the only part of iMessage (actually Messages.app) that is insecure is the bit that automatically unfurls attachments and the payload is exploiting a vulnerability elsewhere. So any other app unfurling the attachment thus triggering the payload would be equally vulnerable.
Imagine ping had a privilege escalation vulnerability and someone does ssh foomachine ping <payload> to get root, it'd be a bit weird to call out ssh as being unsafe because it can execute commands, one of them being able to privesc.
Disabling ssh would be a mitigation, and I do wish Messages would disallow unfurling for senders not in the recipient's contact list.
imagent runs as root and processes incoming messages. whatsapp or signal or whatever cannot ship an unsandboxed always on daemon like imagent.
signal/whatsapp/etc have to parse incoming messages inside the app sandbox. iMessage doesn't.
(I'm saying this all very confidently because the quickest way to get the right answer is to be confident about the wrong one and get corrected by a techbro)
Why would they give that specific process (imagent) that much privilege? Can nefarious motives be inferred from such a choice? It seems pretty damning to me that a glorified GIF processing helper is given root access to the entire system. It just doesn't add up that this is all accidental.
What are the odds that something like the NSO just happens to luck into being able to remotely initiate and sustain the building of an entire Turing-complete internal and unauthorized computer internally that also happens to be able to override all hardened protections to the contrary? It just seems so unlikely that there was not a hand in facillitating this internally at Apple. That's what happened with the GreyKey guy...
IIUC (from a cursory look) according to the diagram it delegates all message processing to MessageBlastDoorService/IM{Transfer,Transcoder,Persistence}Agent, relying only on locally computed boolean-ish metadata replies from these services, and merely transparently forwarding actual data between those.
I'm no security pro, but last night I iMessaged a friend a TikTok video and according to him, the link initiated an App Clip. Perhaps it's totally safe and I'm just naive but it just seems like the risks of a link initiating code like that outweigh any rewards. Even if it's totally safe and all involved can be trusted, that experience is enough to creep me out.
There’s been a long history of them, and an entire industry doing things like filtering attachments or rendering HTML emails in sandboxes.
I think the original poster made an attribution error: iMessage gets attacked because it’s popular. If it didn’t allow you to receive rich messages from anyone, people would switch to other apps which do and there’s a long history of those being exploitable, too. What makes iMessage special is that you can assume an iPhone user has it enabled without having to check whether they use WhatsApp, Telegram, Facebook Messenger, etc.
There have been! One was in Microsoft Outlook parsing email subject lines, so you had to do was recieve email in order to get hacked. And there was another one around when heartbleed was a thing that had to do with parsing of the DNS lookup and response of who the email was coming from.
> It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.
If you are using a phone, you have a phone number. Targeting the phone and SMS handling apps will always be the go-to vector for these sorts of attacks, because you don't want to tell your customer that they can only spy on targets that have Evernote installed and configured.
I agree, and there really need to be controls on it. I understand they want the "IMessage Network" to have predictable functionality, but I care about security more, and IMessage has been demonstrably unsafe for a long time.
I would really prefer to keep it text-only, and am fine with the goofy symbols. If they want to make photo exchange safe, they have the hardware to securely sign images taken on-device and only allow those.[1] (Although that would probably piss off regulators even more.)
[1] With some work, this could be a new feature, used to demonstrate images haven't been altered. With some lockdown of the clock, it could have secure timestamps. (Location could still be spoofed with a GPS hijack.)
It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time).
This is less true now, with the option to enable “advanced data protection”. Turning this setting on disables Apple’s access to your iMessage keys along with a bunch of other stuff, though of course if you get locked out, Apple can’t help you
Yeah, and this is the sort of thing that I think drives Apple's care in recommending the most secure modes; they don't want people causally turning it on and discovered that they've buggered themselves up.
I agree with you; Amazon servers receiving 80,000 or 800,000 requests per second or 8,000,000 is all a different ballgame than it is for 800 individual actual families around the world (or 8,000 or 80,000) to get their telephones totally buggered up before work that morning on any given workday -- just because somebody trustworthy has advised them to play it super safe without making equally sure the listeners were understanding the UX difficulties of recovering their smartphone's functionality in certain mundane use cases, etc, which would ensue. That's a lot of panic to deal with. Apple user help forum volunteers would be helpless to reach all the affected frustrated people.
I don’t believe this is true. You can change your iCloud password at any time, which means they definitely are not encrypting your iCloud data based on that key or a derivative. If I had to guess, they generate a key and encrypt that key with your password so it can be changed but they also aren’t able to produce it on request.
The drawback here is that the encryption key for your data never changes, even if you change your password (the private key is just re-encrypted with the new password).
If they’ve implemented it well then this is mostly academic but it does mean they must be escrowing encrypted keys for every account, and those with ADP enabled are just encrypted against their password rather than the Apple key. It also means if they’ve suffered an undetected breach in the past then changing your password doesn’t help protect your data going forward necessarily. That being said, if an attacker had ongoing access to iCloud data then it probably doesn’t matter (although the presumably-more-secure key vault wouldn’t need to be breached again).
I have no insight into Apple’s practices and this is all speculation, this is just the trade-off I would make to keep it usable.
The keys in advanced protection are derived from your device passcodes, your macOS user password and a recovery key. You'll notice you have to approve from one of your devices to use iCloud web or add a new device.
The deviation function takes a while to run and depends on the secure enclave, but you still probably want to avoid 4-digit passcodes.
They are, but they also must be encrypted n separate times where n is the number of signed in devices.
Mac
iPad
iPhone
Recovery Key
Each of the above would have a separate uniquely encrypted device backup key as a result of the derivation function. I can change the password on any of those (or regenerate the recovery key) without a full iCloud re-encryption or duplication of my iCloud data - therefore Apple must be holding a key in escrow that is the actual decryption key. One would assume it's that key that is encrypted against the derivation function, as then it could still be credibly argued as end-to-end, but that's just an assumption I'm making.
I'm not sure why you're doing all this speculation, when wrapping keys is a pretty standard technique (i.e. LUKS key slots) and Apple provides the details themselves[1]. Yes, they're doing a handshake with secure enclave keys and transfer the master key to your devices. Turning on Advanced Protection will reencrypt all the data in iCloud in the background whereas turning it off will submit the master key to Apple so they can presumably place it on an HSM. Apple already did this before advanced protection with your Keychain.
Unless BOTH ends of a conversation are using it, it's pointless.
This means that turning it on does nothing in terms of privacy, in practice, today. All of the iMessages you send and receive will be readable using the escrowed keys from
the other users you are messaging with.
Perhaps at some point Apple will prompt or nudge people to migrate, but that's unlikely given the risks to data loss for people who forget their credentials (and have "nothing to hide").
I probably spent 100+ hours doing everything possible to regain access to an iCloud account with advanced data protection.
I lost the password and the recovery key (with no 2nd apple device that was logged in). The only outcome in that scenario is losing your iCloud account completely.
Lesson: enable advanced security, but save your recovery key!
It's on by default, which means everyone you iMessage with is escrowing the keys that allow Apple to decrypt all of the messages. Turning it off on only one end of the conversation has no meaningful effect.
Was going to mention. iMessage seems to be that golden key thing the FBeye asked them for back in 2015 in San Bernadino (insofar as iCloud itself isn't a/the key itself, already)
Another idea for Apple would simply be quarantining attachments from unknown contacts. E.g. display that an attachment exists but don't download it to the device until a user accepts a "attachment from unknown sender" warning box
AFAIK all iMessage attachments (since iOS 14) are quarantined via BlastDoor, any such full system takeover must include at least two escapes: one from BlastDoor, and another from the application sandbox. They also need to cope with ASLR. It's pretty heavy duty even in the most basic default configuration.
I think attackers would just try to make the system offer to disable security whenever possible then. Anything as easy as clicking an already offered option by the OS itself will be used often enough to negate most of the security benefits of that mode IMO, meaning you deal with it being slower be default and probably not as secure as you think because people will opt out often for convenience, so the worst of both worlds.
As I understand it this was a real problem with earlier versions of Windows where it kept asking for admin privileges all the time for simple things, and people got conditioned to just authorize it. They made a concerted effort to provide APIs that didn't require it for most actions to combat this.
What do you mean "per-app in safari"? I'd like to turn it on globally, with a single exception: I want to be able to continue using shared photos albums with my two best friends.
I don't care enough about JS performance or, more generally, the mobile web, to want to disable it on safari, or even parts of it.
You can disable lockdown mode in web views for specific apps. You do it in settings because those apps don’t have the usual Safari UI for configuring that.
I'd prefer a third mode that compromises between the two, perhaps letting you lower your security for a few minutes when you need the extra functionality. For example, Safari could detect when JavaScript is being slow and pop up an offer to re-enable JIT.