[Nextgrid]

Employees, no. Executives, absolutely.

Beeper put them between a rock and a hard place, where any action other than accepting Beeper would solicit regulatory action. This in fact ended up happening.

Furthermore, I bet Beeper was outright hoping for a lawsuit from Apple, which would put up a well-publicized fight over adversarial interoperability that could yield to a disastrous legal precedent not just for Apple but other companies.

Apple knows this and that's why they haven't sued them (or DMCA'd any repos).

[turquoisevar]

I hate to be the one to bursts bubbles, but there’s no cause of action here under the current legislation. None.

That is unless we’re talking about Beeper being the defendant.

They have incurred criminal liability by violating the CFAA and committing computer trespass and civil liability by violating the the OS license agreement and ToS that both prohibit reverse engineering (yes that supersedes DMCA exception) not to mention the general copyright violations of reselling Apple’s IP for $2/mo (pypush isn’t without proprietary Apple code).

CCIPS would have a field day with this and if by some weird “blow up in your face fashion” they get their hands on the referral after the antitrust division of the DOJ is done shrugging at it, Beeper might get more than they bargained for.

The only thing that could actually affect Apple in this, is if legislators pass new bills. The problem however is that this would have cascading effects across the industry, if not the economy as a whole, because there’s no way to legislate this in such a way that it would only affect Apple and Apple alone.

Anything short of that makes for a fun fantasy that I’m sure some people will get off on, but a fantasy nonetheless.

[stuartjohnson12]

> unless we’re talking about Beeper being the defendant

Yes that's the point, Beeper are probably hoping Apple sues them for the reasons you describe.

> criminal liability by violating the CFAA and committing computer trespass

This is pretty tenuous. They do have proper authorization because the keys in question are valid iMessage keys and they are being used by the same individuals those iMessage keys are allocated to. They're not trying to commit any further crime post-access.

> violating the the OS license agreement and ToS [...] (yes that supersedes DMCA exception)

Does it? This seems like a pretty textbook case of reverse engineering for interoperability.

> reselling Apple’s IP for $2/mo

Probably the case they're hoping for a lawsuit on - the degree to which Apple has legitimate claim to control use of the iMessage protocol given their market presence. In the process of the lawsuit, if Apple is found to be leveraging this protocol anti-competitively, they're in trouble.

And beyond that, Apple is a highly litigious company with great lawyers and extremely deep pockets and large incentives to defend their ownership of the messaging market.

That they've been this slow to sue Beeper probably signals enough on its own that there's probably no field day to be had.

[nicce]

> Does it? This seems like a pretty textbook case of reverse engineering for interoperability.

The problem is that everything works through Apples private services, even if there is no DMCA things in the app. On top of that they are making business with that. Quite unfair use.

What if I use Amazon’s private APIs for running my cloud. Even share it to others and charge even money from it?

[stuartjohnson12]

Seems legitimate to me.

There's no reasonable case for trespass under the CCFA as proper credentials are being used and there's no intent to use that access to commit further crime.

You can't infringe on intellectual property of a server by making requests to it, that doesn't make sense. Any case there would be access violations under the CCFA which are already covered above.

The only real claim would be the intellectual property of the client app in the way that it forms requests and accepts responses which this system is undoubtedly based on the reverse engineering of. The only problem with that argument is that the DMCA includes a specific exemption for interoperability as fair use.

Note that simply building a new client app doesn't necessarily constitute fair use, but in this case the client app extends to a platform that is otherwise not supported. Seems a pretty obvious case for interoperability in my eyes.

"Fair" or "unfair", what is the crime? Your intuition pump doesn't include enough details to be useful, I don't understand it.

[nicce]

> "Fair" or "unfair", what is the crime? Your intuition pump doesn't include enough details to be useful, I don't understand it.

Beeper does not talk only to Apple devices but also to other Beeper clients. There is no authorization by Apple to use their backends, and they are not sharing any revenue from their business, while Apple funds all the million messages.

CCFA covers the value gain, should be less than 5000 in one year, what I doubt is happening here.

I am not even sure if they are authorized in any point, because they violate ToS. Technically they fake authorization by preventing to be something other than they are, and not authorized by the terms and conditions.

[AnthonyMouse]

> while Apple funds all the million messages.

A text message is, on the high side, 1000 bytes, so a million messages is <1GB. For reference paying $0.09/GB for bandwidth is considered a high price.

This is not a number which is literally zero, but it's a number which rounds to zero.

[turquoisevar]

> They do have proper authorization because the keys in question are valid iMessage keys and they are being used by the same individuals those iMessage keys are allocated to. They're not trying to commit any further crime post-access.

Authorization in the legal sense of the CFAA is permission, plain and simple.

The ToS and EULA explicitly only allow using the iMessage service on Apple hardware, so any other form without explicit permission by Apple is unauthorized.

Spoofing device credentials to fool the server and gain an authentication blob definitely doesn’t fall under authorized access.

But even with legitimately attained credentials you can still be in violation. Ex employees of a corporation, finding a device with credentials on it, etc.

Whether they commit any further crime or not is irrelevant for criminal liability.

> Does it? This seems like a pretty textbook case of reverse engineering for interoperability.

The DMCA exception only applies to interoperability for legally acquired (e.g., licensed) software.

But it doesn’t really matter but because ToS and license clauses that explicitly prohibit it overrule it, see Bowers v. Baystate Technologies, 320 F.3d 1317 (Fed. Cir. 2003)[0]

> Probably the case they're hoping for a lawsuit on - the degree to which Apple has legitimate claim to control use of the iMessage protocol given their market presence. In the process of the lawsuit, if Apple is found to be leveraging this protocol anti-competitively, they're in trouble. And beyond that, Apple is a highly litigious company with great lawyers and extremely deep pockets and large incentives to defend their ownership of the messaging market. That they've been this slow to sue Beeper probably signals enough on its own that there's probably no field day to be had.

This reads like a Gish gallop with a bunch of weak arguments that border fantasy.

There is no “Apple in trouble” when it comes to iMessage and there are no signals.

I don’t know where you get this from but I suggest seeking better sources on understanding legal standards and ramifications.

0: https://law.resource.org/pub/us/case/reporter/F3/320/320.F3d...

[singron]

This case is probably relevant: https://en.m.wikipedia.org/wiki/HiQ_Labs_v._LinkedIn

In that case, breaking the ToS superceded the fact they were merely accessing public information.

The other question is whether Beeper is violating terms of service or their users are. I'm guessing Beeper is not and they instead need to be implicated for some kind of tortious interference. I would love if Apple individually started suing their own customers though.

[turquoisevar]

Not sure why you think HiQ Labs v. LinkedIn is relevant here?

The facts of that case are not analogous to the matter at hand.

hiQ Labs v. LinkedIn primarily deals with scraping publicly available data and the definition of "exceeds authorized access" in the CFAA. And to a lesser degree selectively banning competitors. ToS violation was a generic argument and not the contentious part.

Meanwhile Bowers v. Baystate Technologies, Inc. is current standing law on reverse engineering clauses in ToS and EULAs, while the matter at hand has nothing to do with publicly accessible data, no exceeding of authorized access and no data scraping.

> The other question is whether Beeper is violating terms of service or their users are.

That would be Beeper, no question about it. They had to agree to the OS license agreement that prohibits reverse engineering and the ToS for Apple Media Services that also prohibit reverse engineering, before they could get to the parts that needed the reverse engineering they did.

The users didn’t do any reverse engineering, although they would be in violation of the terms that state iMessage (and other Apple services and software) is only licensed to be used on Apple devices. But that’s small fry in comparison to reverse engineering, repackaging and reselling Apple’s service without a license to do so.

> I'm guessing Beeper is not and they instead need to be implicated for some kind of tortious interference.

Tortious interference has more to do with affecting a relationship you’re not a party to. This is more of an intentional tort, like conversion, although in this instance that would be more of a “side-dish” claim.

After all why go through that trouble and prove damages when you’ve got more suitable options with statutory damages.

[alright2565]

> Bowers v. Baystate Technologies, Inc

This case involves a company reverse-engineering another company's software in order to make a clone product.

Do you think a case about reverse-engineering for the purpose of interoperability might have a different outcome?

[stuartjohnson12]

That's the thing. None of this is remotely settled, the legal system is still figuring out what the book says. Various courts at various levels have affirmed and vacated all sorts of decisions. The amount of people overconfidently declaring this is an open book shut book case are living in cloud cuckoo land.

I sure as hell don't know how this will play out, and neither can anyone with any massive degree of certainty. Hacker News opinion-passive-aggressively-stated-as-fact syndrome strikes again.

[Frivolous9421]

>CFAA violation for logging into your own iMessage account and using the service

Not fucking likely

[mikeryan]

Your premise seems to be that they want Apple to sue them?

That point is moot now.

[Nextgrid]

Keep in mind that Beeper is a company (backed by some people wealthy enough to open themselves up to litigation against Apple) and most/all of the CFAA horror stories have been against defenseless individuals, so it might play out very differently as corporations are given much more leniency.

Beeper has managed to get enough media coverage on this issue that any litigants will need to consider before bringing any suits, including attention from legislators themselves who are calling for antitrust investigation. That's no small feat and suggests Apple may not be on as solid footing as you think.

[turquoisevar]

Apple would have little to do with it as CFAA violations are a criminal matter.

And I’m not very impressed by US legislators in any context, they’re politicians first and foremost, ones that are always 2-4 years away from elections.

[lxgr]

Even in a criminal matter, wouldn't Apple's description of their systems and services matter quite a lot on how that would go?

[turquoisevar]

Apple would only have to report it, similar to how you report a regular trespass and provide some evidence like logs.

Maybe, if LE is unable to connect the dots, explain how it was done so the prosecution can explain it well.

But it’s significantly less intrusive than a civil case where a lot of discovery is involved.

[lxgr]

I think you might be right about Beeper not having any legal right to iMessage interoperability.

On the other hand though, if Apple's legal right to continue locking them out was as certain as you make it sound, wouldn't it make sense for them to file a lawsuit and set precedent for anybody walking in Beeper's footsteps?

[turquoisevar]

> On the other hand though, if Apple's legal right to continue locking them out was as certain as you make it sound, wouldn't it make sense for them to file a lawsuit and set precedent for anybody walking in Beeper's footsteps?

Prefacing this by saying that I’m not privy to what, if anything, Apple is cooking up. But such a case isn’t something you cobble together in an afternoon.

In my experience a lead time for something like this is at least about a month, a week if it’s urgent and less if it’s really urgent and you seek an injunction (and then you try to flesh it out afterwards).

But ideally you want to take your time so you can discuss your strategy both internally with higher ups as well as with outside counsel, collect exhibits and draft up a solid initial filing.

Part of these discussions is also what kind of exposure you’ll have during discovery. Apple for example genuinely believes that Masimo used Apple’s internal confidential documents that Masimo received during discovery in the California trial to create the competing W1 smartwatch.

It could be that they’re weary of having to share more internal information, especially since so much has already come out during the last couple of years full of cases. Or wary that Beeper would learn more about the inner workings of iMessage.

I wouldn’t characterize it as a high priority matter with urgency either because they seem able and effective in blocking Beeper, with little loss in device sales as a result.

A lot of effort is going towards the Apple Watch issue with Masimo that prevents them from selling the newest models.

Lastly, while only of minor importance, it’s slightly more beneficial for Apple if Beeper would sue them while they keep successfully blocking Beeper than Apple suing Beeper.

All in all, it’s a lot of weighing pros and cons, even when you’re in the right. That’s one of the reason why there are so many settlements, because it often is cheaper, faster and easier than a whole trial.

[ToucanLoucan]

This has been my gut feeling about the entire thing and I don't understand so much about:

a) How Beeper thought they had a business model here

b) How so many HN readers can justify flagrant misuse of private API's and servers as some sort of liberatory move

Apple's iMessage service is a privately owned, privately hosted, closed source protocol and always has been. You are not allowed to use it without an iPhone, an iPad, or a Mac and you never have been allowed to use it otherwise. That's just... what it is. You can dislike that, you can think it's anti-competitive and you might even have a case for it, I guess we'll see, but insofar as I can see it:

iMessage is a closed source, walled garden, private protocol Apple uses to permit a higher tier of text messaging for owners of iDevices. There is no reason at all to think you're entitled to access that service without using the aforementioned devices, and there's even less reason to be surprised in the slightest that, when a company was offering services to bypass those requirements and use the API without meeting Apple's requirements, that Apple would shut that shit right down.

[Nextgrid]

> You are not allowed to use it without an iPhone, an iPad, or a Mac and you never have been allowed to use it otherwise

What about for those who do own an Apple device and thus paid the "tax" to use iMessage, but want/need to use it on unapproved devices out of convenience? The argument would be very different if Apple merely restricted the service to Apple IDs associated to a valid Apple device purchase, but that's not what they're doing. They're clearly not making the cost/resource usage argument otherwise it would be trivial for them to implement such a restriction.

> There is no reason at all to think you're entitled to access that service without using the aforementioned devices

Would you also apply that argument to Microsoft Office files? Microsoft would sure love it if it would be forbidden to create/edit such files in anything but Microsoft software. Would you also want LibreOffice/OpenOffice/Apple's very own Pages/Numbers/Keynote to not be able to read such files?

[ToucanLoucan]

> What about for those who do own an Apple device and thus paid the "tax" to use iMessage, but want/need to use it on unapproved devices out of convenience?

You'd probably be told no, that you can only access it via Apple's devices. Your options there are to access it via approved devices or use a different service. You cannot arbitrarily bypass requirements to use it how you want to use it and expect Apple to just organizationally shrug their shoulders.

> The argument would be very different if Apple merely restricted the service to Apple IDs associated to a valid Apple device purchase, but that's not what they're doing.

That's correct. They only want their hardware and software on all ends of this traffic. That is not inherently unreasonable or anti-competitive and is likely spelled out in the terms of service.

> Would you also apply that argument to Microsoft Office files? Microsoft would sure love it if it would be forbidden to create/edit such files in anything but Microsoft software. Would you also want LibreOffice/OpenOffice/Apple's very own Pages/Numbers/Keynote to not be able to read such files?

I think it would be a bad decision on the part of Microsoft to attempt that, as the file formats are already supported by other software and artificially restricting them to only Microsoft apps would only serve to drive users to Libre/Open office, but ultimately having proprietary file formats that are crypto-graphically secured is also not without precedence and also not inherently anti-competitive. At my current employer we sell specialized software for maintaining machinery, and our files are locked right down because that's how we make our money: the ability to open, save, and utilize our files is our entire business model so you're damn right it's secured. That's not anti-competitive either: if you don't like how we do our business, you are free to use a competitor's product. What you're not free to do is crack open our software and use it anyway.

Edit: I'm being rate limited:

> This is closer to a Telcom/Basic Utility law issue

No, it isn't, because iMessage is not the only way to text on an iPhone. It degrades gracefully into full compliance with SMS/MMS protocols to allow it to text Androids, Blackberries, or flip phones.

> and is the default way to text message on this "basic utility" platform

No it is not, SMS/MMS is. If your iPhone is in a particularly bad data area, it will also SMS other iPhones absent it's ability to contact the iMessage service.

> Interoperability should be a given

IT IS.

[Nextgrid]

> as the file formats are already supported by other software and artificially restricting them to only Microsoft apps would only serve to drive users to Libre/Open office

Obviously the formats have already been reverse-engineered long ago. But the world you describe and wish for, such reverse-engineering would be illegal, thus those formats would never have been reversed & implemented in third-party software.

> our files are locked right down because that's how we make our money

If your client software is able to open the files then it means the key must be on the user's computer (in your application binary?) or fetched at runtime over the internet and a user can technically make their own software to obtain this key and decrypt the file.

> What you're not free to do is crack open our software and use it anyway.

What if the user pays for your software (and its implicit access to any online key server that serves the cryptographic keys) but instead uses their own replica that mimics this software? That's what's happening when an Apple device owner (having paid for access to iMessage) decides to use Beeper. Both you and Apple still make money in this case. Should this still be illegal?

> you are free to use a competitor's product

I'm not sure what the nature of your product is, but this gets murky if your product relies on proprietary file formats or centralized services like iMessage. In this case, using a competitor would be inconvenient or might be outright impossible if everyone else is using this software and expects you to be able to open their files or interoperate with them.

Why should we allow arbitrary roadblocks to interoperability that don't accomplish anything beyond strengthening monopolies and restricting end-user choice and convenience? It would be fair if Apple argued for a reasonable fee to allow iMessage access to non-Apple-device owners but they've never made such argument.

[ToucanLoucan]

> What if the user pays for your software (and its implicit access to any online key server that serves the cryptographic keys) but instead uses their own replica that mimics this software? That's what's happening when an Apple device owner (having paid for access to iMessage) decides to use Beeper. Both you and Apple still make money in this case. Should this still be illegal?

Again, you and most critics are keeping your examples and your metaphors solely isolated to your phone, your device, your computer and this is not the case. iMessage chats are not peer-to-peer, they reside on a platform which Apple pays to host and operate. You are not just using your device, you are using their devices too via the API.

No examples put forth in your comment or other comments are grappling with this reality. The iMessage API doesn't call other Apple devices, it calls Apple's servers, and Apple owns those servers and is within their rights to dictate how they are used. Every photo sent, every live photo, video, voice message, all are hosted and archived forever until the user deletes them on Apple's servers. That in and of itself is, in my mind, justification to restrict the service's use to their own devices.

[closewith]

> You cannot arbitrarily bypass requirements to use it how you want to use it and expect Apple to just organizationally shrug their shoulders.

Corporate policies aren't absolute. It doesn't matter if a provider dislikes the manner in which it's services are used if that use is found to be protected by law, which is obviously what Beeper is hoping for.

[topato]

But what about the companies that make the machinery that you produce software for? Shouldn't they have the right to prevent you from accessing their built hardware and force companies to get service from them directly? Obviously I don't know what your company does exactly, but it and Microsoft are both very bad examples. This is closer to a Telcom/Basic Utility law issue, imsg is used by roughly half of Americans, more than half in Europe, and is the default way to text message on this "basic utility" platform. Interoperability should be a given and it's closer to a Ma Bell situation This is starkly similar to the tweaking of antimonopoly practices that needed to be hammered out back in the 80s to break up Bell.

[doix]

> imsg is used by roughly half of Americans, more than half in Europe

Is it really used by more than half in Europe? Obviously anecdotal, but I have never encountered it. Almost everyone is on WhatsApp/Telegram/FB messenger or some other non-SMS based app.

[msteffen]

> No, it isn't, because iMessage is not the only way to text on an iPhone

It’s the only way to get an encrypted message into a user’s iMessage inbox, and iMessage is, unchangeably, the only possible default messaging app on an iPhone—the only one you can use from Contacts and so on.

IMO if you could completely substitute WhatsApp (or whatever) for iMessage on iPhones to the point of being able to delete iMessage completely, I actually bet a lot of the handwringing over iMessage being closed would go away. It also feels to me (IANAL) like that’s part of the anticompetitiveness. Apple uses its dominance in phones to establish dominance in messaging apps. Beeper is trying to force the messaging app (iMessage) itself open, but a world where everyone is just deleting iMessage and replacing it with Beeper, as Apple is required to allow them to do, would probably be fine with them too.

[turquoisevar]

> It’s the only way to get an encrypted message into a user’s iMessage inbox

True.

> and iMessage is, unchangeably, the only possible default messaging app on an iPhone—the only one you can use from Contacts and so on.

You kind of lost me here.

The Messages app is the default app on iPhone that handles both SMS/MMS and the iMessage protocol. So it goes without saying that it’s the only way to get get an encrypted message into a user’s “iMessage” inbox.

But it’s not the only one you can use from the Contacts app, nor is the only one you can use with Siri or the only one that pops up in the share sheet or the only one that you can use with CarPlay or the only one that you can receive notifications from or the only one that can ring your phone (if you want to count FaceTime as part of iMessage), etc, etc.

The Messages app, which supports iMessage, is the only app that can receive SMS/MMS via the cellular network. That’s pretty much the only limitation.

Other than that, there’s pretty much complete feature parity with iMessage in terms of native access, available should the third party messaging service want to implement it (and many do).

Take WhatsApp for example. WhatsApp will show up as an option in under contacts[0], WhatsApp message notifications will be read by Siri if you wear AirPods, use Siri to send messages and even set which default messaging app to use[1], have WhatsApp pop up as a suggestion in share sheets[2], and so on.

0: https://stackoverflow.com/questions/46422640/how-iphone-cont... this was 6 years ago, it’s now much more sleeker and you can set a default messaging service, but I couldn’t be bothered to upload a screenshot

1: https://i0.wp.com/9to5mac.com/wp-content/uploads/sites/6/202...

2: https://wabetainfo.com/wp-content/uploads/2019/12/WA13_Share...

[haswell]

> How so many HN readers can justify flagrant misuse of private API's and servers as some sort of liberatory move

So that I better understand your position, would you feel differently if Beeper Mini was just a GitHub repo hosting the code to an unofficial 3rd party iMessage client? Why or why not?

HN as a community is made up of quite a few people who care about interoperability, the right to use our computers as we see fit, the joy of building solutions to solve problems that other people won’t solve, etc.

What is surprising to me is the growing number of comments that are defending Apple and framing the creation of an unofficial 3rd party client using terms like “flagrant misuse”.

Don’t get me wrong. I didn’t expect Apple not to fight this, but I think we need to walk back the hyperbole a bit and consider how utterly normal it is for developers to try to build their own clients when the official options either suck or are too restrictive.

I do think that trying to charge for the service was a questionable decision.

[ToucanLoucan]

> So that I better understand your position, would you feel differently if Beeper Mini was just a GitHub repo hosting the code to an unofficial 3rd party iMessage client? Why or why not?

I mean, I think using that code would be a risky proposition at best that might earn you as a user the ire of Apple, and I wouldn't personally do it, but ultimately, showing people how to do a thing, or even providing the executable I don't think itself is a crime.

That said, I would also not be remotely surprised if Apple figured out how to block it's access to it's API's too. And, if there is money involved or if the breach is egregious enough in some other way, I don't think it would be altogether unexpected for the authors to find themselves in some legal hot water too, and/or for Github to receive a takedown notice.

> HN as a community is made up of quite a few people who care about interoperability, the right to use our computers as we see fit, the joy of building solutions to solve problems that other people won’t solve, etc.

Which I respect on the whole, but the key difference here is you are not just using your computer/smartphone, you are using Apple's computers too. That's where I find the disconnect. Each time Beeper Mini connects to those servers it is using compute resources, however infinitesimal, to perform it's functionality: functionality that is not supported, that fundamentally, Apple is now paying for. And you can justify that any way you want, but at the end of the day, that's stealing. And Apple is perfectly within their rights, IMO, to block it and if they feel they have a case, to pursue it legally afterwards.

> Don’t get me wrong. I didn’t expect Apple not to fight this, but I think we need to walk back the hyperbole a bit and consider how utterly normal it is for developers to try to build their own clients when the official options either suck or are too restrictive.

And if you're talking about open protocols or API's, you have my support 100%! I've done some of that kind of work. But you can't just use API's that are publicly available but otherwise closed to you just because you want to. That's textbook misuse.

[haswell]

> but the key difference here is you are not just using your computer/smartphone, you are using Apple's computers too ... you can justify that any way you want, but at the end of the day, that's stealing.

I think that boiling this down to something like "stealing" oversimplifies something that can't be reduced to a singular notion as such. I think there's a case to be made that it's not approved use of the various API endpoints, but there's more nuance than just theft of CPU cycles or services. For sake of argument, I'm deeply embedded in the Apple ecosystem. I have a half dozen devices that are all capable of communicating via iMessage. If I want to bring an Android device into my personal ecosystem, it doesn't seem clear ethically or morally that there is some theft occurring. I realize there are other scenarios where someone has no Apple devices, never intends to, and would be in a weaker position, having never "bought in".

How do you feel about web scrapers mining the open web and profiting from the results? Or browser automation tech that logs into websites as if there's a user at the keyboard for the purpose of building automated interactions with services that do not provide public APIs, e.g. Quicken banking connections? I'm bringing this up primarily because there is a whole ecosystem of products that exist based on brute force workarounds to a lack of public APIs. The existence of this kind of tech would equate to similar kinds of "misuse" if only judged based on whether or not the service provider intended for this use case and whether or not the client was using some publicly blessed integration channel.

> But you can't just use API's that are publicly available but otherwise closed to you just because you want to. That's textbook misuse.

I think it's reasonable to say that in some scenarios, such use could be classified as misuse. But I don't agree with a blanket statement that "using undocumented APIs is misuse".

When the subject is creating a client for the purpose of interoperability, and when the client implementation is using the underlying APIs/services for their intended use case (i.e. to provide feature parity with the 1st party client e.g. calling the API that sends a message does so for the purpose fulfilling the feature-equivalent send message functionality in the 3rd party client), it seems like this is all a lot greyer than "textbook misuse". Textbook misuse would be building an iMessage spammer bot.

[ToucanLoucan]

> but there's more nuance than just theft of CPU cycles or services.

CPU time, network bandwidth, storage space, the infrastructure to drive the rest, the fat, fat internet pipes to handle half of the United States' text messaging demands...

> For sake of argument, I'm deeply embedded in the Apple ecosystem. I have a half dozen devices that are all capable of communicating via iMessage. If I want to bring an Android device into my personal ecosystem, it doesn't seem clear ethically or morally that there is some theft occurring. I realize there are other scenarios where someone has no Apple devices, never intends to, and would be in a weaker position, having never "bought in".

The ethics aren't the issue. The stealing isn't a problem because it's morally wrong; it's stealing because it's against the terms of use. It doesn't matter if you own 150 iPhones and 1 Android: the iPhones meet the requirements, the Android does not. And Apple has no legal, ethical, or market obligation to allow it in, they just don't. You can text the Android from the iPhone and vice versa and it will function completely correctly in both directions, with full support for the open protocols.

> I'm bringing this up primarily because there is a whole ecosystem of products that exist based on brute force workarounds to a lack of public APIs. The existence of this kind of tech would equate to similar kinds of "misuse" if only judged based on whether or not the service provider intended for this use case and whether or not the client was using some publicly blessed integration channel.

I think you're free to do it and the provider of the service is in turn, free to make your workdays a living hell in a never ending escalating pattern of back-and-forth modifications, or free to ignore you if they don't care. Quicken apparently doesn't care, Apple does. Those are respectively their responses and both are right depending on the organization's priorities.

Most web-scraping I see is pretty gray on ethics too though, things like the stack overflow clones that piss all over the information with ads and try and SEO themselves in front of the posts they're ripping off. Personally I think all those web operators can locate a fire to die in.

> I think it's reasonable to say that in some scenarios, such use could be classified as misuse. But I don't agree with a blanket statement that "using undocumented APIs is misuse".

This is not undocumented, it is documented and said documentation is kept private because it is not meant for anyone's use outside of the organization.

> Textbook misuse would be building an iMessage spammer bot.

And it could be easily made the case that this is exactly the reason why Apple demands you own Apple devices to use the iMessage service: Because it can't be automated on their own hardware, and because it can't be used by other devices/endpoints, it is much, much, much harder to spam via iMessage. In fact I'd say it's bordering on impossible unless you buy an iDevice and do it by hand, at which point, Apple can see your suspicious traffic and disconnect you from the network, possibly without you even knowing you've been.

That's not to say they couldn't secure it in a way to combat abuse, but again, why? What does Apple gain here apart from a happy nod from a userbase that is wanting to use an Android phone and an iPad? iMessage is a free service that Apple fans enjoy using. They gain nothing by making it open to people who don't use Apple devices, and that freedom for you comes at a security cost to the platform as a whole and the users in it. Apple is very clear that their priority (apart from profits) is their users, and this gains their users incredibly little while opening the platform to much wider instances of abuse that are already incredibly common.

And even aside of my views and understanding of systems integrity and API use/misuse, frankly, even just the anti-spam excuse would be enough for me to support them in this unilaterally, because as a service, iMessage is the only platform I make regular use of that I don't end up getting calls about my cars extended warranty, or messages from hot russian women who want to bang me, or people asking to buy my stupid house, or assholes telling me they've hacked my PC and are going to send videos of me jerking off to my family, or whatever the hell. And if the closed ecosystem is the only way to do that, which it kind of seems to be, then close the ecosystems I say.

[whynotminot]

> HN as a community is made up of quite a few people who care about interoperability, the right to use our computers as we see fit, the joy of building solutions to solve problems that other people won’t solve, etc.

lol dude this wasn’t reverse engineering your lawn sprinklers to work with a raspberry pi. In effect this was always an abuse of services Apple funds and intends to be a value add for only their customers.

(Coming from someone who wishes Apple would just go ahead and release iMessage for android.)

[rezonant]

Invoking the CFAA for messaging interoperability is a pretty dystopian take. If it were as open and shut as you think it is, then why didn't AOL use the CFAA against Microsoft for doing exactly what Beeper is doing in MSN Messenger?

[sgustard]

Apple is a massive company that swats away pesky threats all the time. It's like Exxon executives losing sleep over a guy with a hose siphoning gas from the corner station. From a PR standpoint they won't dignify it with a response of any kind, other than to quietly crush it to dust.

[amazingman]

>Beeper put them between a rock and a hard place

"Should we allow a third party we have no control over to man-in-the-middle our end-to-end encrypted messaging service or not? This is a tough one!"

[hn_throwaway_99]

> "Should we allow a third party we have no control over to man-in-the-middle our end-to-end encrypted messaging service or not? This is a tough one!"

That's absolutely not what's happening, and I think Beeper's response here was totally correct.

There is no encryption, at all, between iOS and Android clients if the iOS user is using iMessage. And, furthermore, my understanding is that the presence of a single Android user in a group chat means nobody gets an encrypted messaging experience.

In the past, Apple's response to this has literally been "Buy your grandmother an iPhone". How can anyone not call incredible amounts of bullshit when their response to a company that actually let, for the first time, an Android user have an encrypted conversation with an iOS user as "This is unacceptable, we can't allow this" and claim it's because Apple cares about user security???

Not enough BS chutzpah in the universe for that one.

[Nextgrid]

Nobody is MiTM'ing anything. Individuals willingly provide their credentials and only get access to their own messages - the same messages they can voluntarily take screenshots of & publish by logging into a real Apple device. Furthermore, Beeper's app runs entirely on-device with an optional cloud-hosted bridge that may not even have access to the plaintext.

[dylan604]

It is pretty much universally frowned upon to provide your credentials to a 3rd party. Plenty of places will suspend your account if discovered you have done this. Building a product that relies on receiving user's credentials to 3rd parties is just building your company on a foundation of very dry/loose sand

[Nextgrid]

To be fair, Beeper Mini operates entirely on your device, the optional cloud component is there because there's literally no other way. It's like an e-mail client, or an FTP or SSH client, or a browser. Are those considered bad now?

> Plenty of places will suspend your account if discovered you have done this.

Plenty of services base their business on restricted interoperability and suspend your account not because of security but because they'd miss out on all the "engagement" they get from the official client. This has nothing to do with security.

[dylan604]

In the rare time I'd make a pro-Twit...er, X comment, if the platform makes its money from ads being delivered next to the content and then 3rd party comes up with a way to provide the users an ad free experience, OF COURSE they will not be happy with that. But this isn't specific to that particular platform. Any time you assist users in circumventing a method for the platform to earn money will be viewed as hostile. If you are build a product and pay a licensing fee to offset the lost earnings, then that would be potentially viewed as less hostile even if still not 100% accepted by the platform.

This isn't rocket science.

[ClarityJones]

> Plenty of places will suspend your account if discovered you have done this.

And yet that's not the route Apple chose to take.

[dylan604]

if you can take out the 3rd party tempting Apple users from doing this, then Apple doesn't have to lose those users. doesn't seem very strange for them to do this. however, if it's not something that Apple could control on their end, then they probably still have the "suspend user" club in their bag

[heavyset_go]

Wait until you discover how Plaid works.

[dylan604]

I very much am aware of how Plaid works and will not use it.

Someone recently really tried to get me to use Chime. As soon as the "must use Plaid" part came up in their onboarding, I stopped immediately. It's just a shame that I had already provided Chime so much of my information just to stop there.

[mplewis]

Plaid is also bad.

[notpushkin]

Plaid is bad, but is there another way? (OAuth and PSD2 could be, and IIRC they use that for banks that support it, but many banks don't.)

[amazingman]

Beeper's app is the MiTM. I already have to trust Apple not to abuse their privileged position re: e2e iMessage. Now I have to trust Beeper, Apple, and Apple has to continuously trust/verify Beeper. Privacy and interop are fundamentally in opposition here, and I find Beeper's PR approach regarding this to be misleading at best.

[Nextgrid]

Beeper is as much of an MITM as your e-mail client is one, or your FTP client, or your SSH client, or your browser. Should those also be frowned upon? After all, they both implement a cryptographic protocol and have access to the plaintext.

You also don't have to trust Beeper because you are not obliged to use it. You are welcome to not use it (and buy an Apple device) or even fall back to SMS.

The recipient can themselves decide what level of security they want and whether they trust Beeper (but they don't need Beeper to compromise their security - they can just as well post screenshots of your E2E-encrypted messages with them, make a backup on a compromised computer or leak their Apple/iCloud credentials).

[amazingman]

Email isn't end to end encrypted. FTP and SSH are client-server protocols whereas iMessage is client-server(s)-client.

Do you actually believe these things you're claiming, or are you arguing for the sake of contrarianism?

[Nextgrid]

> Email isn't end to end encrypted

E-mail can be end-to-end encrypted; you can use PGP (of which there are multiple implementations, all compatible) or some other custom cryptographic protocol. Having multiple compatible implementations does in no way prevent it from being secure.

> FTP and SSH are client-server protocols whereas iMessage is client-server(s)-client.

I don't understand how iMessage and FTP are different? Both have a server which mediates communication between different clients. The FTP server accepts & persists files which other clients then see and can download. The iMessage server does something similar but with messages.

> Do you actually believe these things you're claiming

Yes? I believe every person should have the right to choose which software they use to interact with services, whether it's first-party, third-party, or their own creation. I don't know nor care which browser you're using to read & reply to my comments and shouldn't have a say it in in any case - whatever happens on your machine is your own business only.

I don't understand what is so extreme about my position? It's like arguing that being able to open & create Microsoft Office files in anything but a Microsoft-approved version is heresy.

[advael]

This is a great illustration of how you can only take Apple's security claims seriously if you don't understand them.

One of the primary benefits of end to end encryption is that it can protect messages from an untrusted carrier. In other words, a proper encrypted messaging setup is not vulnerable to man-in-the-middle attacks

[amazingman]

>When sending and receiving Signal, iMessage and WhatsApp messages, Beeper Cloud's web service acts as a relay. For example, if you send a message from Beeper to a friend on WhatsApp, the message is encrypted on your Beeper Cloud client, sent to the Beeper Cloud web service, which decrypts and re-encrypts the message with WhatsApp's proprietary encryption protocol.

> Using native chat apps independently may be more secure than connecting to other encrypted chat networks with Beeper Cloud.

https://www.beeper.com/faq#how-does-beeper-connect-to-encryp...

Please tell me more about how Beeper can't be used as a MiTM for E2E encrypted networks like Signal.

[advael]

So is the issue that there's a cloud web service that interacts with some of the proprietary protocols? That definitely is another point of trust and it would seem weird that they do it that way, especially for protocols that aren't proprietary. For proprietary ones, this might be necessary to dodge intellectual property liability claims that could take the whole thing down, which is a great argument for not allowing security-critical proprietary code to be protected by law in this way, but that's just a plausible reason for them to have this problem, not a reason it doesn't matter

I appreciate you pointing out specifically what the problem was rather than just repeating that it was insecure, rather than how, and admit what I said was, as far as I now know, wrong

That said, what are the odds that Apple would accept a solution that was encrypted on-device? If this were feasible, would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?

I think the main issue I see with iMessage that this highlights is that it's presented in a way that's deceptive to its users, and thus might give them a false sense of security in their messaging. An interoperating client on android is a band-aid for this problem at best, but it's a weird move to block it. I guess for now there's the plausible deniability of what appears to be a real issue though. The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue

[amazingman]

>what are the odds that Apple would accept a solution that was encrypted on-device?

We probably agree that the odds hover just above 0%

>would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?

We could agree in principle that they would be wrong to, _if_ there were a clear path to continuously verifying that a third party client is behaving above board. Unfortunately that's just not the case. AFAIUI, this is still an intractable issue with encrypted communications. Is it an impossible problem? Probably not, but the amount of sustained effort this would require from Apple (and the 3rd parties) seems unworkable. So given that reality (I think), I don't think Apple are wrong to disallow third party clients for their E2E encrypted service.

>The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue

Yeah, I don't disagree here. I can only say that this is par for the course when it comes to Apple's PR. They would basically never explicitly state that their E2E encrypted service is at risk of a MiTM attack due to third party clients. Instead we will get very generic language and be left to fill in the blanks ourselves.

[Nextgrid]

Keep in mind that you are linking to the FAQ for the original Beeper (now renamed Beeper Cloud), this is a Matrix-bridge-based where the bridge and homeserver have access to the plaintext. You could still technically self-host both components if you wanted to.

Beeper Mini was a completely self-contained app that implemented the iMessage protocol on-device and did not use bridges. Its only optional cloud component was a push notification bridge that wasn't actually given the E2E keys (the cloud proxy would receive your messages but not be able to decrypt them, instead it just sends a push to wake up your device which will fetch and decrypt them).

[advael]

The discussion of the technical details of this has such a low signal-to-noise ratio, and I think the blame for that lies mostly with companies who try to set themselves up as infrastructure but maintain significant secrecy about how their tech actually works

[nwiswell]

> Furthermore, I bet Beeper was outright hoping for a lawsuit from Apple

Doubtful. Beeper has several legitimate causes of action to bring their own suit, if they really expect that outcome (and more importantly, if they have the financial resources to litigate)

[Nextgrid]

Beeper wouldn't have any arguments to stand on had they initiated the lawsuit - after all, Apple is allowed to make changes to their protocol as they see fit.

However, the regular pattern we've seen is that companies use copyright and/or ToS as basis for C&D'ing (with threat of litigation) developers that produce adversarily-interoperable solutions.

If Apple did so (and Apple would've absolutely done it if Beeper wasn't a reasonably well-funded adversary), Beeper would suddenly have an argument, as well as the support of the media ("Apple sues small company for opening up iMessage to Android") and the potential to establish a legal precedent that would threaten not just Apple but the tech industry at large.

[JumpCrisscross]

This isn’t how the law works. If it’s a valid defence, it’s a valid injunction.

[Nextgrid]

I don't think neither Beeper nor Apple is doing anything illegal here. Neither has any legs to stand on for a lawsuit.

However, it's a common pattern that large companies can shut down adversarially-interoperable projects by threatening litigation against the developers. The lawsuit might be baseless but would still require upfront resources to defend; this is what these companies rely on, so they get their way without the argument ever getting into a courtroom.

If Apple brought forward such a lawsuit and Beeper actually litigated it to the end (and actually got it into a courtroom), it would risk creating a legal precedent that would enshrine adversarial interoperability as legal and make such future bullshit legal threats ineffective. That is a major risk not just for Apple but the tech industry at large.

[JumpCrisscross]

Sure. But if that were Beeper’s goal, they’d file for an injunction. Waiting for someone to sue you to set precedent isn’t a thing in civil law.

[Nextgrid]

Fair enough. I'm obviously just speculating here and my knowledge of the US legal system is hearsay.

However, it seems that Beeper effectively got what they wanted (bipartisan calls for regulatory action against Apple, and lots of media coverage over the issue) without any lawyers being involved.

[GeekyBear]

> I don't think neither Beeper nor Apple is doing anything illegal here.

Beeper could definitely be prosecuted by the Feds.

Aaron Swartz is probably the most famous example of someone being prosecuted using the Computer Fraud and Abuse Act. He was merely accessing a web server without permission and wasn't even trying to turn a profit.

[lxgr]

The question is: Would they really?

There are many instances of "adversarial interoperability" (somebody else already mentioned screen scraping of online banking for budget management tools already in a different thread), and I haven't seen the CFAA being thrown at the responsible parties all that often.

I'd be quite curious to see precedent being set here, but I doubt it'll happen. Apple has much more to lose than to gain from that:

They can play cat and mouse on the tech side as long as they want, but with all the attention and scrutiny of a lawsuit, I could see a small chance of Apple ending up having to open up their service for interoperability.

[madeofpalk]

Executives, absolutely not. Apple is so opinionated and principled. Have you seen the emails that came out during recent trials where they state so clearly how much they deserve 30% of all commerce on their devices?

They would have firmly believed that iMessage is their service that no one else has an entitlement to. If they had any involvement, it would be just one email to say to shut it down, and then never thought of it again.

[Nextgrid]

It's not about what they believe, whether legitimately or not. It's about how the regulatory environment will react to their actions and statements.

The outcome of this Beeper saga is a bipartisan call for an antitrust investigation, suggesting even politicians are starting to doubt Apple's narrative and intentions.

This is dangerous ground as it could force them to do things they don't want to regardless of how rightful they believe themselves to be.