Don’t build apps that encrypt customer data | Hacker News Reader

Don’t build apps that encrypt customer data

developer.amazon.com

141 pointsballadeer43 comments

They're going for user experience, not security.

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.

Unless it's convergent encryption or if the user has a way to share the key across apps.

Cryptomator solves that problem fine, and incorporates into major storage providers anyways.

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.

from the dev forum:

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

... so the EncFS-backup-your-6TB-media-drive trick isn't threatened yet? That's good.

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.

Unless they clarify their intent and guidance, I read this as "Don't use Amazon drive".

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.

> Don’t build apps that support commercial use

Doesn't make much sense either.

I read it as "Don't build apps that let people back up their entire datacenter to Drive"

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

> (e.g., do not copy the look and feel of Amazo Drive branded apps)

Amazo!

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

Well, Facebook definitely knows what I was searching recently on Amazon, as it shows me ads with the same (rare!) products that I browsed (didn't buy) on Amazon.

Clearly, they sell my data to Facebook. Can they sell some aggregates over your Amazon Drive?

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.

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.

Could also be an additional defense against "Don't build apps that promote illegal peer-to-peer file sharing"

Unlimited cheap storage is probably a magnet for pirated videos. Encrypting (or just obfuscating) them would be an obvious step to avoid detection.

Only applies to Amazon Drive? So I'm assuming that they don't want ransomware-type third-party apps.

They have Arq backup in the gallery, which uses data encryption so maybe they just mean don't encrypt where it's not necessary?

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.

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.

Maybe it's in the context of a malware?

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

what's a not dumb scheme?

It's probably:

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?

The client/server model is great for capitalism but no good for liberty.

what is the limit of "Unlimited Storage" in drive? 100gb? 100pb? or even more?

Several folks on /r/datahoarder have 100+ TB stored there without issue. You'd have to try pretty hard to run into any soft limits they've set.

Do not encrypt it because then we can steal it.

Don't use AWS. There, fixed that for you.

> Don’t build apps that encrypt customer data

Sarcastically interpreting this directive as non-generously as it is worded: don't use SSL?

This title is click bait

Yeah the title is highlighting one part of the text 70% down the page, but it does seem to be a disconcerting part of the text.

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.

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"

Reply on news.ycombinator.com