Hacker News Reader

Comment by mike_d | Hacker News Reader

> If Apple continues to cut off Beeper's access, it makes an antitrust argument stronger

I'm not sure why everyone thinks it is an antitrust issue when it isn't. There is no legal obligation to support your services and software on third party platforms.

View on HN

I'd argue that's not the right framing of the issue. Taking active steps to prevent your services from being used on competing platforms is more than merely "not supporting" them.

it would be incredibly easy for apple to frame this as a security issue, because, even in my mind, it is. I pay for apple devices because I trust apple with my data. I do not trust most companies with my data. I trust my data to only flow through Apple's servers, and to get a clear indication when my data is _not_ flowing through apple's servers (e.g. green bubbles). A company bypassing this causing messages to show up blue when they are in fact traveling outside of Apple's control is a security risk (to me). Clearly if it's e2e encrypted that's not the case, but that's not what apple is going to argue. They're going to argue exactly what I just did. And I honestly agree with them. That doesn't mean Apple doesn't need to allow other companies onto the platform, just that BLUE BUBBLES mean something to apple customers and bypassing that is something that apple needs to block.

Apple really needs to get that RCS implementation rolled out though. Wonder if it's still going to be green bubbles or something else.

I think this pypush method uses Apple servers. I think the key aspect was the author figuring out how submit public keys and request public keys for other Apple users from Apple servers. From that point it seems to be as secure as public key cryptography.

https://jjtech.dev/reverse-engineering/imessage-explained/

i mean... will the court understand that? Or will they understand the argument I framed (however dumb it is)? I think apple would easily be able to convince the court that anything exiting their servers is less secure, or gives the appearance of lower security, to their customers. Anyway, apple is implementing rcs next year so hopefully none of this matters.

Apple has always made services primarily for the users of their hardware. They are a hardware company that makes their own software and services. The hardware purchase funds the software development.

Who decides which platforms get support, if it's not the company making and supporting the service? When BBM was popular, I know a lot of people without Blackberries would have liked to use it, but Blackberry didn't offer it, and no one was threatening legal action against them (that I know of). I don't see how this situation is any different.

There are a lot of exclusive services out there, which are locked to specific platforms. Affording legal protection to anyone who hacks their way into a system, and telling the company they can't do anything about it, would create chaos in the tech world. There might be some cool projects, but business models would fall apart, companies would fail, security would be worse than it already is, and I'd question why anyone would try and start something new when they wouldn't be allowed to control it in a way to ensure profitability. Having everything free and open is great, but at some point these services need to be paid for.

> Who decides which platforms get support

The developer of the software supporting those platforms. In this case, Beeper.

I suppose if Apple wants to say certain users are not allowed to access iMessage unless they've bought an iPhone that's fair. (Maybe you could argue its anticompetitive to bundle services together like that, but I won't assert that point here.) But if that's all this was about then I ought to be able to buy an iPhone, import the access token from that into Beeper on my Android, stuff the iPhone in a drawer, and go about my business. The problem is that Apple wants to dictate not only who has access to iMessage servers, but also how they're allowed to access it. And that is unacceptable in my opinion.

"Security" is a poor excuse. If server side software has to rely on trusting the client then it was never secure in the first place. And if client side software wants to "secure" itself against the person who owns it... that's a form of "security" I could do without.

Antitrust is not about legal obligations though, it's about competion and user harm.

Reply on news.ycombinator.com