"With our updated RESTful API and SDKs for Android and iOS, Amazon Drive is moving to an invite-only developer offering to ensure we can provide a consistently viable service available for supported use-cases."
Clearly, they want to be able to spy user data.
You can easily summary this list of restrictions to:
DO NOT WRITE Amazon Drive APPLICATIONS!
(At least if you care for your customer).Personnaly, I would never write an application that would not encrypt user data, including user credentials. Basically, most services don't even need to know who their users are (unless you implement dumb password recovery scheme that requires you to send an email to the user, you just don't need ever to know anything more than a hash instead of an email in the clear!).
1) they'd rather encryption didn't become widespread on the service because they want to spy on users (users encrypting things themselves is still fine, they say)
2) they don't want support calls from people who've lost really important files because your crappy app lost their key, and/or because the user lost it, because typical users cannot and never will be able to handle manual key management, but if you encourage them to do it they might try.
When Amazon says they can't do it they will ask for the source code or a vulnerability for the software that encrypted it. That will get bounced to the developer. Does Amazon want to get into that business of selling out the people making software for them?
An app like Cryptomator may use Amazon Drive APIs to encrypt data before it arrives in the Amazon Drive. Does that cover Cryptomator? Well, we don't know, because it's so vague.
It could also very well be a purposeful thing, if Amazon wants to data mine all the backed-up data. Plus, it may want to make it easier to give the data to law enforcement (or not get in trouble itself for having that data stored in an encrypted form), and so on.