Hey, folks (I guess, specifically, @ncw in this case). It's not so much about help or support in this case, it's a question from a sister project's team - DVC, to learn more about your experience with Google Drive integration and app.
Similar to rclone we have our DVC Google app that is verified and is using drive scope by default to write / read files that DVC is managing or needs access to.
Recently we've received a request from the Google Drive team that we either need to pass the verification again or migrate to a safer scope (drive.file). Overall the idea to migrate and let users decide which folders to give access to seems very reasonable, the only problem is that I'm not sure a CLI app can be modified to provide a file picker or something similar.
We have drive.file as an option in rclone and it effectively means that rclone can only see and use files it created itself.
I don't know how you share files with the app though - perhaps you have to build a bit of web UI to do this? You could potentially run a webserver locally and just put up a simple page to do this. This isn't something we support in rclone - our docs point to the drive scope if you want rclone to see existing files.
This isn't something we support in rclone - our docs point to the drive scope if you want rclone to see existing files.
We also don't have UIs, etc. It's a CLI app simiar to rclone, and we also were using drive since in some cases we need to access the existing files. But from what I understand even accessing the existing files is not enough justification for using drive (at least that's what GDrive team is saying).
drive.file AFAIU is enough to access the existing files (that were not created by the app):
Create new Drive files, or modify existing files, that you open with an app or that the user shares with an app while using the Google Picker API or the app's file picker.
So, they seems to be right that (assuming there is a way for a users to pick the list of files / directories to share with an app) drive.file is enough for all the scenarios? I'm curios if they were asking you to pass the verification second time because of these sensitive scopes (drive). If you have some details to share please feel free also to ping me directly. Thanks.
I don't really understand how this works. How can a user choose to share stuff with an app? You don't seem to be able to do it in the drive web interface
We did the full verification. It was some time ago though so things may have changed.
We also encourage users to make their own app IDs as the rclone one never has enough quota.
Yep, exactly the same for us! We also encourage them to use their own app, etc.
It's just they reached out to us to do another review and explain why we need drive or migrate to using only drive.file. And so far they are not convinced that drive.file is not enough (despite some technical issues - see below).
I don't really understand how this works. How can a user choose to share stuff with an app? You don't seem to be able to do it in the drive web interface
That's a good question. I think they did some infrastructure / plugins / JS components that web apps could you to show a file picker. I'm not sure but I doubt it is reasonable for a CLI or even possible to use it.
I mentioned to them this issue - still not enough.
Btw, I wonder when your users use drive.file - how they give access to specific files then?
They don't. Typically users will be using rclone to back up their data from elsewhere so it is an advantage that rclone has no access to existing stuff.
Do they need in some case to pick the directory to put their back up to? Or it's not the case? Or do you create it for them then. (and the root access to create a directory is probably given by default?)