Support downloading known public files using a non-restricted scope. [168687448]

Fixed

Feature Request

Status Update

No update yet.

Description

ge...@gmail.com

created issue #1

Sep 16, 2020 06:15PM

A short description of the request:

Allow requests authenticated with a non-restricted scope to download publicly shared Drive files with file IDs that are already publicly available and known by my application.

What is the purpose of this new feature?

This functionality is currently possible, but is either subjected to a severe rate limit when the requests are not authenticated, or is hidden behind a restricted scope that requires an expensive security assessment, which isn't necessary for this use case.

What existing APIs would this affect?

Google Drive API v3, specifically when doing this in the googleapis Node.js library:

drive.files.get({
  fileId: 'ID of publicly shared file',
  alt: 'media'
}, {
  responseType: 'stream'
})

What existing data does this use?

Google Drive files that are shared publicly, and the link/fileID has been already shared by a user and is already known to my application (and is stored in a database, for example).

Please provide any additional information below.

There are three potential ways to download these publicly shared files:

1.) Downloading the file using the url https://drive.google.com/uc?id=<fileID>&export=download without any authentication. This is allowed by the API, but is subjected to a severe rate limit restriction.

2.) Downloading the file with OAuth2.0 authentication using the scope https://www.googleapis.com/auth/drive.file. This currently is not allowed by the API, and I am requesting that this become possible. (either by modifying this scope or adding a new non-restricted scope that allows this)

3.) Downloading the file with OAuth2.0 authentication using the scope https://www.googleapis.com/auth/drive.readonly. This is allowed by the API (without any other code modifications from the "drive.file" case). I can't use this option because of the required security assessment for applications that use this scope.

I don't see the justification for why case (2) is not allowed. If (2) is not allowed because of a security/authentication concern, then (1) should not be allowed. If (2) is not allowed because of a rate limit concern, then (3) should not be allowed.

I have read that the "drive.file" scope provides access to "files created or opened by the app". This seems to require the Picker API, which doesn't seem to support selecting publicly shared drive files or filtering the selection by an already-known file ID. It also requires user input, which is not necessary in this use case. "Opening files in the app" without user input seems equivalent to making (2) possible.

Comments

mi...@google.com <mi...@google.com> #2Sep 17, 2020 08:50AM

Assigned to mi...@google.com.

Hello there!

Another option would be to use an API key. Have you tried that? Would it be useful for your situation?

In any case, could you please provide more information on your current situation?

What workaround (if any) are you currently using to avoid this limitation?
How is this impacting you in terms of costs, productivity, etc.? How much could be improved if this functionality got implemented?

Kind regards.

ge...@gmail.com <ge...@gmail.com> #3Sep 17, 2020 02:09PM

I looked into using an API key, but that is not ideal for my use case. The source code for this application is public, and it uses Electron (so I cannot use referrer restrictions on the API key). I have read here that the only way to secure an API key in situations like this is to use my web server as a proxy, but I don't have the bandwidth on my web server to download every user's file request and then send it to them.

I have not released the application yet, and I haven't decided on a workaround. I am considering two options:

Give the application dynamic access to an API key at runtime through my webserver. This is not entirely secure, but it is better than putting it in source code.
Use the drive.readonly scope anyway, without the security assessment. This has a 100 user limit, so this solution won't work for long. I could theoretically create additional cloud projects to avoid the 100 user limit, but that seems like it would violate terms of service, and wouldn't scale effectively (even though I don't expect more than 10k users).

Neither of these workarounds are good enough to make me comfortable releasing my application. Making this change seems like it would be relatively straightforward, and it would allow me to release my application right now without further modifications.

Message last modified on Sep 17, 2020 02:13PM

mi...@google.com <mi...@google.com> #4Sep 18, 2020 02:34PM

I have reported this request internally. Any updates about this will be communicated here.

Thank you.

is...@google.com <is...@google.com> May 26, 2023 08:13AM

Status: New

jp...@google.com <jp...@google.com> Jul 13, 2023 02:35AM

Assigned to wo...@google.com.

jp...@google.com <jp...@google.com> #5Mar 12, 2024 04:23PM

Marked as fixed.

As of 2024, no scope is necessary to download public files.

al...@learningtapestry.com <al...@learningtapestry.com> #6Apr 3, 2024 06:02AM

It appears that the issue persists.

Current Situation:

A Google Document is shared with the setting "Anyone on the internet with the link can view".
A Google Cloud Project is set up with a drive.file scope.

Outcome:

When attempting a drive.files.get request for the Google Document, a 404 error is returned.

We really would like to be able to execute drive.files.get, drive.files.list and drive.files.copy requests on publicly shared objects.

ok...@gmail.com <ok...@gmail.com> #7Mar 28, 2025 03:31PM

Tested this with drive.files.get, drive.files.list and drive.files.copy requests and with nonsensitive scope ./auth/drive.file on publicly shared objects and it's not working:

drive.files.get, drive.files.copy - returns 404
drive.files.list - returns empty array

Message last modified on Mar 28, 2025 03:33PM