Live data from Hacker News

Apple cuts off Beeper Mini's access

techcrunch.com

451–460 of 1001 posts

Re: Apple cuts off Beeper Mini's access

#451

Earlier quoted context omitted.

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.

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.

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

Re: Apple cuts off Beeper Mini's access

#452

Earlier quoted context omitted.

I remember another post that was very well-received where an individual hacker wrote his own homebrew iMessage client for his own personal purposes. HN really liked that! I think HN exists at an intersection of individual hackerism and business. If a project is clearly by-hackers-for-hackers it gets a lot more leeway for unsustainable concepts / implementations. But this is building a business on adversarial interope…

You're allowed to admire the technical implementation while denouncing the business model at the same time.

Pretty much all Adtech comes to mind here.

Re: Apple cuts off Beeper Mini's access

#453

Earlier quoted context omitted.

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.

Re: Apple cuts off Beeper Mini's access

#454
i will never understand the absolute hatred people have toward imessage. it's an app that runs on apples platform, for apple users. people can still communicate or text between android and apple. if you want inter-OS encryption then use whatsapp or signal or whatever the hip new thing is today.

apple owes nothing to anyone. they have created an ecosystem for their walled / gated devices that works extremely well. they don't have to let anyone else play in their pool.

this is really about blue bubbles vs green bubbles, it's the most asinine thing to waste thought on.

Re: Apple cuts off Beeper Mini's access

#455

Earlier quoted context omitted.

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.

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.

Re: Apple cuts off Beeper Mini's access

#457

Earlier quoted context omitted.

> just the IPs Beeper Mini was using to connect to the APN service. Hmm, wouldn't blocking IPs be overly broad and risked affecting regular users? Considering that IPs are scarce and constantly recycled by ISPs etc. Blocking device identifiers sounds more targeted and, for that reason, realistic.

If you take a look at their How it Works post [1] this is not an entirety client side implementation, so there would presumably be a small number of IPs that would need to be blocked. [1] https://blog.beeper.com/p/how-beeper-mini-works

Are you referring to the step where Beeper's servers make a persistent connection with Apple's APN service to listen to new messages ?

So your point is Apple can presumably distinguish between an actual iOS connection and Beeper's connection by looking at "how many connections per IP"? Still seems prone to false positives to me, unless there is something else I missed.

(Upon re-reading the post, I realized that the phone number registration is actually done by Apple. Wonder if this might provide another basis to block Beeper, i.e. all this SMS infrastructure is not cheap to maintain and Beeper's integration is arguably using it in an "unauthorized" way.)

Re: Apple cuts off Beeper Mini's access

#458

Earlier quoted context omitted.

What? Does a fire extinguisher connect to Apple servers? Does a fire extinguisher secretly being a bomb affect the security of others? I don’t know if you could have come up with a worse metaphor.

If you think about it, blocking an app and stealing your fire extinguishers are both actions that a person or corporation could theoretically do. Since they are both actions, they are equivalent. Therefore blocking an app, burning down your house, baking a pie, writing a sonnet, doing a backflip are all the same thing.

Ahhh and to think all this time I thought I knew what a metaphor was. It’s literally any comparison! Silly me!

Re: Apple cuts off Beeper Mini's access

#459
post #440
post #210

Earlier quoted context omitted.

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

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.

Re: Apple cuts off Beeper Mini's access

#460

Earlier quoted context omitted.

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

Post reply on HN