It's possible, but I think they could've been a lot more clear about that. With what they're saying now, they're leaving things in a pretty grey area, which is not good for developers thinking of building "good" apps that use encryption.
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.
Is that within the T&C for using Amaxon cloud services? Do you give up your clients privacy for amazon to be able to read and use information that hits their disks?
No, it's in the context of Amazon Drive applications:
"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.
I also wonder if it could also be that if Amazon is subpoenaed for your files and they hand over an encrypted binary the government will then ask for it to be unencrypted.
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?
That makes sense given that Amazon Drive itself is for non-commercial use: "You may use the Services only to store, retrieve, manage, organize, and access Your Files for personal, non-commercial purposes using the features and functionality we make available." from Amazon Drive and Prime Photos Terms of Use https://www.amazon.com/gp/help/customer/display.html/?nodeId...
These are very vague - could mean anything from "don't build ransomware", through "no Amazo Drive encryption apps, we'll offer that as an option" to "leave your cust data in clear so we can play with it"
Indeed - in fact, the previous paragraph states your app risks not being approved if you don't follow the guidelines!
>We want to give you some guidelines for apps not to build on the Amazon Drive platform to save you time in building something that will not be approved during the App Review process
This post's (current) title is verbatim in the content: "Don’t build apps that encrypt customer data", and in my opinion is significant and surprising enough to call out as a title.
Perhaps it interferes with deduplication/compression of the storage, which would throw off some level of storage efficiency and increase costs for Drive. That said, I don't think I would really want to use a cloud drive service that discouraged client side encryption.
What a clickbait headline. It seems pretty obvious that it is about the user experience. For example, if someone dumps 20GB of encrypted photos on Drive, no other app would be able to use that. Maybe that's what you want. But Photos are the kind of thing that multiple different applications should be able to read/write.
That's a wee bit troubling. There might be an argument for some kind of user experience, but, uh, that's not how it's actually phrased.
Obviously client side encryption is an important part of using any kind of cloud storage, so disallowing it pretty much removes any potential use of Amazon drive for me. I have some photos I don't mind being stored unencrypted, but I have plenty I'd rather not allow any and every app to have access to.
At first glance, based on the headline, I thought ARQ backup is screwed.
But, this is only for Amazon Drive storage. Which makes sense.
If you want to store encrypted personal stuff, dont use Amazon Drive. Clients like ARQ are definitely made for such cases (and are probably cheaper in the long run).
I'm pretty sure this means that you shouldn't encrypt users data without their consent, or encrypt existing data. There are plenty of 3rd party apps which have been approved by Amazon which encrypt your data client side. e.g Arq Backup
I know Stablebit Clouddrive (which does client side encryption) have been struggling to get approval from Amazon, but this is due to excessive API requests, not client side encryption.
That's probably correct. But it is still an interpretation of a very ambiguous statement. Too often, when lawyers write ambiguous statements it is because they want to exploit the ambiguity.
Don't encrypt your user's data that is stored hardware you do not own. If you have nothing to hide, you have nothing to fear. This is all in order to improve the user experience of course.
> We want to give you some guidelines (...) save you time in building something that will not be approved during the App Review process. While this isn’t an all-inclusive list (...) don’t violate our Terms of Use, Brand Guidelines and the App Distribution and Services Agreement.
So encrypting data from the customer side could make some app be blocked in the future, making me lose all my customers and perhaps their data? That doesn't sound good, why would I take a chance by using Amazon ?
You take that risk, anyway. Amazon can always change their TOS unilaterally, or duplicate the functionality of your app with their own app, and there's nothing you can do to stop it.
This is only for Amazon Drive. As others have said, 3rd party apps won't be able to make use of the data, but there's probably another reason.
I'm assuming Amazon uses fingerprinting to store only one copy of a file across their system, and just link to it if you upload the same file. If the files are encrypted they can't do this.
It's not in amazons best interests for you to encrypt your customers data - but it's likely in your customers best interests from a privacy perspective.
46 comments
[ 5.3 ms ] story [ 97.2 ms ] threadAn 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.
"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:
(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?
Doesn't make much sense either.
> What if the customer choses to encrypt their data?
>> Brian@Amazon · Feb 02 at 06:28 PM 0 >> They can do that, and that is fine.
https://forums.developer.amazon.com/questions/54909/impact-o...
Amazo!
>We want to give you some guidelines for apps not to build on the Amazon Drive platform to save you time in building something that will not be approved during the App Review process
Sarcastically interpreting this directive as non-generously as it is worded: don't use SSL?
They want users to pour data into Amazon Drive and for that to be useful to any and all applications that connect to Amazon Drive.
If one app encrypts that data, then no other app can make sense of it.
Unlimited cheap storage is probably a magnet for pirated videos. Encrypting (or just obfuscating) them would be an obvious step to avoid detection.
Obviously client side encryption is an important part of using any kind of cloud storage, so disallowing it pretty much removes any potential use of Amazon drive for me. I have some photos I don't mind being stored unencrypted, but I have plenty I'd rather not allow any and every app to have access to.
But, this is only for Amazon Drive storage. Which makes sense.
If you want to store encrypted personal stuff, dont use Amazon Drive. Clients like ARQ are definitely made for such cases (and are probably cheaper in the long run).
I know Stablebit Clouddrive (which does client side encryption) have been struggling to get approval from Amazon, but this is due to excessive API requests, not client side encryption.
So encrypting data from the customer side could make some app be blocked in the future, making me lose all my customers and perhaps their data? That doesn't sound good, why would I take a chance by using Amazon ?
I'm assuming Amazon uses fingerprinting to store only one copy of a file across their system, and just link to it if you upload the same file. If the files are encrypted they can't do this.
Is this for de-duplication or just to avoid people not being able to access files across other apps on the platform? Or both I guess.