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