[Nextgrid]

Does it matter if an Apple device user (having bought a device and paid Apple for access to iMessage servers) subsequently makes software that mimics this Apple device's interaction with the servers but runs this software on his Android device?

We'll assume it's still a single person using it, thus whether they use it on Apple or Android, the amount of messages sent shouldn't increase (they'd just be spread across the two devices) and server load should thus remain constant.

Would it be a problem? You're coming back to the idea of cost but not only are those costs negligible but Apple has never made any argument about it even though Beeper was open to paying a reasonable fee.

> it calls Apple's servers, and Apple owns those servers and is within their rights to dictate how they are used

Should websites then also be allowed to dictate that your browser should not run an ad-blocker, should accept (and persist!) cookies and not run a VPN? I'm sure websites would indeed love that but I think we'd both agree this would be a very sad day for the internet if this became law?

I think the control stops at the protocol. Apple is welcome to change their proprietary, undocumented protocol as they see fit, but people should also be free to reverse-engineer and implement clients for it. As long as the client perfectly mimics the official one (including proving any eventual purchase, using an Apple ID associated with an Apple purchase or the serial number of an Apple device the user purchased) there should be no legal/moral reason it should be rejected.

[jpc0]

> Does it matter if an Apple device user (having bought a device and paid Apple for access to iMessage servers) subsequently makes software that mimics this Apple device's interaction with the servers but runs this software on his Android device?

From what I got from this news cycle, if this was the case and beeper mini just made you use your apple device's "hardware token" this would never have been an issue and apple would not have locked down their use.

The thing Apple blocked was hundreds to thousands of users using the same "hardware token" which means beeper mini, probably rightfully for UX reasons, didn't want Apple customers doing this but it would also gate a feature to only Apple device owners.

So if beeper mini had actually just used your Apple device's "hardware token" and only offered the feature to Apple device owners then likely all this never happens and Apple devices owners would in fact have the benefit.

[ToucanLoucan]

> Does it matter if an Apple device user (having bought a device and paid Apple for access to iMessage servers) subsequently makes software that mimics this Apple device's interaction with the servers but runs this software on his Android device?

If explicitly forbidden in the terms of service? Yes. The ToS act as your contract with Apple to make use of the service. Violation of the terms of service terminates your access to the service. If you want to stand up your own mimic'd Apple servers then you're free to do that, but you are not free, again, to change the rules set forth by Apple to use Apple's services. I don't understand why you keep returning to this question.

> Should websites then also be allowed to dictate that your browser should not run an ad-blocker, should accept (and persist!) cookies and not run a VPN?

All sorts of websites have all sorts of requirements to use them off certain VPNs, without ad-blockers, and with cookies. Tons of websites simply stop functioning if some or any of those conditions are true for your browser.

> I'm sure websites would indeed love that

They do.

> but I think we'd both agree this would be a very sad day for the internet if this became law?

What do you mean become law? The ability for an online service to not provide functionality if you do not concede to their requirements is so benign as to be barely worthy of note. Apple included! Apple has been "excluding" Android from iMessage since 2011!

> I think the control stops at the protocol. Apple is welcome to change their proprietary, undocumented protocol as they see fit, but people should also be free to reverse-engineer and implement clients for it.

I mean, you are! They did! And then Apple found them, and made changes to their protocol that bricked what they made. That is the most likely outcome for this and any subsequent adventures along the same path.

> As long as the client perfectly mimics the official one (including proving any eventual purchase, using an Apple ID associated with an Apple purchase or the serial number of an Apple device the user purchased) there should be no legal/moral reason it should be rejected.

Because it's their platform and their right to reject it and I'm not going to rehash this point again.