Why a Google Drive PDF Redaction App Uses Only drive.file Scope and Never Uploads Files

The Minimum-Permission Dilemma of a Redaction Tool

When a developer decides to let users redact PDFs directly from Google Drive, the first design question has nothing to do with redaction itself. The real question is: how small a permission scope can we get away with?

A redaction tool inherently touches users' most sensitive files—contracts, medical records, legal documents. Taking the lazy route and requesting full Drive access would of course be the easiest option, but it would also be the worst. Redact PDF by PDF Redaction, listed on the Google Workspace Marketplace, breaks down its permission trade-offs in an official blog post, and the approach offers a useful reference for any sensitive-data product that integrates with cloud storage.

Permission Choice: drive.file, Not drive

Google offers a whole spectrum of Drive permissions. The broad drive and drive.readonly scopes expose every file a user has, and they trigger the restricted-scope verification process—security teams will almost certainly reject such a request outright.

drive.file grants per-file authorization: the app can only access files the user explicitly opens or actively selects through the Google Picker. For an "Open with" integration, this is exactly the contract you want—what the permission consent dialog says is something an admin can understand at a glance.

The cost is real. With drive.file, the app cannot arbitrarily create new files, nor can it browse folders, so "Open with" and the Picker become the only two entry points. The author explicitly accepts this limitation. This points to a fundamental principle for sensitive-data products: the product shape should adapt to the permission model, not the other way around.

Google Drive API's OAuth scopes are essentially a "contract declaration" that determines which resources an app can see and manipulate in a user's account. drive and drive.readonly are Sensitive Scopes—requesting them not only triggers alarming consent text like "View, edit, create, and delete all of your Google Drive files," but also kicks off Google's OAuth app verification process, which requires submitting a privacy policy, a demo video, and possibly undergoing a third-party security assessment, a process that can take weeks. For a product targeting the enterprise Workspace Marketplace, this is nearly a barrier to entry. drive.file, by contrast, is a non-sensitive scope, exempt from that verification, and its consent dialog only shows "View, edit, create, and delete specific Google Drive files you use with this app." Another key point is that drive.file's authorization scope accumulates dynamically: each time a user selects a new file through the Picker or "Open with," that file enters the app's accessible set, while previously unselected files remain invisible. This "allowlist-style" incremental expansion is exactly why it's called "per-file authorization."

Tokens Stay Only in Browser Memory

The "Open with" menu passes the file ID to the app's site through Drive's state parameter. The app parses that ID, asks the user to complete Google authorization, then uses the resulting access token to fetch that single file.

The key point is that this token never needs to pass through the backend—and so it doesn't. The token exists only in memory during the handoff page's session—there's nothing in the database to leak, and no credentials to rotate periodically. For anyone doing a security audit, this architecture is extremely cheap to explain, because the attack surface is essentially nonexistent.

The access token here is the short-lived credential used in the OAuth 2.0 flow to call Google APIs, typically valid for one hour. It's paired with the refresh token—a long-lived credential used to silently obtain a new token after the access token expires. Traditional server-side integrations often store the refresh token in a database, because background tasks need to keep accessing Drive while the user is offline. This architecture, however, completes everything within the browser session, so it needs no background access and therefore no refresh token at all. This yields two implicit benefits: first, the attack surface shrinks from "database + network + credential rotation mechanism" to "the lifetime of a single browser tab"; second, the questions common in security audits—"is the token storage encrypted, what's the rotation strategy, how do you clean up residual credentials from departed employees"—simply disappear under this architecture. Not that the answers are better, but that the questions don't exist. This is a classic example of "architectural guarantees over policy promises."

PDFs Go Straight to the Browser; Only Text Leaves the Network

The app doesn't relay the PDF through a server. Instead, the browser downloads the file directly from the Drive API, and rendering, OCR of scanned pages, and redaction all happen on the client.

The only network request carrying document-derived data is PII (personally identifiable information) detection, and it sends the extracted page text, not the file itself. For stricter environments, the app also offers a local detection mode that transmits no data at all.

This data-flow design deserves special mention: many similar tools treat "server-side processing" as the default for performance optimization, but for redaction scenarios, the file never leaving the browser is itself the strongest privacy promise—it doesn't rely on policy statements, but is guaranteed by architecture.

The core tech stack for client-side redaction typically has three layers: rendering PDF pages in the browser with a library like pdf.js, running OCR on scanned documents with Tesseract.js to extract a text layer, and then performing the actual redaction via pixel-level masking or text-layer removal. What to watch out for is "fake redaction"—merely covering text with a black rectangle, leaving the underlying text recoverable through copy-paste or extraction tools, which in legal-document scenarios can constitute a serious leak. True redaction must remove the corresponding text from the content stream and re-encode it. As for PII detection, it typically relies on named entity recognition (NER) models to identify names, addresses, ID numbers, bank account numbers, and so on; the server-side call merely sends the extracted plain text to the detection API. Since the text contains no original layout or imagery, the risk of leaking sensitive layout information is low, but the text itself may still contain PII, which is why a local detection mode matters especially for highly regulated industries (healthcare, legal, finance).

Two Things Deliberately Not Done

The author lists two features intentionally abandoned, and this part best illustrates the constraints imposed by the permission model:

No writing back to Drive. The redacted file is only downloaded locally. Writing back would require broader permissions, and "overwriting the original file with the redacted version" is itself a dangerous operation.

No folder-level automation. Batch redaction of whole directories is tempting, but it requires permissions beyond drive.file. If there's a real need for that, an API or workflow solution is more appropriate than stretching Drive permissions beyond their design purpose.

Writing clearly about "what we can't do," according to the author, is the most honest part of a privacy document.

"Writing back to Drive" requires drive or at least a broader scope that allows file creation, because although drive.file permits creating files, in a single-file "Open with" authorization scenario the app doesn't have a stable write guarantee on the target file, and overwriting the original is a destructive operation that can't be undone if the redaction judgment is wrong. Folder-level automation conflicts with drive.file at the permission-model level—browsing directories and enumerating subfiles requires reading files the user hasn't individually selected, exceeding the semantics of per-file authorization. When the author mentions "an API or workflow solution," they mean letting enterprises use the Google Drive API plus a service account, or an automation platform like Zapier or Make, to handle batch processing within the organization's own permission framework, while keeping the tool itself limited to a single-file, human-confirmed operation path. This "capability for trust" trade-off is a common strategic choice for sensitive-data products.

Three Lessons for Fellow Developers

1. Start from the narrowest permission that supports your entry point, then see what breaks—rather than requesting permissions first and trimming features later.
2. Keep the data that passes through your backend to a minimum. Every byte you relay is a byte you're responsible for.
3. List what you can't do, because it builds more trust than a feature list.

These three lessons aren't limited to Google Drive integrations. Any AI application handling users' sensitive files—whether document summarization, contract review, or data anonymization—faces the same permission and data-flow decisions. The Redact PDF case shows that by solidly nailing down narrower permissions and keeping data off the network, functional compromises are perfectly acceptable.

The app's integration methods and permission limitations are described in more detail in its integration documentation.

One-line Summary

A redaction tool uses the narrowest permission and a purely client-side architecture to reduce sensitive-file data exposure to nearly zero.

Paragraph Summary

This article breaks down the permission and data-flow design trade-offs of a Google Drive redaction tool. Facing the most sensitive contracts, medical records, and legal documents, the author doesn't request broad drive or drive.readonly scopes, but instead chooses the per-file drive.file scope that makes the consent dialog self-explanatory to admins. The cost is no arbitrary file creation and no folder browsing, so "Open with" and the Picker become the only two entry points. The access token lives only in browser memory and never touches the backend; PDF rendering, OCR, and redaction all happen on the client, with the only network-bound derived data being page text for PII detection, and a local detection mode is also offered. The author deliberately forgoes writing back to Drive and folder-level batch automation, and concludes with three lessons: start from the narrowest permission, let the backend handle as little data as possible, and explicitly state what can't be done.