Correct docs about permissions for Dropbox backend (and why not Google Drive?)

[DustinWehr]

Currently reads:

the lack of a permission model. So apps can usually access all of a user's storage with these backends (vs. only relevant parts of the storage with RS accounts)

This is not accurate for Dropbox. Users of my app see an API Request Authorization page from dropbox.com that says:

chatgptweb-sync would like to:
Edit content of your Dropbox files and folders, view content of your Dropbox files and folders, and view and edit information about your Dropbox files and folders, only within the Apps › chatgptweb-sync folder
View basic information about your Dropbox account such as your username, email, and country

That RS docs excerpt does seem to be accurate currently for the Google Drive backend, surprisingly. But is that necessary? Could've sworn I've granted some app's Google Drive integration access to just its "app data folder" before, i.e. this https://developers.google.com/drive/api/guides/appdata. More specifically, why can't we just replace this line:

remotestorage.js/src/googledrive.ts

Line 17 in 1e0cccc

const AUTH_SCOPE = 'https://www.googleapis.com/auth/drive';

with https://www.googleapis.com/auth/drive.appdata ? It's described as "View and manage the app's own configuration data in your Google Drive." There is also a drive.appfolder scope code (see here); not sure if that's just an alias or what.

[DougReeder]

It's not the lack of a permissions model that's the problem, it's that Dropbox (and Google Drive) have permission models that conflict with the RS permissions model.

An RS scope can be accessed by more than one app (for example, the documents scope is accessed by both Litewrite and Notes Together). So, unfortunately, Dropbox App folder scope does not match the RS permissions model. So, while an app using remotestorage.js will only access files in the remotestorage subtree, there wasn't a way to request just that from the Dropbox API, when I last checked. Likewise for Google Drive, last I checked.

[raucao]

Yes, that's correct. You can either grant the app permission to write its own files, or you can have interoperable apps that access the same data.

See this current Webmarks issue for some more discussion and info regarding Google Drive. There's a scope where you can write to /remotestorage/category, but the app can only see documents that it created there itself.

It may make sense to switch rs.js to app folders entirely by default, and tell users that single-app access is the drawback compared to RS, especially for new apps where data migration to a different folder is not necessary.

[DustinWehr]

It may make sense to switch rs.js to app folders entirely by default, and tell users that single-app access is the drawback compared to RS, especially for new apps where data migration to a different folder is not necessary.

Yeah! I just want Drive and Dropbox support so (a) users can try my feature without having to make a new account (with a company they haven't heard of), and (b) as a backup sync method. Both of those backends were slower than RS via 5apps --and I was intending on telling users that-- but they worked well enough for a try or for a backup method.

@DougReeder got you. Sharing data doesn't make sense for my application (which is adding a device sync feature to a web app that was designed only for local storage), for a few reasons, most importantly because nobody else would use it. There is probably some well-organized effort to make an interoperable data format for LLMs that I don't know about. Making an RS data module would make sense for them.

Back to my main suggestion. I probably told Dropbox that I want a "Scoped App (App Folder)" when I set it up. Looks like this in the main dropbox app settings page: Screenshot from 2024-04-06 15-52-01
but that would be the only possible difference between what I did and what the RS docs advise (permission scopes are the same: account_info.read, files.metadata.read, files.metadata.write, files.content.read, files.content.write). So it is very easy to set up Dropbox so that it gives a non-alarming consent screen like this:

I can't say the same for Google Drive. I tried patching remotestorage.js and fiddling with the google dev console settings for a couple hours, but couldn't get the consent screen to change.

[raucao]

With Google Drive, you'd have to change the scope to drive.file, both for your OAuth dialog in the Google Developer Console, as well as in rs.js.