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

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.

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

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

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

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

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

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

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

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.

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!

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.

That is technically a remark I agree with, but you're skipping past the actual point of my comment: it may be a valid strategy on its face but it is fragile and makes users vulnerable to systemic exploitation.

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

> you're skipping past the actual point

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.

I think the difference here is whether we're considering the plausibility that there aren't any security violations versus the overall frequency and severity. Centralization significantly increases the chance that all the systems involved will be safe; that's what makes it so useful for individual organizations, where centralizing their operations wouldn't attract significantly more bad actors to try breaking their security than decentralizing.

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.

Agree with all of that.

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)

I don't remember anyone "clutching pearls" over https by default? Do you have any suggested references where I can find those? I do recall people really complaining that anything at all was allowed to be http, even sites that most people would consider "unimportant".

There were a lot of complaints that websites which never had to bother with certificates before now had to set one up (and pay for one). Though that's now largely solved by Lets Encrypt.

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

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

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

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

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

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)

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.

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

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

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?

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.

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.

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

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

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?

Beeper was acquired by Automattic about a month ago.

That was texts.com, not Beeper

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

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

https://texts.com/faq

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

apple

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)

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

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

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

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.

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

Gruber is effectively an Apple employee.

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

Everything you said is correct.

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

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

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

Easy to be right on the money here. This is the default MO. Regardless of if you are paying for it or are licensed or are doing it despite the tech giant whose toe you are tickling. Twitter API springs to mind.

If an "unsanctioned" client can compromise iMessage security, then there was no actual security other than obscurity.

I didn't compromise the security of iMessage as a whole, it just exploited a way to get people into the system that was not planned.

Imagine there is a theme park that has normal ticket booths and some requirements there to get in. Then there comes a Beeper that finds a hole in the fence on the perimeter and sets up their ticket booths there. It's in theme park's best interest to close that hole and cut off the revenue stream of somebody pigging back on their theme park.

Except they charge a thousand dollars to enter and then let everyone else in for free but they have to wear a badge and the pictures they get from the roller coaster photo booth are 240p.

And no one is obligated to come to the Theme park. There's an entire world of people who never visit the theme park, mock the people who do, and couldn't care less about it. But some people want to be included as going to the park, when they don't. Some people are very judgy and don't want to talk to people who don't go to the park...

Okay, I've stretched the metaphor out enough.

Almost 60% of America is in the theme park.

> Except they charge a thousand dollars

A Lamborghini Urus costs $230k so I guess it's morally acceptable to break into a dealership and steal it.

Kind of, yeah. Once something is expensive enough it's no longer common theft, it's a heist.

It looks to me like there is an advantageous business relationship between Beeper and their customers. As a general rule, Apple is free to change their programs and how they work. However, I think there’s a plausible argument for tortious interference here if the sole purpose was to prevent interoperability.

Are you a lawyer because Apple stopping third parties from using their service being in any way illegal sounds extremely hard to believe

> The CFAA prohibits intentionally accessing a computer without authorization or in excess of authorization, but fails to define what “without authorization” means.

- From the National Association of Criminal Defense Lawyers

Other way around. If anything, it sounds to me like Beeper Mini was acting illegally by accessing Apple’s servers in a way they didn’t give permission for.

The CFAA is ripe for abuse. I’m not saying applying it here would be just or not, only that Apple likely wasn’t the one acting illegally.

I think that’s certainly an argument that Apple would make. However, it seems that this app was simply sending requests and receiving responses that there was no code injection or compromise of Apple servers, or of credentials, or anything of that sort.

Yes, they didn't violate the law as you think it ought to be written.

They may very well have violated the law as it is actually written.

It's also entirely possible that no law has been violated by anyone at all. What Beeper Mini did is probably not illegal. What Apple did in response is probably not illegal.

Not particularly relevant due to lawsuits involving game cheating, where the circumstances are very similar.

Beeper is lucky they weren't sued under the DMCA anti-circumvention clause, as they clearly were bypassing the technological measures Apple uses to prevent genuine devices from connecting to iMessage & Apple services.

The DMCA protects copyright, not APIs. If iMessage was a DVD then this would be a point.

I wonder if any of the encryption stuff Apple uses would give them an argument, like convincing their system to generate keys.

I think you’re likely right though. If they had such a claim I think their lawyers would have been on it instantly.

That’s why I mentioned the CFAA. Accessing servers without someone’s permission is the exact kind of thing people have gotten very stiff punishments for under the CFAA in the past. It’s basically the main reason I know the law exists, stories about peoples ridiculous punishments for relatively benign things.

Sure it’s useful for real things. I bet you can prosecute ransom under it. Or hacking to break into a rival company.

But it’s also great for when someone embarrasses a politician with stuff that they published on their own website and “something has to be done”.

Wouldn’t it be the users, rather than Beeper Mini, that are doing the accessing?

Beeper mini includes a hosted service to receive APNS notifications (meant for Apple software)

So I would summarize it as the corporate entity connecting to an Apple API and using it in undocumented ways that they reverse engineered, intercepting messages meant only for Apple software, doing so without prior permission, for purpose to selling access to services which would normally be covered by an Apple EULA.

It is not quite like a smaller word processor wanting to be able to import Word documents - without tying into Apple's service, Beeper Mini has zero value.

That’s fair, but compare it to SMS. What if Apple blocked SMS messages sent via cellular carriers, which are also using their services (software on phones, etc.) Then suppose it wasn’t malicious SMS or spam, but legitimate messages sent using a competitor’s product (e.g. from all Samsung phones).

There's a bunch of reasons why this is unlikely to be tortious interference, but one of the obvious ones is the contractual Terms & Conditions that apply between Apple and its users; I doubt Beeper is liable here, but if interference was a thing, my bet (not a lawyer!) is that the liability would point the other direction.

My read of GP's comment was that the claim of tortious interference would be by Beeper against Apple (for interfering with Beeper's relationship with Beeper's customers).

Apple is not preventing anyone from downloading beeper, or giving beeper money, or running beeper software. They are exercising control over their own servers.

My understanding of tortious interference is that it is broader than actually preventing others from using a service. Even just saying things to dissuade them from doing business with a company can qualify.

Really weird that a disinterested third party like Apple would even make loud public statements about Beeper.

Blocking interpretability could be illegal, especially as they near market dominance

iMessage is nowhere near market dominance. As evidenced by the ease of use and popularity of alternatives such as SMS/Whatsapp/Signal/Wechat/etc

I agree. The obsession with "blue bubbles" is something I only hear about from tech writers. No one I communicate with in the real world has ever mentioned it. Supposedly teenagers care about this, but that seems like a poor basis for anti-trust action.

At the same time, I miss the era of rich third party client ecosystems for things like AIM or MSN messenger. Blocking interoperability is a bummer for innovation.

>Supposedly teenagers care about this,

Android vs iPhone is definitely a thing people in their 20s and 30s even use to judge others. I have polled quite a few family/friends, and it is near unanimous that it is a dealbreaker in dating, mostly because they assume there is a higher likelihood they will not mesh with the type of person the non iPhone user is.

>but that seems like a poor basis for anti-trust action.

Correct.

Apple would claim that you pay for the iMessage service as part of the purchase price of hardware and software. From this perspective it's not blocking interoperability, it's blocking theft.

Whether that argument holds is for governments and courts to decide, ultimately.

Yes. And I'm saying, were this a live issue (I don't think it is), the graver liability might be for Beeper interfering with Apple's contracts with its users.

In what way would Beeper's action cause Apple's customers to breach a contract with Apple? I would think most of the people who would purchase a service like this would be Android users, not iPhone users. Some of them might own Macs, but what would be the contract that the user would be breaching that would result in damage to Apple?

If they're "just Android users", they don't have iMessage accounts.

So your thinking is that these end-users have signed some sort of agreement with Apple, and that agreement says they won't use any unauthorized services to connect to Apple servers, or some such thing?

That's not "my thinking" so much as it is a fact.

If it’s a fact then it should be no trouble to share the relevant provision.

I was sharing that theory as a conjecture, since I have no reason to believe such a provision exists.

There’s certainly a contract there, but it’s not obvious how a customers compliance the terms and obligations create a profit for Apple. I think most outside observers would generally assume that Apple‘s profits come from the payments the customers make to Apple, when purchasing devices or making subscriptions. After all, the only people subject to, and breaching the terms of service are Apple customers who did pay for their phones, etc..

In a California interference case, Apple would need to prove:

1. An enforceable contract existed (check!)

2. Beeper knew about the contract (check!)

3. Beeper's actions intentionally caused a breach of that contract (check!)

4. An actual breach of Apple's Terms & Conditions occurred

5. Apple had damages

None of those elements have much to do with profit.

How are you going to make a case for tortious interference when the would be interferee is profiting by using the interferer’s resources without payment?

From beepers website, there’s no use of apples servers when iMessages are sent from a beeper user to a beeper user. Rather, they only pass through Apple when sent to an iPhone user and in that case it’s the iPhone user that’s utilizing apples resources. And in that case there’s an Apple device owner, who is paid for the right to use iMessage servers.

Well, obviously, if those messages aren't using Apple's servers, then Apple hasn't stopped them, so there's no interference.

Wow that’s a hell of a stretch, but A+ for effort I guess. By that logic, they’re only stealing 50% of Apple’s iMessage resources for iPhone users.

Not sure why this is getting downvoted – IAAL and this is definitely something worth considering. This particular type of law varies from state to state, and can be quite broad. I've talked with other lawyers about it in the past, and my understanding is that it's frequently asserted when companies make counterclaims in business litigation.

That doesn't mean it's a sure winner, just that it's a live question until more info is known. I imagine Apple would say they need to tighten up any parts of their system that could allow for spoofing or other security issues, and that was their 'legitimate' reason to make these changes.

I’m not a lawyer, but I do know how computers work. I’d bet the farm on the very safe assumption that any protocol change that blocks a third-party client at the very least can plausibly be claimed to be in service of security, and most likely be a legitimate claim in reality. It is probably being downvoted because it’s incredibly far-fetched.

I agree that this would be their argument. But as other commenters mention, this area could be a minefield for Apple due to their dominance in various markets. It's possible they wouldn't want to get sucked into a lawsuit about this, even if they thought they could win, since they might end up making statements that would have a larger detrimental effects in other cases/potential cases.

I think most or all states recognize that the defendant’s actions must not be justified or privileged. It’s hard to imagine how Beeper would meet that element on these facts.

Maybe (or maybe not) plausible, but I think it's irrelevant, because there's no way a small company like Beeper could beat Apple's lawyers at this game. It will end up bankrupting Beeper long before it would even matter.

This is unfortunate, but not untrue. Even just going through discovery on this issue would be quite expensive — and would be critical to proving Beeper's case.

That's like getting upset after getting bad dating advice from a vending machine.

Not sure that's worth much congratulation. Is there anyone that didn't think the exact same thing as soon as they saw the story?

I heard/saw quite a few people saying Apple either couldn't or wouldn't cut them off—and that even if they did, it would take a while. They were ridiculous takes, yes, but apparently made in earnest.

While it would ruin the experience in practice (not being able to receive any notifications), I don't see why someone couldn't perfectly reverse engineer the protocol.

Beeper made several design decisions that made the app super easy to use (i.e. using a single certificate that wasn't supplied by a user's phone), but if you extract the necessary source material from an old jailbroken iDevice, you could create an iMessage clone that Apple can't ban without either legal action or breaking compatibility with all easily jailbroken iOS devices.

Back in the days of AIM and MSN, even large companies used reverse engineering to get chat interoperability, and it was so successful that AIM left open an RCE vulnerability to push shellcode so that Microsoft couldn't chat through their service.

Any source/articles about the AIM RCE and it being left open? Would love to read about that

Here's a long writeup by someone who worked at Microsoft at the time: https://www.nplusonemag.com/issue-19/essays/chat-wars/

The "well duh" crowd says "well duh" no matter what happens.

Mmm, absolutes.

There were a lot! Usually taking the form of: 1. They’ll have to do a major update to iMessage, 2. But what about Hackintosh?, or 3. EU regulators will stop it

A good chunk of the posters on the release thread seemed to think otherwise.

His first sentence about privacy and security is nonsense, but his second sentence hits the nail on the head.

If the richest company in the world wanted their chat app to run on Android, it would by now.

It's strange Apple doesn't sell an iMessage Android app, but I'm sure they've had somebody do the math and found out that it's more money for Apple in the long run if they don't.

Completely agreed about the nonsensical first claim. We have many third-party clients for other messaging platforms where privacy and security are a primary feature. It's completely tenable, especially for a player like Apple.

Or put another way: If the privacy and security of imessage is compromised by someone building another client, I'd argue that you never had either to begin with.

> Completely agreed about the nonsensical first claim. We have many third-party clients for other messaging platforms where privacy and security are a primary feature.

I can't think of an any with independent implementations.

For instance, have a few third party Signal clients, which work by using the official libSignal . These are not third party clients, but third party GUIs. Use of libSignal on the official Signal network is also not supported or recommended.

Likewise, all the third-party Telegram clients I know of are forks using Telegram source.

This makes sense, because neither of these are stable systems. A third party has to stay up-to-date with features and changes made to the official servers and clients.

Do you know of a security and privacy focused messaging platform which is both:

1. documented

2. has multiple independent implementations of the networking and security protocols?

Does Matrix not qualify?

I suppose it is determined by where you set the bar, even more so with privacy which still varies person-to-person and can sometimes take a qualitative feel.

Security wise, there is interesting work adopting MLS (and I believe key transparency) under Matrix, see https://arewemlsyet.com for example.

> If the privacy and security of imessage is compromised by someone building another client, I'd argue that you never had either to begin with

That's like saying the internet protocol is neither private and secure because people willingly use random public Wi-Fi

Because there are people that buys iphone just to get a blue bubble, why would Apple want to stop that?

you’re talking to a forum that is probably 50% iPhone and has very good technical reasons to do so, this is insulting and it’s absurd that it’s so casually normalized to directly insult people in this fashion

How did you manage to take this as a personal insult? Some people buy an iPhone for the blue bubble, some have what they believe to be good technical reasons to buy one, some people like the aesthetics, some people buy one out of habit. Stating that each category exists is not an insult to those who fall outside it.

> How did you manage to take this as a personal insult?

years and years of "apple sheeple" variants tend to take their toll, you're just the latest in an endless parade of microaggressions even if you don't think your particular case was notable.

why is it so important for you to push on the idea apple users being thoughtless trend-followers? just don't do that, be better. you can do it. the next time you feel like posting that, simply take a deep breath and don't post it.

there is just no reason to go around posting that "[device that 50% of people own] users are all doing it for [trite/dismissive reason]" in the first place, let alone on a tech forum where everyone has very specific reasons for their tech purchases. and it's so completely normalized, android users do it so routinely and don't even think that what they are saying is offensive. it's literally the classic microaggression problem.

Do Apple devices not have a shift key?

he didn't say that though???

You need to read the message again, they said nothing like that.

> on a tech forum where everyone has very specific reasons for their tech purchases

Thats a very funny statement. From my experience tech people in general are the ones falling for vanity, fashion, dogmas etc. most often while claiming some "practical" reasons

It's a socioeconomic indicator for high status, and it would be foolish to ignore that as part of Apple's strategy.

Android doesn't suffer from that kind of complaint because it's often perceived as the opposite: a socioeconomic indicator for low status. It's socially acceptable to mock people for choosing high socioeconomic indicators, but not low socioeconomic indicators.

"You only bought that because you're rich" has a very different ring than "you only bought that because you're poor".

That perception of low vs high indicators is somewhat wrong (high-end Android phones cost more than the latest iPhone, used iPhones are pretty affordable) but it is the perception.

That’s a small subset of their customers in a single country. I don’t think they really care either way.

the american consumer punches far above its weight. apple cares and goes to great lengths to wall imessage. See the article linked in this post for instance

Look no further than blackberry... Their days were always numbered as the only reason to keep it is the messaging (and a bit the keyboard).

Another theme here is BBM (Bloomberg Messaging). People/Companies pay BB five figures per year just to get BBM. Why would they ever release a messaging app outside of the terminal. They will die before this happens.

> It's strange Apple doesn't sell an iMessage Android app

Apple doesn’t sell apps they sell hardware and services. There’s no incentive for them to provide a free iMessage app for android, and I doubt many people would pay for one.

> I doubt many people would pay for one.

Enough people paid for one. Enough to make Apple scared and use engineer time to ban/block people anyway.

Do we know that and that it wasn’t e.g. a massive influx of messages coming from a single hardware ID triggering an anti-spam system.

Since we're not Apple, we don't know. But if we take their word [0] for it.

> We took steps to protect our users by blocking techniques that exploit fake credentials in order to gain access to iMessage.

> We will continue to make updates in the future to protect our users.

[0]: https://techcrunch.com/2023/12/08/apple-cuts-off-beeper-mini...

The primary feature of iMessage is lock-in. Everything else is secondary.

> Seems irresponsible for Beeper to charge a subscription for an unsupported service.

Completely wrong. It's a job-seeking ad. “Look, I'm ruthless enough to fuck over users who buy this bogus subscription.” Which SV startup wouldn't pay millions for a crook of that caliber?

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

What a stupid take on the situation. At most it's untenable to Apples short term financial interests. A well designed protocol and implementation would be even better at protecting user privacy and security especially from a privileged attacker like the service provider and anyone able to put covert pressure on them.

The only way in which vendor lock-in helps the the existing users is that spammers and scammers have to invest additional money to acquire Apple devices to create new accounts instead of just phone numbers and a labor to create accounts.

this sounds like proof of stake to me

yes, you can indeed build a secure system on the basis of increasing the economic cost of attack beyond reasonable levels and by forcing attackers to repeatedly slash their stake to perform an attack

On the money, but unsurprising. Gruber is an Apple fan-boy through and through and it doesn't take much of a guess to posit the exact "prediction" he made. It was clear Apple was never going to put up with this, but it was likely accelerated by all of the media attention.

Apple is, however, nothing for "privacy and security" beyond what they need to do to be marginally better, and that's a stretch these days. If Gruber really believes what he wrote he's full-on living in Apple's orchard behind the walled garden that Tim Cook splendidly gatekeeps. But because Apple puts marketing dollars behind ads that say "privacy" and "security" it must be so!

This is why it's always funny to me when the trope of the hour is the mass privacy failures of Signal through use of phone numbers. And then the author turns around and types out an iMessage to a blue-bubble friend. I really hope we can move beyond the Apple reality distortion machine and move to truly user focused platforms that aren't designed to steal user data or make the board richer.

Apple has become rotten.

To be fair, that was an easy prediction.