A few months ago, I was doing extensive research on personal cloud backups (Backblaze, Amazon Cloud Drive, etc). My requirement was to have client-side encryption synced to the cloud. A modicum of googling led me to rclone. After reading about how rclone works, I immediately made a mental comparison to Amazon's "official" client GUI sync program and thought, "there's no way Amazon has blessed rclone." It would be very risky to invest hours into building custom backup scripts built on top of rclone if Amazon blocks it. Well, it turns out that's exactly what has happened.
rclone was blessed by Amazon. It was an official app developed by a developer using their official API.
And now, without any warning, it is not. For many use cases, rclone is the only practical way of getting data in and out of Amazon Cloud Drive.
Amazon still hasn't bothered contacting me to let me know. Despite the fact that rclone was used with my Amazon Cloud Drive account daily.
"Oh hey FYI, we've disabled the app you use to access your data, good luck getting your data, have a nice day" would have actually been better than they approach they chose instead (disable my access + radio silence).
Fortunately I planned for this eventuality.
But this is yet another striking reminder of how foolish it would be to doing anything important while depending on just one cloud company.
After the thunderstorm, when the sun shines, often the clouds are no longer there.
Link as originally submitted leads to a commit message where the submitter, maintainer of git-annex-remote-rclone, a tool which wraps the multi-provider cloud storage client rclone [1], makes the following comment:
"Amazon has, without warning, revoked the API keys necessary for users to access the data that Amazon's paying customers have entrusted with Amazon. A data storage offering that simply stops working one day is not a data storage offering at all."
In effect, this is a self-submission to an opinion that leads to a dead end; I propose a better source is this reddit thread [2] which includes a screenshot of an email from Amazon support confirming the news.
As another poster writes, Amazon has revoked rclone's OAuth2 API key. However, consider that rclone's default OAuth2 client id and secret are compiled into the rclone executable, and thus effectively public; aka. anyone can extract them and pretend to be rclone, and fool users into obtaining access and abuse them for unrelated purposes.
A far better option is for the cloud provider to let users generate their own OAuth2 clients, such as Google does (and supposedly Microsoft, although for me it's always errored out). Unfortunately, Amazon has a "call us" style of Developer access, which effectively translates to no new API access being granted to these types of users.
The speculation around the web is that Amazon also wanted to shut this down because they offered "unlimited" storage, and people were using it to store very large amounts of hard-to-compress, hard-to-dedup data. Breaking a popular tool used to accomplish this (e.g. it supported on-the-fly encryption, producing the exact style of difficult data) will cause some portion of less profitable users to migrate elsewhere. This may or may not be true, but it's certainly an intriguing point.
My submission was unnecessarily terse. Thank you for expanding upon it.
I agree with all your points about OAuth2 clients. But I would also add:
All clients (Amazon official or not) will ultimately need to have API keys compiled into them, and/or use a (less secure for the user) remote service to do the OAuth flow.
And for all of these clients, it will be possible for users to obtain the keys with some very simple reverse engineering and/or protocol analysis.
Which makes this entire thing seem like a real waste of everyone's time. Provide an API/service available on the internet, or don't.
Trying to tell people exactly which configuration of which software they should use to access your service is both disrespectful of your user's freedom as well as a fool's errand.
I used them years ago as part of free trial offer but they had rate limiting for their APIs ,it was totally unusable, to upload it would take months to finish my NAS drive, so i stopped using them completely. its the crappiest i have ever seen.
EDIT: "You may not use the Service to store, transfer or distribute content of or on behalf of third parties, to operate your own file storage application or service, to operate a photography business or other commercial service, or to resell any part of the Service." I imagine "your own file storage application" is at issue here.
But if customers should only use the (reportedly awful) official app to sync files, why offer an API at all?
[+] [-] jasode|8 years ago|reply
A few months ago, I was doing extensive research on personal cloud backups (Backblaze, Amazon Cloud Drive, etc). My requirement was to have client-side encryption synced to the cloud. A modicum of googling led me to rclone. After reading about how rclone works, I immediately made a mental comparison to Amazon's "official" client GUI sync program and thought, "there's no way Amazon has blessed rclone." It would be very risky to invest hours into building custom backup scripts built on top of rclone if Amazon blocks it. Well, it turns out that's exactly what has happened.
[+] [-] DanielDent|8 years ago|reply
And now, without any warning, it is not. For many use cases, rclone is the only practical way of getting data in and out of Amazon Cloud Drive.
Amazon still hasn't bothered contacting me to let me know. Despite the fact that rclone was used with my Amazon Cloud Drive account daily.
"Oh hey FYI, we've disabled the app you use to access your data, good luck getting your data, have a nice day" would have actually been better than they approach they chose instead (disable my access + radio silence).
Fortunately I planned for this eventuality.
But this is yet another striking reminder of how foolish it would be to doing anything important while depending on just one cloud company.
After the thunderstorm, when the sun shines, often the clouds are no longer there.
[+] [-] pvg|8 years ago|reply
[+] [-] niftich|8 years ago|reply
"Amazon has, without warning, revoked the API keys necessary for users to access the data that Amazon's paying customers have entrusted with Amazon. A data storage offering that simply stops working one day is not a data storage offering at all."
In effect, this is a self-submission to an opinion that leads to a dead end; I propose a better source is this reddit thread [2] which includes a screenshot of an email from Amazon support confirming the news.
As another poster writes, Amazon has revoked rclone's OAuth2 API key. However, consider that rclone's default OAuth2 client id and secret are compiled into the rclone executable, and thus effectively public; aka. anyone can extract them and pretend to be rclone, and fool users into obtaining access and abuse them for unrelated purposes.
A far better option is for the cloud provider to let users generate their own OAuth2 clients, such as Google does (and supposedly Microsoft, although for me it's always errored out). Unfortunately, Amazon has a "call us" style of Developer access, which effectively translates to no new API access being granted to these types of users.
The speculation around the web is that Amazon also wanted to shut this down because they offered "unlimited" storage, and people were using it to store very large amounts of hard-to-compress, hard-to-dedup data. Breaking a popular tool used to accomplish this (e.g. it supported on-the-fly encryption, producing the exact style of difficult data) will cause some portion of less profitable users to migrate elsewhere. This may or may not be true, but it's certainly an intriguing point.
[1] https://rclone.org/ [2] https://www.reddit.com/r/DataHoarder/comments/6c3mnv/amazon_...
[+] [-] DanielDent|8 years ago|reply
I agree with all your points about OAuth2 clients. But I would also add:
All clients (Amazon official or not) will ultimately need to have API keys compiled into them, and/or use a (less secure for the user) remote service to do the OAuth flow.
And for all of these clients, it will be possible for users to obtain the keys with some very simple reverse engineering and/or protocol analysis.
Which makes this entire thing seem like a real waste of everyone's time. Provide an API/service available on the internet, or don't.
Trying to tell people exactly which configuration of which software they should use to access your service is both disrespectful of your user's freedom as well as a fool's errand.
[+] [-] slau|8 years ago|reply
https://github.com/DanielDent/git-annex-remote-rclone/issues...
https://www.reddit.com/r/DataHoarder/comments/6c3mnv/amazon_...
[+] [-] Jayakumark|8 years ago|reply
[+] [-] dicroce|8 years ago|reply
[+] [-] pvg|8 years ago|reply
[+] [-] astebbin|8 years ago|reply
https://www.reddit.com/r/DataHoarder/comments/6c3mnv/amazon_...
[+] [-] chrisblackwell|8 years ago|reply
[+] [-] astebbin|8 years ago|reply
EDIT: "You may not use the Service to store, transfer or distribute content of or on behalf of third parties, to operate your own file storage application or service, to operate a photography business or other commercial service, or to resell any part of the Service." I imagine "your own file storage application" is at issue here.
But if customers should only use the (reportedly awful) official app to sync files, why offer an API at all?
https://developer.amazon.com/blogs/post/TxRNQX3SWVLUYC/Amazo...