Guys, what do you think , what the situation the own secret ID-s? Now they are working, but what will happen on the future?
If i use my storage actively (with API) possible that they ban me?
1 Like
I wrote in a got a full refund in about an hour.
For what it’s worth, my Amazon phone rep seemed to have an understanding of the issue, and while I was refused a new set of API keys, I was told that the ban was “because of a recent event” (i.e. something about the acd_cli security issue must have triggered Amazon to pull the plug on hoarders).
My rep did offer me a full refund (Amazon.ca).
I will ask for some time to migrate my data and then full refund.
I will migrate everything to Hubic, which offers 10Tb of space that will be enough for me.
Amazon is really don’t care a sh** about its costumers. Informing us in advanced would be the minimum.
I had 3 calls.
1 ) result was it will be fixed in 24 / 48 hours… asked for confirmation , confirming what we know - YES it will all be fixed.
2 ) called back as not happy with 1) was asked to hold… got cut off…
3 ) got through to someone that understood the situation, they didnt let much away but was offered a full refund straight away. (initial payment Dec / 16)
Thankfully I had already migrated to google drive for performance / reliability anyway!
@pedrosimao - Without know why it was removed, it could have been a security concern and had to be pulled. I agree notice is always great, but without details, it just stinks.
Well, this freaking sucks.
Well, it seems that Amazon really wants to sneack into your files by banning this kind of tools “ACD_CLI” and Rclone.
Too bad for this freacking guys!
Filled for a refund and got it straight away
What do you think about Microsoft Onedrive?
I’m uploading all my data right now and it works very well…and it cost same amount as ACD. I need only about 600 GB and Onedrive offers 1 TB.
I’ve updated the main post with some more info.
6 Likes
Very cool. Thanks for the update
That’s great news. Not sure if I’ll go back to ACD though. After this, they’ve lost all trust.
That sounds soooo great !
Thank you very much for your hard work !
Hope we can use the system again we where told when ordered -> Unlimited !
I got a letter from ACD support:
I’m Karthik from Amazon Digital Support.
I’m sorry for the inconvenience you’ve had while accessing Amazon Drive on r-clone. This is definitely not we want our valued customers to experience.
In this regard, I’m sorry to inform you that at this time, the Amazon Drive ended the invitation period for new third party apps. This is the reason you were unable to access Amazon Drive through r-clone.
I’d like to inform you that currently you can download files from Amazon Drive App (available for PC/Mac/iOS/Android) to sync / upload / download / connect to Amazon Drive.
…
Best regards,
K. Karthik
I’m assuming this auth server well only be used for ACD as I personally do not want my credentials to be handled by an intermediate server. This is really bad practice and I actually can’t believe Amazon wants you to do that.
As an intermediary step, the client ID / secrets should NOT be included in the rclone source code and not commited on github, and only injected at compilation time in the binaries (exactly like closed-source applications).
I could be completely wrong, but I am thinking the problem is that with open source software the api key needs to be in the source somewhere even if it is, like rclone, encrypted.
So as I see it currently the only way round this is to have a non open source auth server, so no one has any sort of access to the projects api keys.
It would be better if amazon would allow individuals to create their own api keys, like it was a couple of years ago. Then when creating a remote you would use your own api keys, so then there would be no need for api keys within the source code.
It seems Amazon kinda created this problem themselves when they closed the api.
Their API should have included xauth. They completely caused this problem themselves and now they are forcing a completely insecure approach but having a third party manage the tokens that could have been handled by the client itself.