One thing that might work would be open sourcing the code of the auth server (without client_id and secret of course) and then running it on something like Google App Engine in a way that us users can verify that the open source code is actually running there without modifications.
Never looked into it much but App Engine does have various viewer only access control settings, including one that lets people view source code:
https://cloud.google.com/appengine/docs/standard/python/access-control
Putting the client_secret in the source wasnāt the best idea. But even some commercial tools are including the client_secret in there binary (expandrive, arq etc.) I extracted these tokens without much of a problem. The best way the client_secret is handelt is by Duplicati via there oauth handler (http://duplicati-oauth-handler.appspot.com/) This way the secret ist kept save and no one can fake there app login. I even have an old security profile with amazon that still worksā¦
Amazon could in fact disable access for expandrive and arq by using the same argument anytime.
And then the developer has full access to your drive and can intercept your authentication tokens. This is not the 'best' way. It may be the only way but it definitely isn't protecting the customer's data.
But having the client_secret in the open can be very dangerous in some slight social engineering in where an attacker might mask as Arq and can access your account in there name.
If your are running a compiled binary of any kind of source you did not compile yourself you have this issue. You always put the trust in the developers. So trusting them to handle your oAuth tokens isnāt much of a stretch.
Have you confirmed that the binary you downloaded from github is in fact the unmodified source code hosted in the repo? (You can: https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/ it is)
So in general I donāt see the security problem in trusting the developers of an open source project. ( I am aware of the fact that this is exactly the problem acd_cli faced and which lead to this problem. But in fact the auth.py script that was run by acd_cli was open source to and NO one did suspect anything)
They need more than the API secret. They also need a token. If its all done on a server you don't own its dangerous.
Yes but I can choose to compile my own.[quote="luggi, post:229, topic:2314"]
So trusting them to handle your oAuth tokens isn't much of a stretch
[/quote]
I believe it is. If I were the developer, I wouldn't want to control a device that can access thousands of users data if it were compromised.
I've compiled my own.
I trust a developer to make sound security decisions and not create a security problem. I shouldn't have to trust a developer with securing my authentication credentials.
All in all, we can agree to disagree here.
@hennes11 - This is a simple piece of code used by clouddrive to handle the authentication server - https://github.com/alex-phillips/clouddrive-endpoint/blob/master/clouddrive.php
I find it DEEPLY ironic that the whole thing started with acd-cli having a bug in the auth server and rclone got the shaft too supposedly because it had the āsecrets in the openā even if it could never have acd-cliās problem - not having a server at all.
It looks like acd_cli is back: https://github.com/yadayada/acd_cli
Iāve not heard back from Amazon this week about getting rclone back on.
Iāll post here if I hear anything!
I really hope they come back to you with positive newsā¦ acd_cli isnāt cutting it, says itāll take 60 days to transfer my 4TB via my Scaleway serverā¦ or Iām doing something wrong.
The windows drive for odrive isnāt too bad for uploading. I made the mistake though of allowing symlinks in my samba share, so it started off by attempting to upload duplicatesā¦ Now that I corrected that it seems to be going at a reasonable rate.
To upload a network share with it in windows, you need to use the mklink command. I havenāt tried the linux version of the client yet.
In the middle of all this madness I wanted to extend my sincere thanks for working so hard on a great open-source tool and trying to get it working again with ACD. Even if they never let you back in Iāll still be using it with other cloud providers and sftp. Simple because itās the best and most reliable option out there.
So thanks again, hope itās a fulfilling experience working on it.
On my Hetzner server I mounted ACD with acd_cli, and Iām using rclone to sync up to Google Drive. Iām getting about 65MBps average.
@PJBurnhill you are doing something wrong. I am not sure about acd_cli drive mount because I havenāt used this methos. I have used some temporary tokens from other apps (expandrive / drivesynk) and I have used Scaleway as a VPS. I did transfer 2Tb to GDrive in 13 hours. I used the server with 500Mbit/s bandwith. I was using the full bandwidth the entire time. Maybe it is not the most ethic way of dealing with the problem. But hey, Amazon was also not ethic towards us, not even warning in advance, nor giving a temporary solution on how to move the data out.
I reused an old whitedlisted profile and ran into the same problem myself. It turns out the whitelisted profile has a different set of permission scopes from what rclone is requesting. rclone wants to have "write" and "read_all" scopes. I don't have "read_all" in my profile, but can list all and download some other file types.
I changed rclone's request scopes so that I still have all upload permissions (and some download ones). It's not ideal but useful to me for archiving my files.
Hey, could you share how you transferred from ACD to GD? I assume you mounted GD? google-drive-ocamlfuse or something else? What were your acd_cli settings and what actual command did you run?
Edit: Sorry, just re-read you post. Do you mean you didnāt use acd_cli at all, just rclone with token from elsewhere?
Thanks!
Amazing you have not heard back.
Anyway, I cancelled my Amazon Drive and asked for a refund, which was done almost immediately.
Bye.
Not really. They couldnt care less about their customers.
I was using sarcasm, I also cancelled my account and donāt plan on going back.