In a comment of mine earlier this week [1], I (along with others) speculated whether the shipping of OAuth2 secrets was the reason for the ban, and whether they

In a comment of mine earlier this week [1], I (along with others) speculated whether the shipping of OAuth2 secrets was the reason for the ban, and whether they're other contributing, strategic factors. I wrote: 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. [1] https://news.ycombinator.com/item?id=14380106 https://news.ycombinator.com/item?id=14380106