Every attack ever uses something that can be described as "official channels." It's all in the code, after all. As Apple's response makes clear, this is indeed not via the official channels.
"Authorization" in the legal sense != authorization in the cryptographic sense. You can get a token and still be not legally authorized to access a system.
So because of this you're more likely to purchase an Android product on your next device refresh? I don't see how that logic works out... "My family shouldn't have to use the inferior protocol, so next chance I get I'm going to switch myself to that protocol?"
That's not generally true in practice. Especially when it is marketed to end users as a TOS-violating product and doubly so when it was originally a commercialized product.
Under this logic, no hacking would ever be illegal. After all, there's obviously no way any attacker ever did anything the code actually made impossible.
Fortunately, courts aren't computers, judges aren't compilers, and legal code isn't a programming language.
> Reverse engineering for the purpose of interoperability is explicitly allowed.
In Apple's iMessage TOS? I don't find that likely but open to being wrong.
> Also, breaking the TOS is usually not illegal
In general, contracts are legally binding, therefore breaking them is illegal. Sometimes contracts include clauses that can't be legally binding, but I don't think a TOS forbidding this type of behavior would be questionable in the slightest. Apple obviously has no obligation to allow anyone to use its platform as a backend for their own (previously commercialized) product.
Either they're authorized to use the service and (almost certainly) signed a TOS, or they're not, in which case they're using the service unauthorized.
Not a lawyer but I don't see what else could be true here. I suppose you could say the end users are the ones violating the TOS? I don't think it'll land with any judge, "your honor we just did the reverse engineering (without signing a TOS) and sold it to our users (who did sign a TOS, but didn't reverse engineer), so we're all clean."
Does this make you less likely to purchase an Apple device in the future?
TBC, I also don't necessarily view this as a positive. I just don't see it as a negative whatsoever. It would be nice to be able to chat with Android friends over iMessage, but it's not offputting at all that an outside company trying to monetize reverse-engineered "hacks" onto the protocol are getting booted.
(Yes I know it's not "hacking," but it is obviously hacky)
I pay Apple to manage my mobile device experience. That is literally why they demand and receive a premium over the alternatives. Why do you think Apple customers are some helpless and ignorant victim, and not people specifically placing their bets with a company that has delivered exceptional products at the expense of rather fringe philosophical views on "openness?" I don't care about "openness" nor taking down "corporate greed" in this context, I care about having a great experience using my own mobile device.
FWIW there was an era where I felt differently. I was very active in the early Android jailbreak community. It was fun and the freedom has benefits, but those are benefits that I've deliberately chosen to give up for the benefits of the other end of the spectrum. I wasn't tricked into giving them up and neither was anyone else: people are paying Apple for the experience Apple is trusted to deliver. The reason people trust them is because they deliver it. It's super simple.
It's just worse than the alternative that Apple provides for its own ecosystem of users. Any Apple user is free to opt for that more universal system if they want.
I don't think this is painting Apple in a negative light for their actual customers, who pay them money. It's painting them in a negative light for a small segment of Android users who obviously are unlikely to switch to Apple anyway.
Layers work to the degree that you don't need to be a subatomic particle physicist to write this comment.
There are good abstractions and bad ones, all with varying degrees of leakiness and sharp corners. The good ones definitionally prevent you from needing to understand much about what they're abstracting.
> To successfully use an abstraction, you need to understand the problem the abstraction is trying to solve and also understand how the abstraction has solved the problem.
What? This seems like the exact wrong way to view abstractions and in fact, you view it the right way even if you think you view it the (silly) way above.
The whole point of abstraction -- not just in software but in everything in the universe -- is that you do not have to know or care about the underlying facts.
The whole stack is abstractions all the way down to the sub-atomic level, so it's obviously untenable for "correct usage" to require knowing the lower levels. Just like you (correctly) don't need to understand structural engineering or wood's growth patterns to sit in a chair made of wood.
It's very useful to know a few layers below the layer at which you primarily operate, but that is a very different from the claim up top.