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

[lxgr]

> Quicken apparently doesn't care, Apple does.

I think you're missing the point GP is making, and I think it's an interesting one: There's lots of precedent for offering products and services interoperating with an "uncooperative" third party (in this case, Quicken scraping banks' websites to import their customers' transactions).

Sometimes such “forced” interoperability is illegal, sometimes it's the opposite and the a regulator or legislator recognizes it as an important public good, and very often (such as here) there is no precedent and we know absolutely nothing about the legality. We can have our educated guesses, but that's it.

I'd personally be very curious in seeing a lawsuit; it seems like important precedent to have with all the FUD going around, here and elsewhere.

[turquoisevar]

> Sometimes such “forced” interoperability is illegal, sometimes it's the opposite and the a regulator or legislator recognizes it as an important public good, and very often (such as here) there is no precedent and we know absolutely nothing about the legality. We can have our educated guesses, but that's it.

You say this as if all these cases have the same fact pattern and it’s just a roll of the dice. But that’s not true and in fact there is very clear precedent that matches the facts of the case at hand.

Quicken and other scrapers are generally allowed, especially, but exclusively, when it pertains publicly accessible data.

Those kinds of cases have been tried with the main argument being the exceeding of authorization under the CFAA and copyright violations.

Courts have consistently decided that scraping doesn’t rise to the levels of computer trespass in the form of exceeding the authorization given to access the computer system and that it’s not copyright violation primarily because, to put it simply, it doesn’t exceed the authorization enough and because there’s a fair use component to it.

The most recent case law on this, which happens to involve publicly available data so isn’t fully analogue with Quicken, is hiQ Labs v. LinkedIn[0]

However, there’s also case law on clauses in EULAs and ToSs that prohibit reverse engineering (like in the case of Apple’s EULAs and ToS) that says those clauses are not only enforceable but they supersede the DMCA reverse engineering exception.

In fact the case law is even more relevant for this Beeper debacle, because it also happens to pertain to a company that reverse engineered another companies software, repackaged it to then sell it for a price, like Beeper tried to do with Beeper mini for $2/mo. That case law is still good standing case law and is Bowers v. Baystate Technologies, Inc.[1]

0: https://en.wikipedia.org/wiki/HiQ_Labs_v._LinkedIn

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