Sortify Google Drive Targeted Authorization

Published by: MokingBird Oy Last updated: 6 June 2026

Overview

Sortify is local-first and privacy-first. Workspace contents live on the user's device by default. When sync is enabled, Sortify encrypts workspace data before uploading it to the user's selected cloud provider.

For Google Drive, Sortify uses a narrower, least-privilege collaboration model. Instead of requesting broad access to a user's entire Google Drive, Sortify uses Google's drive.file scope and authorizes only the known encrypted Sortify workspace files needed for sync.

This article explains the high-level approach behind Google Drive targeted authorization and the Finalize Join flow.

The Problem Sortify Solves

A Sortify workspace can be shared between a primary user and secondary users. The primary user owns or creates the encrypted workspace sync files in their cloud account. A secondary user must later read and update those same encrypted workspace files so everyone sees the same item locations, rooms, and history.

With Google Drive, this creates a permission challenge:

• the workspace file may be created by the primary user's Google account;
• the secondary user signs in with their own Google account;
• Google Drive may require that the secondary user explicitly authorizes access to the shared file under the drive.file access model;
• Sortify should not ask for broad access to the secondary user's entire Drive just to sync one encrypted workspace.

The targeted authorization flow is designed to solve this without weakening Sortify's privacy model.

The Implemented Model

Sortify's Google Drive collaboration flow is based on three ideas:

1. Known file references. Sortify stores the exact Google Drive file reference for the encrypted Sortify workspace package, normally workspace.sortifypkg.
2. Targeted authorization. If Google requires user consent for that file, Sortify asks the user to authorize the known Sortify workspace package.
3. Encrypted payloads. The Google Drive file contains encrypted Sortify sync data. Google Drive access alone does not reveal plaintext workspace content.

The user experience is designed around a simple concept:

Join workspace -> Owner approves -> Finalize Join -> Workspace syncs

For Google Drive workspaces, Finalize Join may open Google's authorization interface so the user can approve the encrypted Sortify workspace package shared with them.

What the User Sees

A secondary user may see the following flow:

1. The primary user shares an invite link or invite code.
2. The secondary user requests to join.
3. The primary user approves the request.
4. The secondary user sees a Finalize Join prompt.
5. If Google Drive requires authorization, the user selects or approves the Sortify workspace package shown by Google.
6. Sortify returns to the app and performs the first encrypted sync.

The purpose of this flow is not to make the user browse Google Drive manually. The purpose is to let Google record that this user has authorized Sortify to access the specific encrypted workspace file needed for collaboration.

What Sortify Stores

Sortify may store operational references needed to make this work, such as:

• workspace ID;
• workspace name;
• Google Drive provider type;
• Google Drive workspace package file ID;
• sync version or revision metadata;
• whether the provider authorization step was completed;
• workspace membership and approval status.

Sortify does not store plaintext workspace contents on MokingBird servers.

Where recovery protection is enabled, Sortify may store encrypted key envelopes in Firebase/Firestore. These envelopes are not plaintext workspace keys and cannot be used by MokingBird to read workspace contents.

What Is Inside the Google Drive Workspace Package

The Google Drive package approach reduces authorization complexity. Instead of asking users to authorize multiple core files, Sortify represents collaborative core workspace sync as a single encrypted workspace package.

A core workspace package is a single file:

workspace.sortifypkg

It includes:

• encrypted workspace database snapshot;
• sync metadata;
• package manifest;
• version and integrity information.

The package is still encrypted before upload. The cloud provider stores encrypted Sortify sync data, not plaintext item contents.

Photos are intentionally separated from the first core workspace authorization because photo data can be larger and not every workspace needs photo sync. Google Drive photo sync uses a separate encrypted package:

photo_workspace.sortifypkg

That package is optional. A user is asked to authorize the photo package only after choosing to enable photo sync for that Google Drive workspace. This keeps first join focused on one core workspace file.

Photo preparation prefers an existing thumbnail where available, normalizes the image to JPEG, constrains it to a maximum 1280 x 1280 bounding box without upscaling, and compresses it at quality 55. Each compressed blob is encrypted on-device with the workspace key using AES-256-GCM before packaging. The package manifest and checksums allow corruption and workspace mismatches to be rejected without exposing plaintext item or room details.

Users can enable photo sync from a pending sync notification or from Workspace Settings. The app persists incomplete Finalize Join and photo-authorization work as pending sync tasks so the user can return later instead of being forced to remain on the approval screen.

Firestore acts as a lightweight coordination index. Core and photo package generations, revisions, hashes, counts, and authorization state tell devices whether a Drive download is required. The encrypted Drive packages contain the authoritative workspace and photo payloads. Firestore is not a plaintext inventory database.

During recovery, the core workspace package is restored first. If photo sync was enabled and the user authorizes the known photo package, Sortify downloads, validates, decrypts, and restores the compressed photo assets separately. Missing or declined photo authorization does not block core workspace recovery.

Why This Is More Private Than Broad Drive Access

The targeted Google Drive approach supports Sortify's privacy goals because:

• Sortify does not need to scan the user's entire Google Drive;
• Sortify works with known Sortify workspace files;
• Google Drive authorization can be limited to the specific file needed for the workspace;
• the file itself is encrypted before upload;
• workspace content remains controlled by the user's device, workspace key, and selected cloud provider.

This is consistent with Sortify's broader architecture: user-controlled cloud storage, local-first data, encrypted sync, and role-based collaboration.

What Happens If Authorization Fails

Google Drive, OneDrive, and Dropbox are third-party providers. Provider access can fail for reasons outside Sortify's direct control, such as:

• the wrong provider account is connected;
• the owner has not shared the file or folder correctly;
• the user revoked provider access;
• the provider API is temporarily unavailable;
• a shared folder or file permission was removed;
• the provider requires another consent or authorization step.

When this happens, Sortify may show a reconnect, retry, approval, or Finalize Join state. These states are designed to prevent a user from entering an empty or incorrect workspace before the encrypted owner snapshot can be pulled.

Security Summary

Sortify's Google Drive targeted authorization model is designed to provide collaboration without broad Drive access where practical.

Key points:

• Sortify uses OAuth through Google's standard flow.
• OAuth tokens are stored in platform secure storage.
• Sortify stores Google Drive file references needed for workspace sync.
• Core Google Drive collaboration uses one encrypted workspace.sortifypkg file.
• Optional photo sync uses a separate encrypted photo_workspace.sortifypkg package.
• Photo authorization can be started from a notification or Workspace Settings and remains available as a pending sync task.
• Core recovery completes independently; photo recovery is optional and separate.
• Sortify does not intentionally inspect unrelated Drive files.
• Workspace content is encrypted before upload.
• Google Drive authorization is separate from Sortify account sign-in.
• Finalize Join is a provider-access step, not a second Sortify account registration step.

User Responsibility

Users remain responsible for:

• connecting the correct Google account;
• accepting provider prompts when required;
• managing workspace invitations carefully;
• removing users who should no longer have access;
• protecting their cloud account with strong authentication and multi-factor authentication where available.

Workspace owners are responsible for managing provider-level sharing where the provider requires owner action or where Sortify cannot complete the provider operation automatically.

Conclusion

The Google Drive targeted authorization model lets Sortify keep the privacy benefits of user-controlled cloud storage while reducing the need for broad Google Drive access. It is designed so users can collaborate through encrypted workspace packages, approve access to the specific Sortify file they need, and avoid exposing unrelated Drive content to the app.

This approach supports Sortify's core principle: your workspace data belongs to you, is encrypted before sync, and stays under your control.