[treyd]

>It’s untenable that there’s unsanctioned client software for a messaging platform for which privacy and security are a primary feature.

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.

[cdata]

We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users. This rigid tendency towards homogeneity is bound to suffer a tragic systemic failure before too long.

It would be healthier to assume multi-polarity and lean into it.

[zxt_tzx]

> We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users. This rigid tendency towards homogeneity is bound to suffer a tragic systemic failure before too long.

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."

[ChrisMarshallNY]

I suspect there's more where that came from. The only reason we learned of this, is because the cat was let out of the bag, and Apple was able to talk about it (gag order).

People might want to think about how AirTags and Find My Phone work...

[paulmd]

> 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?

[oarsinsync]

With locations over time tied to personal identifiers stored in a database with no public audit controls

[chfalck]

Isn’t that already what every standardly configured smartphone does?

[simondotau]

> We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users.

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.

[zucker42]

> Who is saying that?

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.

[simondotau]

That is not even remotely similar to the claim you made. Nowhere in that sentence is the claim that privacy and security cannot exist without a vertically integrated corporation.

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.

[cdata]

Sure, but also recognize: web browsers constitute a mature, multi-polar ecosystem; we do not clutch pearls when a user chooses Firefox, or Safari, or Chrome (or myriad others) to transact on the web.

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!

[simondotau]

Having a system where trust is embodied in a single entity is one valid solution. It's also not the only solution and I haven't heard anyone claim that it is.

[photonerd]

Plenty of people clutched pearls (rightly) about IE tho. And https by default. And much more.

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)

[oarsinsync]

> 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.

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.

[catlifeonmars]

> An unofficial third party client breaks an established network of trust

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.

[mixdup]

What's untenable is that the third party software is unsanctioned. You can make the argument that it would be a good or better system with third party clients, or that Apple should open the system up, but it is ridiculous that anyone would trust a client/integration that depended on some kind of hack (regardless of the nature of that hack--such as whether it's decrypting and proxying or getting into the ecosystem in a "secure" way)

[jethro_tell]

It's planning to make RCS blue bubble in 24.

[mixdup]

They are planning RCS support. They've said nothing about how that will look in the app, it's not a given that will be in blue bubbles or fully feature complete with iMessage

[a2dam]

They actually did say that it will be green: https://9to5mac.com/2023/11/16/apple-confirms-rcs-messages-w...

[bouke]

So, green=unencrypted (unsecured) and blue=encrypted (secured)? I don’t see a problem with that.

[mixdup]

Even better, and not surprising at all. I was kind of surprised that everyone just assumed RCS would get the blue bubble treatment when Apple made their announcement.

[al_borland]

This would be the case if it were a protocol designed to be opened up for use by 3rd party clients. As it stands, this was a clever hack which would undermine the integrity of the system if left in place. Within a few weeks we’d see 100 3rd party iMessage clients, and it would be luck of the draw if the one someone downloads is secure or not.

[jvolkman]

If the existence of a working unsanctioned client undermines the integrity of a system as prominent and security- and privacy-focused as iMessage proclaims to be, then that system has big problems.

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.

[ceejayoz]

Every system has holes that get discovered in time. Leaving those holes open is a different thing.

[danShumway]

This is also notable, because the technology that Beeper Mini is based on was public and available to potential attackers before Beeper Mini launched. Beeper didn't invent this, they contracted the developer and based the project off of their open Github repository.

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.

[eptcyka]

How is using another client undermining the security of the whole system?

[al_borland]

The system wasn't designed with those 3rd party clients, and security around them, in mind. Beeper Mini is spoofing/reusing device IDs, pretending to be some random person's Mac, for example. True support for 3rd party clients wouldn't not require this kind of thing.

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.

[danShumway]

> The system wasn't designed with those 3rd party clients, and security around them, in mind.

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.

[shadowfiend]

There is no iMessage app. There is a Messages app that implements two systems: iMessage and SMS/MMS. iMessage is the system whose security model is being discussed here, and the security model of SMS/MMS is mostly irrelevant to it.

[danShumway]

This is splitting straws; the overwhelming majority of Apple users don't make this distinction (if they even realize there is a distinction to make). For all practical purposes they use one app that lets them talk to their friends and some of the bubbles are green and some are blue. How many of those Apple users even realize that the green bubbles are unencrypted rather than just being a designation for Android contacts?

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.

[michaelcampbell]

Sure, but I don't think anyone can legitimately claim Gruber hasn't had some generally pro-Apple stance for decades.

[bombcar]

Third party clients offer many more cases for average users to lose their security, because you can’t prevent malicious actors from releasing “SuperMessengerSecure” that just mirrors everything off to a server somewhere.

[catlifeonmars]

Yes 100% Security and privacy should be built into the protocol. Anything else is just protectionism and security theater.

[LanzVonL]

Yeah but then that one Israeli company that spies on everybody will just pump these apps out.

[Grustaf]

How would third-party clients _increase_ security (other than indirectly, by people using SMS less)? On the contrary, third-party clients is a gigantic security hole, since Apple can't even know if a client app is spying on users.

[jlarocco]

> On the contrary, third-party clients is a gigantic security hole, since Apple can't even know if a client app is spying on users.

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.

[dwaite]

> 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.

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.

[person3]

I don’t know a lot about how it works, so forgive me if this is a silly idea. I wonder if attestation could be done using real Apple devices, while leaving the private key on the user’s android. So similar to the old beeper to get the signed attestation, and send the result to the phone. Still could be secure since you can keep the private key used to encrypt messages local on the users device. I guess the issue might be a cat and mouse game if detecting beepers flock of Apple hardware to try and disable them all… (given many people would be using the same Apple devices)

[dwaite]

I think iMessage is still using older attestations, but generally an attestation of this sort (App Attest, Play Protect API) represent a chain of the hardware, boot process, OS and application.

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.

[Grustaf]

> Security isn't about Apple knowing if an app is spying on users

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.

[poisonborz]

> Security isn't about Apple knowing if an app is spying on users, but about THE USERS knowing that nobody is spying on them.

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.

[sneak]

Gruber is a shill, bribed with special access for his blog.

Everything you said is correct.

[cqqxo4zV46cp]

No. This is an entirely self-centred view. The only people that equate this sort of transparency with genuine security are computer nerds. These tend to be the sorts of people that don’t sit very highly on my internal list of “people who stand to benefit the most from increased privacy measures”. For…literally every other member of society, this sort of implementation detail doesn’t mean anything^. They hear some (from their perspective) very abstract words like ‘open’, and all that means is that they’re trusting some league of computer nerds to tell them that something is ‘secure’. This is somehow meant to be more convincing than Apple, who, to most people, is at the very least another mob of computer nerds, but in reality also happen to have a pretty good track record of making phones that seem to work alright for people.

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.

[danShumway]

> 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.

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.

[hoistbypetard]

> 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.

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.

[m3kw9]

No need for transparency here. Just know that no one has broken the encryption is all you need. Also you likely will not know if beeper sends a copy of your messages to their servers to sell, but who would you trust more won’t sell your info, beeper or Apple?

[yurishimo]

Beeper was acquired by Automattic about a month ago.

[massel]

That was texts.com, not Beeper

[shafyy]

Speaking of, how is Texts able to send iMessage messages (at least on their website, they have the Apple Messages app icon)?

[ruune]

They go through Apple. iMessage only works on MacOS, so they probably just hook into the regular stuff MacOS provides

https://texts.com/faq

[shafyy]

I see. And that's fine for Apple? It's still not an official API right?

[oehpr]

I'm trying to figure out if this post is sarcasm.

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.

[m3kw9]

I wasn’t being sarcastic, I mean you do know there exist closed source for a reason whatever that is. For Apple to open their protocol would mean your messages sent to 3rd party clients, which means they could sell your messages for ad targeting or worse.

[danShumway]

When Apple sends messages via SMS, they are sending your messages to 3rd party clients who could sell your messages for ad targeting or worse. Apple already does this. They already send your messages to random clients who could be spying on you.

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).

[paulmd]

isn’t googles RCS encryption a proprietary non-standard that other companies have requested to interop against and been ignored?

yeah can’t imagine why apple doesn’t use it

[danShumway]

Google's RCS standard is garbage.

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?

[paulmd]

apple