"they would not consider it safe" is from Apple's perspective, which is the only thing that matters when Apple is the steward of legally and technically enforcing who can use their APIs.

Sure. They have every right to do what they're doing. I'm just mocking Apple because I think their implication that they're the only trustworthy entity is ridiculous. We have no reason to trust them any more than we do Beeper or any other company.

If Apple actually cared about security they'd implement an open protocol that is provably secure. Imagine if they supported something like Matrix. But that's clearly not their primary concern here. It's just a convenient excuse to maintain their walled garden.

If you don’t trust Apple, then obviously you don’t use it. If you do, then it shouldn't be possible for a 3rd party client to break that trust. Users only see iMessage vs no-iMessage and have no other way to identify the client to decide for themselves whether to trust it.

> If you do, then it shouldn't be possible for a 3rd party client to break that trust.

A correctly implemented end-to-end encrypted protocol would be safe for all participating clients.

The only way to break that security is by copying messages outside the protocol in the app itself.

Neither of us knows whether iMessage or Beeper Mini does this. To bring up the possibility is to criticize both apps equally.

> A correctly implemented end-to-end encrypted protocol would be safe for all participating clients.

As long as the clients are closed source, this is a circular argument. The client itself is a vector. Not just for a good E2E implementation but for the 3rd party company to not outright steal everyone’s messages, create a backdoor, etc. You have to be willing to trust every client used in the thread.

That was my second point.

If we must be willing to distrust one closed source client, then we ought to distrust both.

This is tantamount to saying we should only trust open source software. If that’s your point, then you lost me. If not, then it’s obvious that some companies are more trustworthy than others. (P.S. the many active exploits found in core low level open source software after months or years because despite the source being open almost no one audits it because they’re cheap and/or assume someone else is doing it)

Well why in the world would I trust iMessage and distrust Beeper Mini?

Are you seriously asking why someone would trust Apple over a small generally unknown Android-only app company?

I don't actually think it's that unreasonable. Apple has broken people's trust many times and come out just fine in the end because they are a huge company with many products participating in many markets. A small company like Beeper is dependent on a small user base and a significant breach of trust could easily spell the end for them.

That said, I don't personally trust either of them. When it comes to matters of security, I prefer open protocols which can be proven to be secure over pinky swears from companies.

Trust is generally something you build and lose, rather than something you are given by default. That reputation can be a massive asset or liability.

The level of trust I currently give in Beeper is that identity verification happened such that someone could potentially be prosecuted for abuses after-the-fact.

They have not built up a reputation, and in the face of potential scams or privacy abuses their reputation may not be as valuable as the user information they can gain access to.

Small incidents can cause significant reputation harm to Apple, and those equate to billions of dollars lost in corporate value.

Even the recent notification monitoring announcement harms their reputation, where the government itself mandated non-transparency. (For this reason, I somewhat expect they are trying to design an oblivious notification system, where role separation prevents a single intermediary from knowing both where a notification is from and where it is going to.)

Apple has done plenty to lose my trust, and very little to build it. But that's not really the subject at hand, though I do see where word choice is misleading here.

You just brought up a better word: "liability". I'll go one step further: "attack surface".

When it comes to security in software, we don't need to work with many unknowns. The unknowns we do work with are the attack surface. By presenting a greater domain of unknown behavior, closed source software effectively presents me (the user) a larger attack surface. Sure, I could trust that the extra attack surface is actually covered; but I can't know. With open source, I don't have to trust, because I can know instead.

If I am to choose between open and closed source software, then I am choosing between knowledge and trust. That is a completely different position than choosing between closed and closed: trust vs. trust. So long as any securely-designed open-source messaging app exists, iMessage is at a disadvantage in end-user security. Even if Apple can know for certain that iMessage's attack surface is not larger than an open-source alternative, we the users can't. Closed source software will always present a higher demand for trust.

Not what he said. He said he doesn’t trust them (safe). The question you should be asking is why do you?

Because they’ve proven to be the most trustworthy and if you can’t trust the manufacturer of the device and OS you also can’t trust any app running on said hardware.

As pointed out below, "they" is Apple, but I would also assume that at least 99.9% (really) of users would trust Apple more than Beeper, i they had to choose.

Let’s add a few more 9s to that, just to make it even more realistic.

Which is why most people (should) opt to use a cross platform messenger, such as Signal.

If signal would officially allow third party clients, non-phone-number-bound users and maybe federation that'd be great.

It does not.

As very recently made evident, Signal spends a significant amount of money maintaining their phone-number-bound infrastructure, with an entirely plausible, reasonable, user-focused reason for doing so. As a Signal user, and donator, I’m 100% okay with the trade-off they’ve made, and would hate to see it reversed just to appeal to some nerdy pipe-dream for how services should work.

> As very recently made evident, Signal spends a significant amount of money maintaining their phone-number-bound infrastructure, with an entirely plausible, reasonable, user-focused reason for doing so.

If there is some recent revelation that makes phone numbers all of a sudden a secure, portable and censorship-resistant identifier please link me that.

Until then I'd prefer to not have my private communication determined by telephone companies that often have not cared for either security, censorship or privacy. Regardless of signals e2e encryption having my access to the network determined by a telephone company is not the right way to go.

I'll continue to restate the thing that made me immediately quit Signal forever - I made an account, and 10 minutes later, it had alerted someone I hadn't talked to in years that I had an account, simply because they had my phone number at some point in the past, and they messaged me.

For a nominally privacy focused app, for them to literally alert people to my new Signal account I'd gotten to securely message someone violated all trust I had in them. What's to stop someone from just adding a Contact for every single valid phone number on their phone and then getting an alert for any time anyone makes a Signal account? I may as well just use Facebook then.

Does iMessage allow third party clients? No? Then why the double standard?

I'm saying that if we hold something to a higher standard lets actually hold them to a higher standard.

Is signal better than iMessage? Probably. Should we ask for them to be better than they are? Yes.

It looks like we are comparing standards here, and that neither passes the bar.

Signal does allow third party clients, Beeper is one. I agree about other things, and would expand on the list.

They do not officially and discourage it. Moxie and the rest of the company has been extremely clear that all third party clients are not considered supported or allowed, regardless if they can and do interact with signal services.

Useful (though somewhat dispiriting) to know. I would feel a lot more forgiving toward Signal's UI shortcomings if I had a choice of alternative front-ends.

The basic assumption here is trusting Apple, provided that numerous security researchers have access to the platform. If you don't trust Apple, don't buy their products.

It’s a two party marketplace. Even if I don’t like Apple, the alternative is not great either.

> Since I have no control over iMessage, I would not consider it safe.

Generally fair assumption. There's been some research (both positive and negative) around their E2EE claims, though AFAIK much of what's known about iMessage's E2EE guts has been learned through unofficial means. I think that for the vast majority of users, iMessage is probably safe enough.

As a user, you have the agency to choose a messenger app that better suits your privacy/convenience balance, though in fairness, I think even among users who care about privacy, many don't know how to judge privacy features and implementation details well.

Like others in this thread, I personally recommend Signal. It's widely available, easily usable, has been audited and researched a fair bit, and though it doesn't have a self-hosted option, it does have white papers out about its protocol which IMO are worth a read.

> Since I have no control over iMessage, I would not consider it safe.

I would trust iMessage about 95% less if I had written, or even implemented, the protocols myself, and I consider myself a pretty good developer.

If I'm expected to believe a messaging app is secure, the first thing I want is an open protocol. An open source client would be nice too, but honestly I'm fine with just the protocol.

I do not need to have had a hand in developing any of this. It's not my expertise and, like you, I'd feel more comfortable having it developed by the experts.