Skip to content

Google Drive: one-time setup

Sift can read recordings straight from Google Drive folders. Each member signs in with their own Google account, and their computer talks to Google directly. Before that works, someone sets up a Google Cloud project once, and the app is built with its sign-in client.

This page is for that person. How members use Drive datasets is in Google Drive datasets. The full notes, including the developer details, are docs/GOOGLE_DRIVE.md in the Sift repository.

Google changes its console’s wording and layout often. Names below may differ from what you see. Some limits on this page come from Google’s documentation and could not be checked against the live console. Check them on screen.

Piece What it is for
A Google Cloud project Holds the API and the sign-in client.
The Google Drive API Lets the app list folders and read files.
The OAuth consent screen What members see when they sign in: the app’s name, and that it wants to see and download their Drive files.
An OAuth client of type Desktop app Its client ID and secret are built into the app.

The hub needs nothing. It never talks to Google. Members’ Google sign-ins stay in their computer’s keychain.

  1. Sign in to the Google Cloud console with the account that should own the setup. A shared admin account keeps the setup alive when people leave.
  2. In the project picker, choose New project. Name it, for example, “Fathom desktop app”.

You don’t need a billing account. Google lists billing as optional when you create a project, and standard use of the Drive API costs nothing. Google plans to charge for use beyond its daily Drive API limits. The limit that matters for Sift is 1 TB downloaded per project per day, because Sift downloads whole audio files. Google will give at least 90 days’ notice before any charges start. Those charges would go to a billing account linked to the project.

Go to APIs & Services, then Library. Find Google Drive API and choose Enable.

Newer consoles put this under Google Auth Platform, with the pages Branding, Audience, Data access and Clients. Older ones call it OAuth consent screen.

  1. Audience: choose External. Members use personal Google accounts, so Internal doesn’t apply.
  2. Branding: the app’s name (Sift), a support email members can write to, and a developer contact email.
  3. Data access: add exactly one scope, https://www.googleapis.com/auth/drive.readonly (“See and download all your Google Drive files”). The app asks for nothing else.

The consent screen has two states. For a small team, choose In production and leave the app unverified.

Testing In production, unverified
Who can sign in Only the test users you list, up to 100. Anyone, up to 100 new users in total.
What members see A notice that the app is being tested. A warning that Google hasn’t verified the app. They continue through Advanced.
How long a sign-in lasts 7 days. Everyone signs in again every week. Until it is revoked, or unused for six months.
Adding a member Add their address as a test user first. Nothing to do.

The weekly sign-in in Testing would interrupt labelling. In production, the warning is a one-time click for each member.

The cap counts new users who sign in after the app starts showing the warning, in total. Google may adjust it for some apps. Verifying the app removes it. The warning’s exact wording changes over time, so check it yourself by signing in once.

Full verification by Google is only worth it if the app is offered beyond your team. It needs Google’s review and a yearly security assessment.

Go to Clients (or APIs & Services, then Credentials) and choose Create client. Set Application type to Desktop app, name it, and create it. Copy the Client ID and Client secret.

A desktop client signs in through the system browser and a local address on the member’s computer. There are no redirect addresses to configure.

The app’s build needs both values:

  • Client ID: goes in brand.json as googleClientId. It is public.
  • Client secret: is read from the environment variable GOOGLE_OAUTH_CLIENT_SECRET when the app is built. For releases, add it as a repository secret and pass it to the release build. It is kept out of brand.json so it never sits in the web interface’s files or in a commit.

Google treats a desktop app’s secret as not confidential. Anyone can extract it from the installed app, and that is expected for this kind of client.

A build without a client ID has Google Drive turned off. Members then see Not set up in this build where the Google Drive option would be. A build with the ID but without the secret can’t start a sign-in.

Each member’s own Google account must be able to read the folder:

  • Share the folder with each member’s Google address as Viewer.
  • Leave Viewers can download on. Without it, the app may list the folder but not read the audio.

Folders on a shared drive work the same way once they are shared.

When a member’s app says an address “can’t open” a folder, share the folder with that address. The app has a button to copy the address. Or the member signs in with another account that already has access.

  1. Open or add a Drive-backed dataset in the desktop app.
  2. Choose Sign in to Google. The system browser opens. They choose their account, continue past Google’s warning the first time, and allow access to their Drive files.
  3. Choose where downloads go and how much space they may use. The app asks once per computer.

To remove the app’s access later, a member removes it from their Google account’s permissions page, or removes the account in the app’s Google accounts… settings, which also revokes it.

In the console, APIs & Services, Google Drive API, Quotas shows the per-minute limits and current use. The app slows down and retries when Google asks it to.

If someone sees “Drive limits how often this file can be downloaded; try later”, Google has limited downloads of that one file. The app doesn’t retry this on its own. The limit lifts by itself, but Google doesn’t say how long it lasts. Try again later.