Why Our Google Drive Redaction App Uses the drive.file Scope (and Never Uploads Your PDF)

When we decided to let people redact PDFs from Google Drive™, the first design question wasn't about redaction at all. It was: how little access can we get away with?

A redaction tool is, by definition, handed the most sensitive documents someone owns. Asking for full Drive access would have been the lazy answer and a bad one. This post walks through the choices behind the app, Redact PDF by PDF Redaction, now live on the Google Workspace Marketplace.

Choice 1: drive.file, not drive

Google offers a spectrum of Drive scopes. The broad ones (drive, drive.readonly) expose every file; they also trigger restricted-scope verification and, rightly, make security teams nervous.

drive.file is per-file: the app only gets access to files the user explicitly opens with it or selects in the Google Picker. For an "Open with" integration that is exactly the contract we want, and it makes the permission screen easy to explain to an admin.

The trade-off is real. With drive.file the app cannot create arbitrary new files or browse folders, so "Open with" and the Picker are the only entry points. We accepted that.

Choice 2: keep the token in the browser

The "Open with" menu hands our site a file ID through Drive's state parameter. We parse it, ask the user to authorize with Google, and use the resulting access token to fetch that single file.

That token never needs to touch our backend, so it doesn't. It lives in memory on the hand-off page for the duration of the session. Nothing to leak from a database, nothing to rotate.

Choice 3: fetch straight into the browser

Rather than proxying the PDF through a server, the browser downloads it from Drive's API directly and the redaction editor takes it from there: rendering, OCR for scanned pages, and applying redactions all happen client-side.

The only network call that carries document-derived data is PII detection, and it carries extracted page text rather than the file. For stricter environments there is a local detection mode that sends nothing at all.

What we deliberately did not build

• Write-back to Drive. The redacted file downloads locally. Writing back would need a broader scope, and "overwrite my original with a redacted version" is a footgun anyway.
• Folder-level automation. Batch redaction of whole folders is tempting, but it needs wider access than drive.file allows. If you need that, an API or workflow route fits better than a Drive scope stretched past its purpose.

If you're building something similar

1. Start from the narrowest scope that supports your entry points, then see what breaks.
2. Pass the minimum through your backend; every byte you proxy is a byte you're responsible for.
3. Write the "what we can't do" list down. It's the most honest part of your privacy documentation.

Try it or read the details

• Install from the Google Workspace Marketplace
• Google Drive integration docs: setup, limits and troubleshooting

If you've shipped a Drive integration and chose differently, I'd like to hear why.

Google Drive™ is a trademark of Google LLC. Redact PDF by PDF Redaction is not affiliated with or endorsed by Google LLC.