OWL Privacy Policy
OWL encrypts resource files and chat messages on your device before upload. In client-side decryption (CSD), we do not receive a usable content key. Account recovery preserves that boundary by using a recovery key held only by you. Server-side decryption (SSD) gives the server the key needed for the delivery you request. This policy describes the release design and the information each feature processes.
Contents
- Scope
- Our zero-knowledge model
- Information we collect
- What our servers can & cannot see
- How we use information
- AI assistant (QUAIL)
- Third parties & sub-processors
- Google user data (Google API Services)
- Cookies, browser storage & tracking
- Signing in on your devices
- Password recovery & your recovery key
- Data retention
- Security
- Your rights & choices
- Children
- International transfers
- Changes to this policy
- Contact
1. Scope
This policy covers the OWL File-Server service at ndevr.org and the OWL clients that connect to it — the NDEVR desktop and mobile apps, the OWL web client (file library, chat, account and admin pages), and the OWL command-line tools. It also covers the NDEVR product catalog, licensing/activation, and billing features that run on the same server.
It does not cover third-party services you choose to connect (for example your Dropbox, Microsoft OneDrive or Google Drive account, or a payment processor), which are governed by their own privacy policies.
2. Our zero-knowledge model
OWL's zero-knowledge and end-to-end claims cover CSD resource and chat payloads, including when user-held recovery is enabled. In practice:
- Your password stays on your device. The web sign-in flow supports OPAQUE. Authentication records establish account access; they do not provide a usable content-decryption key. Password-based private-key encryption happens locally.
- Your private key is encrypted on your device. Each account has a randomly generated NIST P-256 key pair. Your password protects the stored private-key envelope. Optional recovery creates a second encrypted envelope under a recovery key held only by you; NDEVR cannot open either envelope.
- Your files are sealed before upload. File contents are compressed and encrypted with AES-256 on your device. In CSD we receive ciphertext and wrapped keys without a usable Content Key. In SSD, your request sends the Link/Content Key to the server so it can decrypt that delivery.
- Your messages use client-side encryption. OWL chat content is AES-256 encrypted under a per-conversation key wrapped to each member's public key. We store ciphertext and wrapped keys we cannot open, including when user-held recovery is enabled.
OWL uses established cryptographic primitives, including P-256, AES-256, ECIES and SHA-256. Format compatibility must be verified across supported clients. Data is also protected in transit by TLS/HTTPS.
3. Information we collect
Account information
- Username and email address (required); an optional phone number; an optional profile avatar image; and a flag for whether you have chosen to make your profile information public.
- Account timestamps (when the account was created), email-verification and approval status.
- The IP address recorded at registration.
Authentication & key material
- Authentication records for sign-in, including the OPAQUE registration record used by the web flow; never your plaintext password.
- Your public key (readable so others can encrypt data to you) and your password-encrypted private key. The server does not receive the key needed to open the private-key envelope.
- If you opt in to password recovery: a copy of your private key encrypted on your device under your user-held recovery key — see §11.
- Web session tokens are stored only as SHA-256 hashes; verification and reset tokens are likewise stored hashed.
Your files and their metadata
- Encrypted file contents (ciphertext only) and prior versions.
- Operational file/folder metadata: MIME type, size, timestamps, folder hierarchy, ownership and permissions. Private Drive names are a release encryption target, still being integrated; current beta names must be treated as server-readable. Preview confidentiality depends on where the preview is generated and stored; it is not covered by a blanket metadata claim.
- File access logs: read/write events with user (if any) and IP address.
Sharing
- Who owns each item and who it is shared with; permission levels and expiry dates.
- Share links: a bcrypt hash of any link password and an encrypted decrypt-password blob; the access token is stored hashed.
- Contacts you have shared with.
Messages (OWL chat)
- Encrypted message bodies and headers (ciphertext only) and per-member wrapped conversation keys.
- Metadata we can read: sender, timestamps, conversation membership and read/unread state.
Billing & payments
- We use third-party processors (Stripe and/or PayPal). Card entry happens on the processor's own hosted page — full card numbers never touch our servers or your browser's connection to us.
- We store: the processor's customer ID, a vaulted payment-method token, and masked display fields (card brand, last four digits, expiry month/year).
- A transaction ledger (amount, currency, status, failure reason if any) and subscription status/renewal information.
Licensing & activation
- Issued licenses bound to a username/email, the activation request and resulting activation file, and validity dates.
- For optional hardware-locked licenses, we record which constraints are enabled (e.g. CPU, drive, OS key, MAC address). The underlying hardware identifiers are checked on your device; we do not store the raw values.
Logs & technical data
- Request logs (IP address, method, path, status, timing) and protocol action logs.
- Failed-login records (IP, attempted username, reason) for brute-force protection.
- An administrative audit log of privileged actions, and system health metrics (CPU/memory/disk — no personal data).
Email & marketing preferences
- Subscription status and per-topic preferences (product updates, marketing, feedback, billing), with hashed confirm/unsubscribe tokens. Transactional emails (verification, password reset, receipts, unread-message digests if you enable them) are sent regardless of marketing preferences.
Connected cloud accounts (optional)
- If you import from Dropbox, OneDrive or Google Drive, OAuth access tokens are encrypted on your device to your OWL public key before storage. We hold ciphertext without a usable account private key; user-held recovery preserves that boundary. Only files you explicitly select are imported.
4. What our servers can & cannot see
This is the heart of the design. Even with full database access, the server operator:
| Data | Server can read it? |
|---|---|
| File contents | CSD: ciphertext only. SSD: plaintext during the requested delivery |
| Chat message bodies & headers | CSD: ciphertext only, including with user-held recovery |
| Your private key | No — password-encrypted; optional recovery is also encrypted under a key only you hold |
| Per-file / per-conversation / folder keys | Wrapped to authorized recipients; SSD supplies a usable delivery key for that request |
| Your password | No — authentication records do not contain the plaintext password |
| Connected cloud (Dropbox/OneDrive/Drive) tokens | No — encrypted to your key |
| Full payment card numbers | No — held by the payment processor |
| Username, email, phone, avatar | Yes |
| Private Drive file / folder names | Release target: encrypted on the client. Integration is in progress; current beta names remain server-readable |
| Sizes, types, timestamps, structure, identifiers and server-managed names | Yes — operational metadata remains visible |
| Who shares what with whom; permissions & expiries | Yes |
| Chat sender, timestamps, conversation membership | Yes |
| IP addresses and request/access logs | Yes |
| Billing metadata (masked card, amounts, status) | Yes |
5. How we use information
- To provide the service: store and sync your encrypted files, deliver encrypted messages, manage sharing, authenticate you, and issue/validate licenses.
- To bill you for paid products and subscriptions through our payment processors.
- To secure the service: detect and rate-limit abuse and brute-force attempts, and maintain audit logs.
- To communicate with you: transactional email (verification, resets, receipts, and unread-message digests if enabled) and, only with your consent, product or marketing updates.
- To operate and improve reliability using aggregate system metrics and usage counts.
We do not sell your personal information, and we do not use your file contents or message contents for advertising or model training.
6. AI assistant (QUAIL)
OWL offers optional AI-assisted features (the QUAIL chat assistant and AI-assisted modeling). When you use them, the content you submit is relayed by our server to an AI model to generate a response. Depending on the feature and our configuration at the time, that model may be one we host ourselves or one operated by a third-party AI provider; we may change providers as the service evolves.
The content sent to the AI model can include:
- Your prompts and the text of your request.
- Screenshots / images of your work. The AI-assisted modeling features capture rendered images of your current scene (or reference images you provide) and send them to the AI model so it can "see" what you are working on. If you do not want an image processed by an AI model, do not use the image-based AI features.
- We do not send your username, account identity, files, or email address along with the prompt or image.
- We record per-request usage counts (model name, token counts, status) tied to your account for billing and rate-limiting. We do not retain a copy of your prompts, images, or the AI's responses beyond what is needed to serve the request.
- No-training guarantee. We do not use, and we require any third-party AI provider we use not to use, your prompts or images to train AI models.
7. Third parties & sub-processors
We share the minimum necessary with the following providers, each only for the stated purpose:
| Provider | Purpose | What they receive |
|---|---|---|
| Amazon Web Services (Lightsail) | Server hosting | All data, as stored (encrypted content stays encrypted) |
| Third-party AI provider | AI assistant responses | Prompt text and any screenshots you submit (no account identity; no training use) |
| Stripe / PayPal | Payment processing | Name, email, card details you enter on their page |
| Dropbox / Microsoft / Google | Cloud import, calendar feeds & mailbox linking you initiate | OAuth consent, the files you select, and — only if you link them — the calendars and mailboxes you connect |
We send transactional and opt-in email (verification, password resets, receipts, and any digests you enable) from our own server; we do not route your email address or message content through a third-party email-delivery provider.
We may disclose information if required by law, to enforce our terms, or to protect the rights, safety and security of our users and service. For CSD content we hold operational metadata and ciphertext rather than plaintext. User-held recovery does not give us a readable account key. SSD plaintext and keys in process have a different boundary.
8. Google user data (Google API Services)
OWL offers three optional Google connections: "Import from Google Drive", a Google Calendar feed in the OWL calendar, and a linked Gmail mailbox in OWL Mail. You only ever interact with Google through OWL if you choose to connect one of them; if you never do, OWL never requests, receives, or stores any Google user data. This section describes specifically how OWL accesses, uses, stores, shares, retains and deletes Google user data, and our use of it complies with the Google API Services User Data Policy, including the Limited Use requirements.
Data accessed
- Google Drive (import):
https://www.googleapis.com/auth/drive.fileonly. This is Google's per-file (non-sensitive) scope: it grants OWL access only to the specific files and folders you explicitly select through the Google Picker. OWL cannot see, list, or access any other file in your Google Drive. For a selected item we receive its Drive file ID, name, MIME type, size, and the file's binary content (so it can be imported). - Google Calendar (feed):
https://www.googleapis.com/auth/calendar.readonly, requested only when you connect Google in the calendar. Your browser reads your calendar list and the events in the visible date window directly from Google; the OWL server does not receive them. - Gmail (linked mailbox):
https://www.googleapis.com/auth/gmail.modify, requested only when you link Gmail in OWL Mail settings. Your browser reads your messages directly from Google's API and can mark them read, starred, or archived at your request; the OWL server does not receive, store, or index your Gmail messages. - Each connection also involves a short-lived Google OAuth access token (and, if you allow offline access, a refresh token).
- OWL does not request access to any Google data beyond the scopes above — no contacts, no photos, no profile browsing — and does not use Google Sign-In to create or log in to your OWL account.
How we use it
- The sole purposes are the features you invoke: importing the files you select from Google Drive into your own OWL library (downloaded, then encrypted on your device under your OWL key, AES-256, exactly like any other file you add to OWL), showing your Google Calendar events in your own OWL calendar view, and showing your Gmail mailbox inside OWL Mail. Calendar and Gmail data is displayed in your browser session and is not copied into OWL unless you explicitly save something.
- We do not use Google user data for advertising, and we do not use it to train, develop, or improve any AI / machine-learning models — neither ours nor any third party's. Gmail message content is not sent to any AI model.
How we share it
- OWL does not sell, rent, or transfer Google user data to any third party. We do not share it with data brokers, advertisers, or AI providers.
- Imported file content is encrypted before OWL upload. It is shared only if and when you choose; CSD and SSD shares have the different trust boundaries described in §2. Calendar events and Gmail messages are read by your browser directly from Google and are not relayed through or stored on the OWL server.
- The OAuth token exchange happens directly between your browser/app and Google, except that the code/refresh exchange for Google's confidential client transits our server solely to attach the server-held client secret; the resulting tokens are not retained server-side in readable form (see below). Our underlying hosting provider (see §7) stores only the encrypted blobs.
How we store & protect it
- Tokens: any Google OAuth access/refresh token is encrypted on your device to your OWL public key (ECIES) before storage. We hold it as ciphertext without a usable account private key, including with user-held recovery. Tokens are transmitted only over TLS/HTTPS.
- File content: imported files are encrypted with AES-256 on your device before upload; our servers store only ciphertext. The protections in §13 apply.
- We never write Google access tokens or selected file content to logs in readable form.
How long we keep it & how to delete it
- Tokens: each stored (encrypted) Google token persists only until you disconnect that connection in OWL (the cloud picker, the calendar's account list, or Mail settings' Unlink) or revoke OWL's access from your Google Account permissions page; disconnecting deletes the stored token blob and asks Google to revoke the token. We do not retain Google tokens beyond what is needed to serve the connections you keep.
- Imported files: once imported, a file is a normal OWL item. It stays until you delete it (or close your OWL account), per the retention rules in §12 — it is your copy, decoupled from Google Drive.
- Revocation: revoking access at Google immediately stops OWL from being able to read anything new from your Drive, Calendar, or Gmail. To delete already-imported copies, delete those items in OWL. To request deletion of any associated data, contact privacy@ndevr.org.
9. Cookies, browser storage & tracking
The OWL web client does not use advertising cookies, analytics trackers, tracking pixels, or third-party fonts/CDN trackers. We don't use Google Analytics or similar.
To run, the web client stores data locally in your browser:
- Session storage (cleared when the tab closes): your session token, your decrypted private/public keys for the session, and basic profile info, so you don't re-enter your password to view your own files.
- Local storage (persists, only if you choose "Keep me signed in"): the same session/key material, plus small preferences such as your light/dark theme choice and which product tours you've seen.
This data stays in your browser and is never sent to advertising or analytics platforms. Signing out, or clearing your browser storage, removes it. Because your keys can be cached in the browser, use "Keep me signed in" only on devices you trust.
10. Signing in on your devices
We publish four separate mobile apps — OWL Calendar, OWL Connect, OWL Nest and OWL Media. Signing into each one separately is tedious, so on a device you own the apps can share a single sign-in. Because that means key material is stored on your device, here is exactly what it involves.
When you sign into an OWL app and choose Keep me signed in, the app saves one record to your device's operating-system keystore:
| What is in it | Your session token, your account profile, and your private encryption key. |
| Where it lives (iOS) | The iOS Keychain, in an access group shared by the OWL apps. |
| Where it lives (Android) | A shared OWL account held by the Android account system, readable only by apps signed with our certificate. If that is unavailable, an encrypted store whose master key is held in the Android Keystore, private to that one app. |
| When it is written | Only if you chose "Keep me signed in". |
| When it is erased | As soon as you sign out of any OWL app, or delete the app. |
The record never leaves your device. We do not receive it, it is not part of your account on our servers, and it is not the same thing as the optional copy held for password recovery — see §11.
On iOS the item is stored as available only while the device is unlocked, on this device only. In practice that means it is protected by your device passcode or biometrics, it is excluded from iCloud Keychain sync, and it is excluded from device backups — it cannot follow you to a new phone, where you will sign in again.
Password autofill
So that a password you have saved for ndevr.org can be offered inside the apps, we publish a file at /.well-known/apple-app-site-association (iOS) and /.well-known/assetlinks.json (Android) naming our three apps. This is a one-way statement from us that those apps belong to this domain.
- It lets your own password manager — iCloud Keychain, Google Password Manager, 1Password, or whatever you use — recognise the app's sign-in form as belonging to ndevr.org and offer to fill it.
- Your password manager decides what to offer, and nothing is filled without you choosing it.
- We never see your password, before or after autofill. It is turned into a derived credential on your device, exactly as described in §2.
- These files contain only our own app identifiers. They carry no information about you.
Turning it off, and clearing it
- Leave Keep me signed in unchecked and nothing is written to the keystore at all — the session ends when the app closes.
- Sign out from any OWL app to erase the shared record for all of them.
- Delete the app to remove its stored data with it.
- As with the browser, use "Keep me signed in" only on devices you control. Anyone who can unlock your device can open your OWL apps.
11. Password recovery & your recovery key
Without recovery, losing your password can mean losing access to encrypted data. To give you a choice, OWL offers an optional password-recovery feature built around a recovery key that only you hold.
- If you enable recovery, your device generates a random recovery key, shows it to you once, and wraps your account private key under it (an authenticated AES-256-GCM envelope). Only that wrapped copy is stored with us; the recovery key itself never leaves your device. If you forget your password, an emailed, single-use, time-limited reset code releases the wrapped copy back to your device, where your recovery key unlocks it. The reset code alone unlocks nothing, and we cannot open the wrapped copy.
- If you do not enable recovery (the default), no recoverable copy of your key is stored, and no one — including us — can restore access if you lose your password. The same is true if you enable recovery and then lose the recovery key.
- You can turn recovery on or off at any time in your account settings. Turning it off deletes the wrapped copy; turning it on again issues a new recovery key.
12. Data retention
- Account data, files and messages: kept until you delete them or close your account. Deleting your account removes your account record and cascades to your sessions, keys, files and conversation membership.
- Security & request logs: kept for a limited operational period for abuse prevention and troubleshooting, then rotated.
- Administrative audit logs and billing/transaction records: retained longer where needed for security, accounting and legal/tax obligations.
- Backups: encrypted content remains encrypted in backups; residual copies are purged on the normal backup cycle after deletion.
13. Security
Beyond CSD content encryption, we apply defense-in-depth: TLS for all connections; OPAQUE in the web sign-in flow; authenticated encryption (AES-256-GCM) for private-key and recovery envelopes; constant-time comparison and rate-limiting on authentication and password resets; hashed session and reset tokens; and audit logging of privileged actions. A server-only breach does not provide the usable key for CSD content when usable decryption keys stay on authorized devices; SSD processing, endpoints, and visible operational metadata remain in scope of a compromise.
For more on our security practices, regulatory conformity (including the EU Cyber Resilience Act and data protection), and how to report a vulnerability, see our Compliance & Conformity and Security pages.
14. Your rights & choices
- Access & portability: you can view and download your files and data through the OWL clients at any time.
- Correction: update your email, phone, avatar and profile visibility in account settings.
- Deletion: delete individual files/messages, or close your account to remove your data as described in §12.
- Marketing: opt out of marketing email at any time via the unsubscribe link or your email preferences; transactional messages will still be sent.
- Recovery: enable or disable password recovery with a recovery key at will (§11).
- Connected apps: disconnect Dropbox/OneDrive/Google Drive to remove the stored (encrypted) tokens.
Depending on where you live, you may have additional rights (for example under the GDPR or CCPA) to access, correct, delete, or restrict processing of your personal data, and to lodge a complaint with a regulator. To exercise any right, contact us at privacy@ndevr.org.
15. Children
OWL is not directed to children under 16, and we do not knowingly collect personal information from them. If you believe a child has provided us personal information, contact us and we will delete it.
16. International transfers
Our servers are operated in the United States. If you access OWL from elsewhere, your information (including the encrypted content and the metadata described above) is processed there. Where required, we rely on appropriate safeguards for cross-border transfers.
17. Changes to this policy
We may update this policy as the service evolves. We will revise the "Last updated" date above and, for material changes, provide a more prominent notice. Continued use after an update means you accept the revised policy.
18. Contact
NDEVR, LLC
21816 SE 280th St, Maple Valley, WA 98038
Email: privacy@ndevr.org