Verification Evidence

For Google OAuth restricted-scope review · Last updated:

Summary

DriveStat is a static single-page web application. It has no backend server operated by the developer. The OAuth access token and any Drive metadata retrieved from Google APIs exist only in the end user's browser and are never transmitted to any server controlled by the developer. The entire source tree is public on GitHub and the deployed site can be byte-for-byte reproduced from the repository.

Architecture

Data flow at runtime (no developer-operated server is involved at any step):

User's browser
  ├── Loads static HTML/CSS/JS ..........  GitHub Pages CDN (em95.org → github.io)
  ├── Sign-in popup .....................  accounts.google.com
  ├── Drive metadata requests ...........  www.googleapis.com (direct, over TLS)
  ├── Scanned tree cache ................  IndexedDB (in-browser)
  └── Access token + preferences ........  localStorage (in-browser)

There is no server-side component under developer control. GitHub Pages is a static file host; it serves the same HTML/CSS/JS bytes to every visitor and has no ability to receive or process Google user data.

Source code & hosting

• Public repository: github.com/EMRD95/gdrive-windirstat
• Deploy workflow (commit-to-live): .github/workflows/deploy.yml
• Hosting platform: GitHub Pages (static file CDN; no server-side execution)
• Custom domain: drivestat.em95.org, served via GitHub Pages with a Let's Encrypt certificate
• Build output: only .html, .css, .js, and image assets (no binaries, no server processes)

The deploy workflow injects the public OAuth Client ID at build time from a GitHub secret. This is the only non-public value in the pipeline, and Client IDs are not secrets per Google's OAuth 2.0 documentation — they are visible in-browser at runtime.

Scope justification

DriveStat requests the single scope https://www.googleapis.com/auth/drive.metadata.readonly.

• Why this scope? The product is a treemap visualization of a user's entire Drive storage, in the spirit of WinDirStat for Windows and DaisyDisk for macOS. Producing an accurate whole-Drive view requires enumerating every file's size and parent folder.
• Why not drive.file? drive.file only returns files the user individually selects via Google Picker. That surface is incompatible with "show me where all my storage is going" — the user would have to hand-pick the very files they're trying to discover.
• What fields are read? name, mimeType, parents, size, quotaBytesUsed, modifiedTime, ownedByMe, driveId, trashed. File contents, thumbnails, and previews are never requested.
• Can the app modify user files? No. drive.metadata.readonly does not grant write access, and the codebase contains no mutation calls.

Where user data lives

All data derived from the Drive API lives in the end user's browser and nowhere else:

• OAuth access token — localStorage key ds_access_token. Short-lived token issued by Google Identity Services for the current session; cleared on sign-out.
• Scanned file metadata — IndexedDB database DriveStatDB, object store files. Caches the scan so repeat visits don't re-enumerate. Cleared by signing out or by clearing browser site data.
• UI preferences — localStorage keys ds_theme, ds_list_pane_height_pct, ds_treemap_visible, ds_cookie_ack.

No part of this data is transmitted to any developer-controlled server. There is no such server.

Limited Use compliance

DriveStat's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• We use Drive metadata only to render user-facing features that are prominent in the app's UI (treemap, file list, details sidebar).
• We do not transfer Drive data to others.
• We do not use Drive data for serving ads.
• We do not allow humans to read Drive data. Nobody at DriveStat has access to Drive data — there is no server and no database.

How to verify this yourself

A reviewer can verify the above claims directly in a few minutes:

1. Open the deployed site https://drivestat.em95.org/ with DevTools → Network tab open and "Preserve log" enabled.
2. Sign in with a test Google account and let a scan run.
3. Observe that the only request destinations are accounts.google.com, apis.google.com, www.googleapis.com, and the static-asset CDN (em95.org / github.io). No request to any developer-controlled server will appear, because no such server exists.
4. Inspect the source repository at github.com/EMRD95/gdrive-windirstat. The deploy workflow (.github/workflows/deploy.yml) ships only the static files in the repo; there is no server build step.
5. Open DevTools → Application → Storage. The token and cached scan are visible in localStorage and IndexedDB respectively, both scoped to the drivestat.em95.org origin. Signing out clears both.

CASA applicability

Per Google's restricted-scope verification documentation, a CASA security assessment is required for "apps with ability to access restricted data from or through a third-party server" — i.e. apps that store or transmit restricted-scope data on servers.

DriveStat is not such an app. It has no backend. No server operated by or accessible to the developer ever receives, processes, or stores Google user data. On that basis we believe DriveStat qualifies for the client-side exception and should not require a CASA assessment.

Contact

Verification questions: em95org@gmail.com.