Rclone banned from Amazon Drive for having the encrypted secrets in code
forum.rclone.org
forum.rclone.org
Now Amazon is suffering the obvious consequence of offering unlimited storage: people are using it to store tens of terabytes of media and/or backups at very low cost. In an attempt to kill off heavy users, they shut down registration of new API keys several months ago, and now they're systematically revoking the API keys used by popular open-source tools.
On the other hand, they've also killed the product for a lot of more legitimate users as well. The Amazon web interface and apps for Cloud Drive are obnoxiously terrible, and Rclone really is just a better way to use it. I've been using it to sync 10s of GBs of photos between all my different computers, but with Rclone unavailable, I'll have to fall back to Google Drive, S3, or some other option (the unlimitedness of Cloud Drive was good peace of mind).
I'll be keeping an eye on it over the next few weeks to see whether shipping a binary with OAuth secrets was actually the reason for the ban, or just a pretext for getting the Rclone users off the service (personally, I suspect the latter).
I'm lamenting Amazon Cloud Drive in particular because it was the best deal. $60 a year for unlimited storage and with no caveats (or so it seemed before last week).
Abuse doesn't mean breaking the rules. It's like going to an all-you-can-eat buffet and staying for a week. Or taking a job with unlimited vacation time and coming to work once a month.
What Amazon should do, as Microsoft should have been done in the case of the unlimited Onedrive offer is putting some clause of reasonable use.
When some company offers an unlimited resource, some of the customers will use it to upload/download/etc a lot.
They can shut down your account for the reason you stated
But it would be nicer for everyone if they could just honestly state a number of TB.
CHRIS Really?
HOPSFIELD This box makes it one million, six hundred thousand. I should win thirty two point six percent of the prizes, including the car.
CHRIS Kind of takes the fun out of it, doesn't it?
HOPSFIELD I suppose so. But they set up the rules, and lately, I have come to realize that I have certain materialistic needs.
That scene is based on a real life incident which in fact involved a McDonald's sweepstakes and Caltech students entering over a million times: [1]
Since everyone knew that the school in the movie, Pacific Tech, was meant to be a thinly disguised Caltech (it only became Pacific Tech when Caltech objected), and McDonald's had not been happy with the Caltech sweepstakes prank and probably would not want it brought up, my guess is that one or both of McDonalds and Caltech asked for the change.
Changing it to Frito-Lay is an interesting choice, because six years before the McDonald's sweepstakes, a group of Caltech students tried mass entry on a Frito-Lay sweepstakes, but apparently were not as successful.
[1] http://hoaxes.org/archive/permalink/the_caltech_sweepstakes_...
====
Lazlo: No. These are entries into the Frito-Lay Sweepstakes. "No purchase necessary, enter as often as you want" - so I am.
Chris: That's great! How many times?
Lazlo: Well, this batch makes it one million six hundred and fifty thousand. I should win thirty-two point six percent of the prizes, including the car.
Chris: That kind of takes the fun out of it, doesn't it?
Lazlo: They set up the rules, and lately I've come to realize that I have certain materialistic needs.
I feel like anyone who's actually uploading personal content and who isn't uploading media files that are amenable to deduplication would be comfortable with some threshold as well.
How is Amazon supposed to distinguish between encrypted and non-encrypted data that you upload?
There are tools to search for TrueCrypt / other encrypted partitions on disks, so it's a solved problem to detect encrypted data.
It would be unfortunate if services ban the ability to upload encrypted secrets, though. On the other hand, that'd be good for Tarsnap. I wonder how much it'd cost to store 10TB on it?
I don't think so. Random noise can take any form - even of a string composed entirely of zeros, which would be trivially compressed. It's just very unlikely that it'll actually be compressible.
It wouldn't be zero in certain math worlds. It is zero in the real universe.
I think deduplication buys them most when people upload common assets - videos downloaded from the net, ebooks, ISO images, etc.
Would this also impact Arq users? I was hoping Arq would support Backblaze...
Actually this seems to have been more triggered by a serious issue with acd_cli's authentication server that resulted in its users seeing other people's files:
- https://web.archive.org/web/20170514020241/https://github.co... - https://www.reddit.com/r/DataHoarder/comments/6bi5p5/amazons...
Amazon has started paying a lot more attention to open source tools as a result.
https://www.reddit.com/r/crypto/comments/61zupq/amazon_drive...
I learned that Amazon Drive is a service that provides unlimited storage for a fixed cost, and that various applications, including rclone, use it for an application that I would expect (as a developer) to use S3 for, and therefore to charge my users per amount of data stored. (Amazon Drive is not part of AWS, I believe.)
I am not extremely surprised that the terms of service of Amazon Drive make it hard to build a compliant application like what rclone is trying to build. I'd expect they can do this with S3 straightforwardly -- at the expense of users needing to spend O(n) instead of O(1) on their data.
They said Unlimited storage, they should provide Unlimited storage, otherwise it's false advertising.
In other words, I hate apologists.
If you stop to think about this part for a second you will realize this service is completely inadequate for backups.
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.
Some companies like Google allow easy registration of OAuth2 clients, so any rclone user can make their own API keys at console.developers.google.com and feed those to rclone, instead of having to use the built-in credential. Rclone's documentation refers to this ability, but positions it as a performance improvement for advanced users to sidestep a shared rclone-wide quota, rather than for any other purpose.
However, it, unlike many, many other applications, at least lets you plug in your own credential -- this shouldn't be an exotic flow, but rather the normal way to grant access to a third-party application, instead of distributing a hardcoded secret. Sadly, the app developer community has been slow to realize and demand this, and providers have been slow to implement it. Google lets you register as many applications as you want; GitHub even lets you make your own OAuth2 scopes. But there's few others who come close.
How does making new Google API keys help with an Amazon service?
https://github.com/ncw/rclone/blob/a9d29c22645c9b5d2ab938ebb...
Amazon has stopped giving out any more API keys (https://developer.amazon.com/amazon-drive). So I guess that isn't an option unless Amazon opens it up again...
So for example, if you want to use SomeMagicTweetTool to send tweets, they use their token to prove it's them, and you grant them a special token for your account.
Someone who has their token can pretend to be them, use their quota if there is per-software/per-provider quota, but cannot access your account unless you gave them a token for your account.
[1] https://github.com/ncw/rclone/blob/66e8c1600ec8c18cbcdce5664... [2] https://github.com/ncw/rclone/blob/66e8c1600ec8c18cbcdce5664... [3] https://github.com/ncw/rclone/blob/66e8c1600ec8c18cbcdce5664...
Clearly they didn't intend for this service to be a general backup system.
While I can understand and agree that fair-play should be a part of the service, if the offer on hand is Unlimited, then it is not abuse to upload tera-bytes, peta-bytes, exa-bytes or even zetta-bytes.
Amazon is hardly a neophyte as far as understanding big data, they are very well placed to know that offering unlimited storage could actually attract really big chunks of data.
And on the other side, many of the more extreme users of drive probably aren't new to storing a lot of data and knew that Amazons offer had to be unsustainable when used to much and thus would disappear in some way.
I'm not particular sympathetic to either sides messaging here. It's sad that rclone got caught in the middle of it.
But they don't want to do that, apparently. Why? I don't know, but it looks like they're worried some of their customers (the same ones they don't like because of excessive usage) will go over to B2 or whatever other cheap services are available, for the peace of mind of not running into any caps even if the service costs more at 2TB or 5TB worth of storage. "Unlimited" storage companies, that nevertheless discriminate against very high usage, want to have their cake and eat it too. Either state a limit and accept the risk that some of your customers decide to go somewhere else, or don't limit and don't discriminate against them. Those are the reasonable choices. Other choices are not reasonable.
while (1) { for user in userlist {
# Top .01% of users are abusive and we boot them
if usage_distribution_top(user, .0001) {
disable_account(user);
send_acctdisabled_notice_to_user(user, "Excessive usage of unlimited storage");
}
} sleep 1; }
Hours later: "How have we lost half our customers? We only ever removed the top .01% for their 'abusive' usage of our unlimited service!"If the concept isn't clear to some people, the problem is this: You can't repeatedly cull the outliers — the top x% of the distribution — because by culling you shift the distribution to create more outliers.
I'm sure businesses recognize that, intuitively if not explicitly in their planning meetings, and therefore cull rarely enough that it doesn't impact the bulk of users (in part due to influx of new users). So you cull the top x%... who decides what x is, and why, if you state in your promotional material that the service is unlimited? "If we set x to .001% and cull monthly, it'll help our bottom line. Those users are scum data hoarders anyway and we won't serve their kind with our 'unlimited' storage service." That should be lawsuit-worthy.
Companies in this situation should be forced to specify a fixed usage limit (exactly what these companies don't want to do), or live with the outliers.
They don't create a running list of the top X% of usage and ban those users. They study their customers usage for some period and find the top X%, then translate that to a fixed upper limit. Then they punish anyone who goes over that fixed limit. If their customers or technology changes, they can re-calculate that number.
As far as "unlimited": marketing is full of bullshit words that don't mean what you think they mean. Courts (no wait, its all company-paid arbitrators now) unsurprisingly favor the companies.
When the Supreme Court sided with AT&T on the binding arbitation clause, no joke I got an email from Charter Communications the very same day the ruling was released that said they updated their terms of service to include binding arbitration.
If the limit is dynamic and periodically re-evaluated, then you run into the "there's always an outlier" problem.
If the determination isn't dynamic, and Snake Inc. advertises its service as 'unlimited' instead of stating the limit, and then starts discriminating against users or tools associated with higher usage, and get a reputation of being a snake in addition to actually having an undisclosed cap, what then? They'll not only lose their high-end customers to other services (which apparently they don't want or they could have disclosed the limits to begin with), but as already mentioned they also hurt their reputation, because whatever the courts say, people are not happy when an unlimited service actually discriminates against high-usage customers.
But it also true that if you offer something unlimited you need to add reasonable limits / throttling so that pathological and cheater do not destroy experience of others.
Amazon Drive might be able to bandwidth limitation for users which are abusing the system but as I far as I understand they just route things to Amazon S3 so bandwidth limitation is probably hard for them. Also they probably do not want to add bandwidth limitation for people who use Amazon Cloud Drive for photos and movies. Not 100% sure but I understand they position.
And I read on redit how people started moving data to Google Drive thinking everything will be super fast - but Google already have bandwidth limitation in place.
It sounded to good to be true, fortunately we were still on the trial.
"paying a flat rate for unlimited storage, or transfer, pits you against your provider in an antagonistic relationship. This is not the kind of relationship you want to have with someone providing critical functions."[1]
[1] http://blog.kozubik.com/john_kozubik/2009/11/flat-rate-stora...