All users and security reviewers
Security & Data Handling
How DecoDocs handles documents by default (Open vs Upload), what we aim for in revocation/audit trails, and security expectations for read-only cloud drive integrations.
About this documentation
- Official product documentation for DecoDocs (operated by Snap Sign Pty Ltd).
- Written for end users, evaluators, and integration teams.
- For support or to request corrections, use the footer support links or email support@decodocs.com.
- DecoDocs provides informational analysis and is not legal advice.
Security principles
DecoDocs is designed to reduce accidental exposure and keep review workflows controlled.
- Least privilege by default (only what is required for a user-initiated action)
- No background sync or indexing for cloud drives (only open files a user selects)
- Clear user messaging about what is and is not stored
- DecoDocs provides informational analysis and is not legal advice
Open vs Upload (Free vs Pro) — the contract
We separate “open a file to analyze it” from “upload/save a file for history”. This is an explicit product contract to reduce accidental storage and preserve user control.
- Default is Open (ephemeral): analyze without creating history or storing a saved copy by default
- Upload/Save is explicit: a deliberate action that creates history and enables export/sharing workflows
- Paid features map to storage: vaults/history/export depend on explicit upload/save behavior
- UI must distinguish Open vs Upload so users understand the difference before proceeding
Token revocation & audit logging (expectations)
For OAuth-based integrations (for example Drive/OneDrive), we design for safe disconnect and reviewable events.
- User-initiated disconnect: user can disconnect at any time from settings
- Revocation: on disconnect, attempt provider token revocation where supported and stop further reads immediately
- Short-lived access: prefer short-lived access tokens; protect refresh tokens and rotate/revoke when needed
- Audit trail: log connect/disconnect events and key access actions with timestamps and user/account attribution
Google Drive (read-only) — design notes
Goal: let a user pick a Drive file, open it, analyze it — without background syncing or broad indexing.
- Consent + scopes: request the smallest read-only scopes required for user-selected file access
- Connect/disconnect UX: clear scopes and a one-click disconnect that revokes access
- Picker → open → analyze pipeline: user selects file, backend fetches content, analysis runs server-side
- Token storage: encrypt at rest; implement rotation and revocation support; no tokens in the browser
OneDrive (read-only) — design notes
Goal: parity with Drive UX where possible, using Microsoft Graph for read-only access to user-selected files.
- Microsoft Graph: use read-only scopes for file selection and retrieval
- Consistent UI: mirror the Drive flow (connect → pick → open → analyze → disconnect)
- Cross-browser testing matrix: test common combinations (Chrome/Safari/Edge on macOS/Windows, iOS Safari, Android Chrome)
iCloud Drive — constraints & parity goals
iCloud Drive access is constrained by platform rules, especially on iOS/Safari. We design around user-initiated selection flows.
- User-initiated file selection: use OS-provided pickers (no background access)
- Open parity: after selection, the open/analyze flow should match local file behavior
- No background sync: do not index or continuously sync iCloud files
Security checklist (cloud drives)
Use this checklist when reviewing or implementing Drive/OneDrive/iCloud access.
- Least-privilege scopes (read-only; no write/delete; avoid broad scopes)
- No background sync or indexing (only fetch a file the user selects)
- Encrypted token storage at rest + rotation/revocation support
- Clear user messaging about what is (not) stored and when upload/save happens
- Disconnect is easy, obvious, and immediate
If you suspect an issue
Report quickly with enough context for investigation.
- Check the Status page for active incidents
- Email support@decodocs.com with the integration (if any), document type, and error details
- Include expected behavior and actual behavior (screenshots help)