Sortify Security Overview

Last updated: 6 June 2026 Published by: MokingBird Oy

Introduction

Security is a foundational design principle of Sortify, not an afterthought. Because Sortify is used to track real-world items in homes, labs, workshops, and businesses — spaces that are personal and sometimes sensitive — we built the app around a model that minimizes exposure of your data while enabling secure, seamless collaboration.

This document describes the security architecture, controls, and shared responsibility model that underpin Sortify. It is intended for users, workspace owners, IT administrators evaluating Sortify for team use, and app store reviewers.

1. Security Philosophy

Sortify is built on three principles:

1. Local-first. Your data stays on your device by default. There is no requirement to upload your workspace contents to MokingBird servers. The primary copy of your data is always the local device database.

2. User-controlled cloud and zero-knowledge transport. When sync is enabled, your workspace data is encrypted before it leaves your device. Personal and small-collaboration workspaces can store encrypted sync artifacts in a cloud account you own and control. Entitlement-enabled Sortify Cloud and Enterprise SyncNative workspaces use managed Firebase/Firestore transport for encrypted events and checkpoints. In both models, MokingBird cannot read plaintext workspace contents or plaintext workspace keys. Where recovery protection is enabled, MokingBird may store encrypted key envelopes in Firebase/Firestore, but not plaintext workspace contents or plaintext workspace keys.

3. Least practical privilege. Each component only has access to what it needs for the implemented workflow. Workspace members have role-appropriate access. The app requests minimum practical permissions from the operating system and cloud providers. Google Drive collaboration uses the narrower drive.file model with targeted authorization of known Sortify workspace files instead of requesting full Drive access.

2. Authentication and Identity

2.1 Identity Providers

Sortify uses Firebase Authentication (Google LLC) to manage user identity. Credentials are managed by an industry-standard identity platform, not stored in a custom database. Supported sign-in methods:

Related account features include: password reset email, email verification, profile update support, and account deletion flow.

2.2 Firebase App Check

Sortify initializes Firebase App Check at startup to verify that requests originate from the genuine Sortify application.

App Check helps prevent unauthorized clients from accessing Firebase backend services even if an API key were exposed.

2.3 Password Policy

When using email/password authentication:

• Minimum length: 8 characters
• Must include: at least 1 uppercase letter and 1 number
• Maximum length: 128 characters

2.4 Account Lockout

• Sortify applies authentication abuse protections including provider-side rate limiting and app-side safeguards.
• Exact lockout thresholds, timing, and enforcement behavior may vary by platform and release.
• Firebase Authentication provides additional server-side rate limiting controls.

2.5 Session Management

• Sessions maintained by Firebase Authentication tokens, refreshed automatically while active
• App-level inactivity lock behavior is implemented with a 15-minute baseline in current releases
• On timeout, the app returns to the lock screen (PIN or biometric prompt)

3. App-Level Access Controls (PIN and Biometric Lock)

3.1 PIN Lock

• Users can set a numeric PIN to protect the app independently of the device lock screen
• The PIN is hashed and stored in platform secure storage (iOS Keychain / Android Keystore)
• The plaintext PIN is never stored or transmitted
• PIN data is local to the device and never synced

3.2 Biometric Lock

• On compatible devices, users can enable fingerprint or face unlock as an alternative to PIN entry
• Biometric processing is handled entirely by the device operating system (Apple Face ID/Touch ID, Android BiometricPrompt)
• Sortify receives only a success/failure signal — no biometric template is ever accessed, stored, or transmitted by the app
• Biometric opt-in status is stored locally as a preference flag only

3.3 Auto-Lock

• The app automatically locks after 15 minutes of inactivity
• Auto-lock behavior and settings availability may vary by release

4. Local Data Protection

4.1 SQLite Database

Sortify stores all operational workspace data (items, rooms, history, workspace metadata) in a local SQLite database stored in the app's private data directory:

• Not accessible to other apps (enforced by Android and iOS sandboxing)
• Not readable without root/jailbreak access on standard devices

4.2 Secure Storage

Sensitive values are stored using platform-native secure storage:

Secure storage is used for: workspace encryption keys, PIN hash data, session-related tokens, and other sensitive local security values.

4.3 Photo Storage

Item photos are stored in the app's private directory, not accessible to other apps. Provider photo sync for Google Drive, OneDrive, and Dropbox uses an optional separate encrypted photo_workspace.sortifypkg package so photo sync can be enabled per workspace and independently from the core workspace package. Images are normalized to JPEG, constrained to a maximum 1280 x 1280 bounding box without upscaling, compressed at quality 55, encrypted with the workspace key using AES-256-GCM, and protected by package checksums. Core join and recovery do not require the photo package.

Sortify Cloud and Enterprise use the same low-resolution compression boundary for optional managed photo sync. Each image is encrypted on-device with the workspace key before upload to a workspace-scoped Firebase Storage path. Firestore receives only ciphertext metadata. Storage and Firestore rules require active workspace membership for managed media; auditor and viewer roles cannot upload media. Photo-sync failure does not block core inventory event synchronization.

5. Workspace Encryption

5.1 Algorithm

Sortify uses AES-256-GCM for all workspace sync encryption.

GCM mode provides both confidentiality (data cannot be read without the key) and authentication (tampered ciphertext is rejected).

5.2 Key Management

• Each workspace has its own unique AES-256 encryption key
• Keys are generated using a cryptographically secure random number generator
• Keys are stored in platform secure storage only — never in the database or app files in plaintext
• A short key fingerprint (SHA-256 hash of the key, 16-character base64 prefix) is stored in the workspace record to verify key integrity without exposing the key
• Keys are workspace-scoped — each workspace has a different key, limiting the blast radius of any key compromise

Sortify's recovery architecture adds an account-level envelope layer without giving MokingBird plaintext keys:

• each account may have an AccountMasterKey generated on-device;
• each workspace keeps its own WorkspaceKey for encrypting sync files;
• WorkspaceKeys may be wrapped into per-user encrypted workspace key envelopes;
• the AccountMasterKey may be wrapped into an encrypted account key envelope;
• the unlock key is derived on the user's device from the user's Sortify account password or, for OAuth-only accounts, a user-created Sortify recovery password;
• Firestore stores encrypted envelopes, salts, KDF parameters, status fields, and timestamps, but not plaintext passwords, AccountMasterKeys, or WorkspaceKeys.

Firebase Authentication proves identity. It is not, by itself, the encryption secret. If a user forgets the applicable password and loses all unlocked devices, encrypted workspace recovery may be impossible because MokingBird cannot decrypt the envelopes for the user.

5.3 Sync File Format

When workspace data is prepared for sync:

1. The workspace database is serialized
2. A fresh IV is generated per encryption operation
3. Data is encrypted with the workspace key using AES-256-GCM
4. The resulting file is uploaded to the cloud storage folder

Format: [12-byte IV][AES-256-GCM ciphertext with 128-bit auth tag]

For managed Sortify Cloud and Enterprise SyncNative workspaces, the same zero-knowledge rule applies to realtime deltas: the device encrypts each change event or checkpoint before upload, and the server stores only encrypted payloads plus safe routing metadata.

5.4 Key Rotation

Sortify includes a key-rotation framework for workspace encryption keys. Rotation behavior, schedule, and rollout policy may vary by release and operational policy.

Key rotation should be used deliberately, such as after member removal, suspected compromise, ownership changes, or explicit security action. Aggressive time-based key rotation is avoided because collaborative encrypted workspaces require stable access to historical encrypted snapshots and per-member envelopes.

6. Sync Security

6.1 Cloud Authorization

Sortify accesses cloud storage using OAuth 2.0 obtained through the provider's standard consent flow. At the time of this document version, production sync support is Google Drive, OneDrive, and Dropbox. OAuth tokens are stored in device secure storage.

6.1.1 Google Drive

For Google Drive, Sortify uses the narrower Google Drive drive.file access model:

https://www.googleapis.com/auth/drive.file

Under this model, Sortify does not request broad access to a user's full Google Drive. Instead, Sortify stores exact Google Drive file references for the encrypted Sortify workspace package and asks the user to authorize those known Sortify files when needed.

For collaborative Google Drive workspaces, a secondary user may see a Finalize Join step after the primary user approves the workspace request. This step can open Google's file authorization interface so the user can grant Sortify access to the specific encrypted Sortify workspace package shared with them. The user is not being asked to browse their whole Drive; the goal is to authorize the known Sortify workspace file needed for sync.

The security boundary is implemented through provider permissions, app behavior, and stored workspace file references:

• Sortify stores the Google Drive file ID for the encrypted Sortify workspace package.
• Drive sync operations use saved Sortify file IDs instead of scanning arbitrary Drive locations.
• Google Drive Picker or targeted authorization is used only as a consent and repair mechanism for known Sortify workspace files.
• Sync reads and writes encrypted Sortify sync artifacts, such as the workspace package and related metadata.
• Sortify does not intentionally index, copy, analyze, or upload unrelated Google Drive files.
• If Google Drive authorization is revoked or the selected account cannot access the shared Sortify file, Sortify may show a reconnect, retry, or Finalize Join state until access is repaired.

6.1.2 Microsoft OneDrive

When OneDrive is enabled, Sortify uses Microsoft identity and Microsoft Graph OAuth permissions to operate Sortify workspace folders and encrypted Sortify sync files.

The current implementation direction uses permissions for:

• file read/write access for Sortify workspace artifacts;
• Microsoft account identity display and validation;
• offline access so sync can continue without requiring a new interactive login on every sync;
• sharing operations where OneDrive workspace collaboration is enabled.

Security boundaries:

• OAuth tokens are stored in platform secure storage.
• OneDrive item IDs, paths, ETags, and sharing records are used only for Sortify workspace sync and provider access management.
• Sortify uses OneDrive ETags for optimistic concurrency control where supported.
• Sortify does not intentionally browse, index, or analyze unrelated OneDrive content.

6.1.3 Dropbox

When Dropbox is enabled, Sortify uses Dropbox OAuth permissions to operate Sortify workspace folders, encrypted Sortify sync files, metadata, and shared-folder membership.

The current implementation direction uses permissions for:

• file content read/write access for Sortify sync artifacts;
• file metadata read/write access for locating and versioning Sortify files;
• account identity display and validation;
• sharing read/write access for collaborative workspace folders.

Security boundaries:

• OAuth tokens are stored in platform secure storage.
• Dropbox folder paths, shared folder IDs, revision IDs, and sharing records are used only for Sortify workspace sync and provider access management.
• Sortify uses Dropbox revision IDs for optimistic concurrency control where supported.
• Dropbox App Folder mode may be insufficient for collaborative sharing; shared workspaces can require Dropbox app configuration that supports shared folder operations.
• Sortify does not intentionally browse, index, or analyze unrelated Dropbox content.

6.1.4 Sortify Cloud and Enterprise SyncNative

Sortify Cloud and Enterprise SyncNative workspaces use MokingBird-managed infrastructure as a zero-knowledge encrypted transport, not as a plaintext inventory database.

Security boundaries:

• devices encrypt workspace changes before upload;
• Firebase/Firestore may store encrypted event payloads, encrypted checkpoint payloads, sequence numbers, workspace IDs, member IDs, roles, timestamps, device IDs, sync cursors, and entitlement flags;
• Firebase/Firestore must not store plaintext item names, room names, locations, notes, quantities, photos, decrypted workspace database snapshots, plaintext WorkspaceKeys, or plaintext AccountMasterKeys;
• authorized devices decrypt events locally using workspace keys;
• recovery uses encrypted key envelopes and checkpoints, not server-held plaintext keys.

Sortify Cloud serves eligible non-enterprise users who want managed collaboration without connecting every invited member to Google Drive, OneDrive, or Dropbox. Enterprise SyncNative serves eligible organizations that need encrypted event collaboration, organization-scoped administration, member controls, checkpoints, and operational support. Access is controlled by entitlement and deployment configuration.

6.2 Sync Behavior

Current sync security behavior includes:

• local-first data handling;
• encrypted database and change log upload before cloud transfer;
• metadata-driven sync orchestration (metadata file contains only non-sensitive operational fields);
• cloud-folder access checks during join before active secondary membership is finalized;
• provider-specific Finalize Join flows for cloud providers where an additional access step is needed;
• targeted Google Drive file authorization for known encrypted Sortify workspace packages;
• optional managed zero-knowledge sync for Sortify Cloud and Enterprise SyncNative workspaces;
• pull-only initial join sync so secondary users do not bootstrap or overwrite an owner workspace snapshot;
• blocking states when provider folder access or initial pull fails;
• offline queue handling with a maximum queue age of 7 days;
• retry and exponential backoff behavior;
• conflict detection and resolution pipeline;
• optimistic concurrency controls using provider version tokens where supported;
• provider backoff when recurring configuration failures occur.

6.3 What MokingBird Cannot Access

Because sync artifacts are encrypted with workspace keys that are stored locally or recoverable only through encrypted key envelopes:

• MokingBird cannot read the contents of your synced workspace data;
• MokingBird does not store plaintext WorkspaceKeys, plaintext AccountMasterKeys, or plaintext recovery/account passwords;
• Firebase/Firestore recovery metadata alone is not enough to decrypt workspace contents;
• Firebase/Firestore managed sync metadata and encrypted event payloads alone are not enough to decrypt workspace contents;
• even if cloud storage credentials were compromised at the provider level, data remains protected by AES-256-GCM encryption;
• the metadata file contains only non-sensitive operational metadata (workspace ID, sync timestamps, version).

6.4 Conflict Resolution

When the same workspace is modified on multiple devices:

• the sync engine detects conflicts by comparing remote and local state through the change journal and version tokens;
• conflicts are resolved automatically using a Last-Write-Wins (LWW) policy based on updated_at timestamps, with a deterministic tie-breaker used when timestamps are equal;
• all changes, including overwritten values, are preserved in the change journal for audit purposes;
• a user-facing conflict review interface may be introduced in a future release; in the current version, resolution is handled automatically.

7. Export Security

Sortify includes secure export functionality supporting:

• Encrypted JSON export — workspace data exported using the workspace encryption key path;
• Plain JSON export — unencrypted export for user portability;
• CSV export — for spreadsheet-compatible use.

Users should treat plain export files as sensitive data and store them appropriately.

8. Workspace Access Control

8.1 Role-Based Permissions

8.2 Invitation Control

Only the Primary User can generate workspace invitations. The Primary User can revoke access by removing a member at any time.

Sortify distinguishes two approval concepts:

• Sortify workspace approval: the owner approves whether a user becomes an active workspace member.
• Cloud provider access approval: the owner or owner device grants access to the private cloud folder that stores encrypted sync artifacts.

For private cloud providers such as Google Drive, OneDrive, and Dropbox, provider access may be required even when a workspace is configured for no manual Sortify approval. Firebase membership alone does not make a private provider folder or file accessible. Sortify therefore tracks approval states separately so the app can show whether a user is waiting for Sortify workspace approval, cloud-provider access, or a provider-specific Finalize Join action. For Google Drive drive.file workspaces, this may include selecting or authorizing the encrypted Sortify workspace package that the owner shared.

8.3 Data Isolation

Workspace data is scoped by workspace_id throughout the data model. A user with access to one workspace cannot access data from another workspace they are not a member of. This is enforced at the database query level.

9. Audit Trail and History

Sortify maintains a complete audit trail:

• every item records added_by (user ID) and added_at (timestamp);
• every modification records last_updated_by and last_updated_at;
• a change journal logs every field-level change (old value, new value, user, timestamp);
• item movement history tracks every location change over time;
• the workspace activity feed aggregates recent operations by all members.

History is stored locally and synced. Secondary users cannot delete workspace history.

10. Error, Analytics, and Monitoring

Sortify initializes:

• Firebase Crashlytics — crash diagnostics, stack traces, app state at time of crash;
• Firebase Analytics — anonymous usage patterns, screen views, feature engagement;
• Firebase Performance Monitoring — performance issue tracking, sync and startup timings.

Crash and analytics reports are designed not to include workspace inventory content or photos. Telemetry configuration may vary by release and environment.

11. Security Responsibilities

11.1 What MokingBird Is Responsible For

• implementing reasonable application security controls;
• protecting local secrets using platform secure storage;
• encrypting synchronized workspace data before upload;
• maintaining app integrity measures through Firebase App Check;
• supporting secure auth flows and session management;
• improving diagnostics, monitoring, and abuse resistance;
• applying patches in response to identified vulnerabilities.

11.2 What Users Are Responsible For

12. Known Security Boundaries

Users should be aware of the following:

• Rooted or jailbroken devices: Local database and secure storage may be more vulnerable. Not recommended for sensitive use cases.
• Shared device risk: If multiple people share a device without PIN/biometric lock, workspace data is accessible to anyone who unlocks the device.
• Cloud account security: Security of synced data depends on security of your cloud storage account. MFA on connected accounts is strongly recommended.
• Workspace membership: Adding untrustworthy members gives them access to workspace data. Manage invitations carefully.
• Compliance: Sortify is not certified for regulated industries (healthcare, finance, defense). Organizations with regulatory requirements must assess suitability independently.
• Analytics and diagnostics: Firebase services still process limited technical data even in areas where workspace content is local-only.

13. Public Security Trust Themes

For website and app-store trust messaging, the strongest accurate claims about Sortify are:

• Your data, your cloud
• AES-256-GCM encrypted sync
• Local-first architecture
• Role-based shared workspace collaboration
• Device security support with PIN and biometrics
• App integrity protections through Firebase App Check (Play Integrity / DeviceCheck)
• Optional zero-knowledge managed sync for Sortify Cloud and Enterprise SyncNative

14. Security Incident Response

If MokingBird becomes aware of a material security vulnerability or incident:

• we will investigate and prioritize a fix based on severity;
• we will apply patches as quickly as practicable;
• we will communicate with affected users where required by applicable law or where notification would materially help users protect themselves;
• we may temporarily restrict affected features to contain an active risk.

To report a security vulnerability: [email protected]

Please describe the issue, steps to reproduce, and potential impact. We will respond to responsible disclosures promptly.

15. Third-Party Security Dependencies

Sortify is a registered brand of MokingBird Oy, Finland. Security document version 1.2 — June 2026