I don't follow this logic at all. Shouldn't supporting thirdparty clients be desirable if security is a primary feature in the interest of transparency? Especially if the reference client is proprietary and undocumented.
It would be healthier to assume multi-polarity and lean into it.
Look no further than the other news that came out this week re: government spying via push notifications. (https://www.reuters.com/technology/cybersecurity/governments...) Consumers rationally trust the few big companies which are incentive-aligned to protect their data and government then goes after those few big companies. I thought this was particularly galling:
> In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications.
> "In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
People might want to think about how AirTags and Find My Phone work...
rotating BTLE identifiers controlled by a pseudorandom sequence derived from a key, and tunneled over end to end encryption?
Who is saying that? Certainly nobody anywhere in this HN thread. It is, however, fair to say that the only guarantor of privacy and security is a network of trust. There are plenty of examples where trust is partially decentralised, the most notable being the system of certificates used for establishing trust in HTTP over TLS.
There is a quote in the top level comment of this thread that says that.
> It’s untenable that there’s unsanctioned client software for a messaging platform for which privacy and security are a primary feature.
All they're saying is that the existence of third party software compromises Apple's ability to make blanket statements about the security and privacy of this one specific platform. An unofficial third party client breaks an established network of trust — which is an objective fact. If you doubt this, then you really should use this Chromium fork I just developed. Use it to log into your internet banking. Don't be scared. There's nothing to worry about. See, there's a lock symbol in the address bar and everything.
Can a bad actor slap a green lock on an insecure browser clone and harm users? Certainly. And yet, in a survey of the systemic threats to security and privacy on the open web, such attacks are relegated to the margins.
Apple encourages a popular narrative that centralization and control beget trust, and from there may enable privacy and security. Look no further than the comments on this HN post to see the narrative echoed!
It's fair to point out that it's not literally what Gruber wrote, but readers will fill in the negative space around his uncritically apologetic commentary. To state the implied message: trust in Apple's way, and remember that third parties (who are not accountable to Apple) will ultimately deprive you of privacy and security!
The web browser ecosystem has its own (different) problems, but iMessage lacks requisite variety to back up its particular claims to privacy and security (see that Reuters article for a preview).
I skipped past that because that wasn't what I had expressed disagreement about. Though now you elucidate further I'll say I fundamentally disagree with your "actual point" as expressed. While I agree that systems of distributed trust are fundamentally healthier, they are an order of magnitude harder, and rely upon educating users. And some percentage of users will always be impervious to education — see the continued prevalence of phishing scams for example.
A system which relies upon trusting fewer entities is inherently less fragile and less vulnerable to exploitation. It's true that systems can be designed which rely on users trusting a large number of entities, and can sometimes result in a more educated user base, but they're much harder to implement and much, much, much, much rarer in the real world.
But if we have centralization on the scale of a society, then anyone interested in any of the groups using that centralized source of secure data storage/transfer will be drawn to look for the flaws in that source. And there are always flaws, either technical, legal (as with the government spying mentioned elsewhere in the comments), or otherwise. And once any group manages to infiltrate that one source, they get access to everything dependent on it.
Sure, decentralized security is harder to get together, meaning we have an initially-high violation rate that decreases over time (though this can be supplemented by security-conscious users taking their own steps to protect their data). But centralized security at sufficiently large scales essentially guarantees a breach impacting everyone within its domain; and the kind of trust that would be required to sustain such centralization also anti-correlates with users independently adding additional layers of security to their systems.
This seems like a much greater risk than just accepting that users who are "impervious to education" will be vulnerable to certain social-side exploits, while everyone else will be reasonably safe.
That it’s not currently a problem is due to 25 years of strongly pushing for privacy & security.
We’re still not there (see Google & adblockers in chrome)
We’ve also got examples of Apple making misleading statements about the security and privacy of their platform, as a result of government gag orders.
That recent disclosure makes me suspect that every vector that they do not disclose explicitly as being private, is very much not private. To that end, the platform is clearly neither private nor secure if you value privacy from the government.
…so I’m not particularly concerned about third party software being a cause for concern anymore.
I think this is key. The problem is the security of iMessage as a protocol is dependent on trust between client (implementations). Which is actually not that great from a security perspective.
I don’t mean that there are necessarily vulnerabilities in the protocol (there very well may be), but that the protocol is not something that Apple is willing to depend upon to uphold their desired security guarantees.
From what I understand Beeper Mini is interfacing with iMessage on-device, what's to stop another clients from using a server and intercepting messages? While I don't have time to look it up again, I think there was also something on how Beeper Mini is handling the push notifications when the app isn't open. While that may not leak a lot of information, and there is also the news of Apple/Google sharing push info with some governments, that's something that can at least raise some eyebrows when it comes to how private it is.
It sure as heck better have been designed with that in mind, because it sends SMS messages to uncontrolled 3rd party clients that could be stealing your information or spying on push notifications every single time you message an Android user.
I genuinely don't understand this argument. Do people think that SMS messages don't generate push notifications? Does Apple have a 1st-party SMS messenger available on Android that I'm not aware of? You're already communicating with 3rd-party clients that could be spying on you, and you're already receiving messages from those clients in the iMessage app. The biggest difference is that your messages with those clients today are fully unencrypted, so spying on them doesn't even require compromising an app.
It's weird for people to be so concerned about push notifications as if that's a decrease in security when the alternative system they're proposing is for iOS messages to be sent to Android devices fully unencrypted. Apple/Google can share all of that information with the government as well; if they're not being asked to it's only because the government can get it even more easily directly from the telcos.
It also changes nothing about my comment, because you can call SMS a different system all you want, but your conversations with Android users are still being sent unencrypted and any malicious payloads you get from SMS phones are still being loaded into the same Messages app. If you're worried that a 3rd-party client on Android is going to let a company spy on conversations you're having with Android users, then I still have real bad news for you about how Apple sends messages to Android users.
Draw the lines however you want between Messages and iMessages, but the security implications of Apple's setup are exactly the same. When you write a message to an Android contact, Apple sends that message unencrypted to a 3rd-party client that could by spying on you, leaking your data, or sending malicious payloads to your iOS Messages app. It still makes no sense whatsoever to be this concerned about the security of the push notifications for your messages to Android users when the alternative being proposed is to throw security entirely out of the window for those conversations. It is still a clear security improvement for conversations between Apple and Android users to be E2EE rather than to be sent over SMS, because the risks being raised about 3rd-party messaging clients are already present within those conversations today.
Certainly this is not the first time some entity in the world has reverse-engineered iMessage; it's just the first time that it was publicized.
Apple did leave the hole open; they left it open until it threatened their customer lock-in. Only at that point did they decide that it was a security risk.
Security isn't about Apple knowing if an app is spying on users, but about THE USERS knowing that nobody is spying on them.
At best a third party iMessage client can only be as secure as iMessage itself because the back end is still closed and has no transparency, so it's the weakest link. If Apple (or a third party) is spying on the back end then no client can be safe.
> How would third-party clients _increase_ security (other than indirectly, by people using SMS less)?
They can increase security by breaking a single target into multiple targets, by increasing competition around security and privacy issues, by having more people use and work with the protocols and able to spot potential problems, by encouraging more transparency around issues when they arise, and by having alternatives readily available if one of the clients is found to be compromised or insecure.
And of course open source clients can be verified and validated by other developers and security professionals.
I believe you are speaking to transparency, not third party clients.
Beeper Mini actually bundled binaries that they didn't understand to bootstrap registration. They could only attempt to be compatible with messages that they have received, and verify messages they send show up correctly - they cannot know they covered all available options.
I speak to this as someone who reverse engineered MSN Messenger back in the early 2000s for an XMPP gateway - you'd occasionally find an entirely new type of message (requiring an entirely new parsing code path for their undocumented/bespoke messaging protocol) because someone registered for a stock ticker or the like.
There was no fuzzing the official servers or clients to see if they were robust or secure - the goal was to have a salable product. In fact, we saw other messaging systems where we had significant concerns based on our understanding of the protocols through reverse engineering, and we saw one vendor exploit a security vulnerability in their own shipping product in order to verify authenticity and block third party clients (which worked for a period of time)
From what I saw of the iMessage system, third party support is not going to be feasible even with a documented protocol without partnership, because there is an assumption of attestation of real, unique hardware as part of registration to prevent mass abuse.
So iMessage is not going to be willing to hand out private keys or negotiate them for a third party application, and Beeper will not be trusted to register a private key itself.
Android iMessage support would be weird because there is no iMessage application - there is an application which lets you send SMS and to upgrade to MMS or iMessage when available. So, if there ever was an official Messages app for Android, I would somewhat expect it to also offer to take over being the default application for SMS/MMS.
True, but Apple caters specifically to a consumer base that can't know this and does not want to think about this. Whether this is health or sustainable in the future is another matter.
Clearly, what matters to Apple is what _they_ believe is secure, and they of course trust themselves more than they trust Beeper.
> At best a third party iMessage client can only be as secure as iMessage itself
Exactly, they can never be safer, and given that Apple, or we as users, know very little about the company behind the client, third-party clients are much less secure.
Everything you said is correct.
Beyond optics, let’s just look at attack surface. The implication that the sort of security holes that “openness” would fix are anywhere near the top of the list is…where’s that xkcd about cryptography and crowbars? It’s very clearly in the realm of nerdy cosplay. You know what is* a much more realistic threat? Some stupid third-party client on the Play store that exfiltrates all messages sent and received. Apple has absolutely no control over that. No protocol security accounts for that.
One way to avoid that outcome would be to have a first-party client on the Play store.
Instead, Apple drops all message security entirely from cross-platform communications for iOS users, allowing anyone to read those messages whether or not they have a crowbar. This is security 101: users do dangerous crap when the secure options don't have affordances for their use-cases. Users are lazy. If an official 1st-party secure client exists that meets their needs, they won't install a 3rd-party client. Users resort to dangerous and unsupported options when the safe, obvious options either don't work or aren't available.
And thankfully, we now know that it would be entirely possible for Apple to fix that problem and to move its own users off of SMS for communication with Android contacts, and we know that because a 16 year-old high-schooler was able to build that support with zero documentation. Presumably Apple is capable of doing the work of a 16 year-old. We now know that it would in fact be entirely possible for Apple using a 1st-party controlled, proprietary client with a proprietary protocol, to encrypt virtually every message that Apple users send to every one of their contacts, rather than what Apple does today where it encrypts... some of them.
None of this requires Apple to Open Source anything or to document or make available any of their protocols. The only reason Apple is in this position right now of needing to deal with 3rd-party clients is because of a lack of support from their 1st-party client.
I think that's my biggest gripe with the situation. Or my second-biggest. My biggest gripe is that the only notification that your messages are now not end-to-end encrypted is the green bubble. They don't tell you anywhere that the green bubble (also) means that.
The first half definitely made me think sarcasm, then the second half... I mean I know some people actually believe this... Then I noticed you said "encryption" instead of "protocol". Breaking an encryption standard is obviously very hard, breaking a protocol is obviously not nearly so hard.
On the other hand, taking this stance would be insane given the post we're talking about. A company that actively circumvented apples security measures. So you must be being sarcastic. You just have to be.
Remember, on the internet it's kinda hard to tell. Make sure to throw in a /s unless you really REALLY sell it.
It's just that in addition to sending your messages to 3rd party clients that could be stealing the data, Apple goes the extra step to make it even more insecure and also sends your messages completely unencrypted, so that everybody along the path from your device to the 3rd-party client can join in and also read your messages and can also use them for ad targeting or worse.
I'll make the argument that this is strictly worse for security than tolerating an encrypted 3rd-party client (or better, releasing their own 1st-party client rather than relying on SMS).
yeah can’t imagine why apple doesn’t use it
But Apple doesn't have to use it. They could release a messaging app for Android that used their own encryption, and they could encourage Android users to switch. But they don't do that, because distinguishing between Android and iOS users is ultimately more important to Apple than securing the conversations that Apple users have.
If RCS is garbage (and it is) then it is extremely weird that Apple has committed to supporting RCS for cross-platform messages instead of encouraging adoption of what would be a superior form of encryption for those conversations.
What you have to ask is, if you are an Apple user, why isn't Apple trying to encrypt every message that you send? Why are they asking you to use a garbage protocol when you send messages to Android users?
> yeah can’t imagine why apple doesn’t use it
Really, this statement should be reversed, it's difficult to imagine why Apple is planning to use RCS. Why is Apple more willing to implement a garbage protocol than they are willing to release a messaging app for Android?