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; server-side decryption (SSD) and optional account recovery deliberately change that trust boundary. This policy explains exactly what we collect, what each mode lets us process, how long we keep it, and who else is involved.

Effective date: 1 January 2026 · Last updated: 15 August 2026
Operated by NDEVR, LLC ("NDEVR", "we", "us"). Questions: privacy@ndevr.org.

The short version. With provider-held recovery disabled, CSD resource and chat content is end-to-end encrypted: we store ciphertext without a usable content key. SSD sends a usable key to the server so it can return plaintext, and optional recovery lets the operator recover your account private key; both are explicit provider-trust modes. We can see account details and metadata: usernames, email addresses, file and folder names, sizes, types and timestamps, sharing relationships, and server logs including IP addresses. We do not run advertising or analytics trackers, and we do not sell your data.

Contents

  1. Scope
  2. Our zero-knowledge model
  3. Information we collect
  4. What our servers can & cannot see
  5. How we use information
  6. AI assistant (QUAIL)
  7. Third parties & sub-processors
  8. Google user data (Google API Services)
  9. Cookies, browser storage & tracking
  10. Signing in on your devices
  11. Password recovery & key escrow
  12. Data retention
  13. Security
  14. Your rights & choices
  15. Children
  16. International transfers
  17. Changes to this policy
  18. 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 when the provider does not hold a recovery path for the account. In practice:

  • Your password never leaves your device. When you sign in, your client derives a credential from your username and password locally and sends only that derived value; we never receive or store your actual password. We keep only a salted bcrypt hash of the derived credential.
  • Your private key is encrypted with your password. Each account has an elliptic-curve (NIST P-256) key pair. The private key is wrapped with a password-derived key before storage. With recovery disabled, we cannot open it; if you enable recovery, the operator-held escrow key can recover it.
  • 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. Without account recovery, we store ciphertext and wrapped keys we cannot open.

The cryptography is standard and identical across our desktop, web and command-line clients (P-256, AES-256, ECIES, SHA-256, bcrypt). Data is also protected in transit by TLS/HTTPS.

Important nuance — metadata is not encrypted. Encryption protects your file contents and message bodies. It does not hide metadata such as file and folder names, sizes, types, timestamps, folder structure, who you share with, or who is in a conversation. We can see that metadata, and so can a server administrator with database access. Don't put secrets in file names.
Important nuance — SSD and recovery trust the provider. An SSD request gives the server a usable key and plaintext for that delivery. If you enable password recovery, the operator-held escrow key can recover your account private key and, together with stored wrapped keys, can recover content available to that account. Neither path is zero-knowledge against the provider. Public authored Sites are intentionally published as plaintext web content.

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

  • A salted bcrypt hash of the credential derived from your password (never the password itself).
  • Your public key (stored in the clear, used to encrypt data to you) and your password-encrypted private key. We cannot decrypt the latter with recovery disabled; provider-held recovery creates an explicit escrow path.
  • If, and only if, you opt in to password recovery: a copy of your private key encrypted under a server-held escrow 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.
  • File/folder metadata we can read: name, MIME type, size, created/modified/accessed timestamps, folder hierarchy, and a small preview thumbnail.
  • 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. Without provider-held recovery, we hold ciphertext without a usable account private key; enabling recovery gives the operator a path to recover that key. 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:

DataServer can read it?
File contentsCSD: ciphertext only. SSD: plaintext during the requested delivery
Chat message bodies & headersCSD without recovery: ciphertext only. Recovery can make them recoverable through the account key
Your private keyPassword-encrypted; recoverable by the operator only if you enable escrow
Per-file / per-conversation / folder keysNormally wrapped to public keys; SSD supplies a usable delivery key, and escrow can recover account-wrapped keys
Your passwordNo — never transmitted; bcrypt hash only
Connected cloud (Dropbox/OneDrive/Drive) tokensNo — encrypted to your key
Full payment card numbersNo — held by the payment processor
Username, email, phone, avatarYes
File / folder names, sizes, types, timestamps, structureYes
Who shares what with whom; permissions & expiriesYes
Chat sender, timestamps, conversation membershipYes
IP addresses and request/access logsYes
Billing metadata (masked card, amounts, status)Yes

The two deliberate provider-trust paths are SSD delivery and opt-in password recovery, described above and in §11.

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.
AI features are optional. If you never use them, no prompts or screenshots are sent to any AI model. Because the image-based features transmit pictures of your scene, treat anything visible in your workspace as content that may be processed by an AI model when you use those features.

7. Third parties & sub-processors

We share the minimum necessary with the following providers, each only for the stated purpose:

ProviderPurposeWhat they receive
Amazon Web Services (Lightsail)Server hostingAll data, as stored (encrypted content stays encrypted)
Third-party AI provider (when not self-hosted; subject to change)AI assistant responsesPrompt text and any screenshots you submit (no account identity; no training use)
Stripe / PayPalPayment processingName, email, card details you enter on their page
Dropbox / Microsoft / GoogleCloud import, calendar feeds & mailbox linking you initiateOAuth 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 without escrow we ordinarily hold metadata and ciphertext rather than plaintext. SSD plaintext/keys in process and recovery-enabled account keys fall outside that limitation.

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.file only. 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. With recovery disabled, we hold it as ciphertext without a usable account private key; provider-held recovery changes that boundary. 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.
Limited Use. OWL's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only to provide and improve the user-facing features you request (file import, your calendar view, your linked mailbox), is never used for advertising, is never sold, is not transferred to others except as needed to provide those features or as required by law, and is not used to develop, improve, or train generalized AI/ML models.

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 Files 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 itYour 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 writtenOnly if you chose "Keep me signed in".
When it is erasedAs soon as you sign out of any OWL app, or delete the app.
Why the private key and not just a login token. The token proves who you are, while CSD decryption requires your private key. An app given just a token could list metadata but could not open CSD files or messages. Sharing a sign-in therefore necessarily means sharing the key on that device.

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.

How each platform shares it. On iOS, the apps read one shared Keychain item. On Android, they read one shared account — you will see it listed as "OWL" under Settings → Passwords & accounts. Either way, signing into one app signs you into the others, and signing out of one signs you out of all of them. In a web browser none of this applies: there is no such keystore, so the browser continues to use its own storage as described above.
One Android detail. The shared account is hosted by whichever OWL app you installed first. If you uninstall that app, the account goes with it and the remaining apps ask you to sign in once more.

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 & key escrow

Without recovery, losing your password can mean losing access to encrypted data. To give you a choice, OWL offers an optional, provider-trust password-recovery feature.

  • If you enable recovery, a copy of your private key is encrypted under a master escrow key that the server operator holds (as an authenticated AES-256-GCM blob), and stored with us. This lets us help you regain access if you forget your password, via an emailed, single-use, time-limited reset code.
  • If you do not enable recovery (the default for maximum privacy), no recoverable copy of your key is stored, and no one — including us — can restore access if you lose your password.
  • The escrow key recovers your account private key. Combined with the wrapped per-file, folder, or conversation keys stored for your account, the operator can therefore recover content available to that account. Enabling recovery is not zero-knowledge against the operator.
  • You can turn recovery on or off at any time in your account settings.

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.

We keep each category only as long as needed for the purpose described above (or as required by law); we do not commit to fixed day-count windows for operational logs, which are rotated on a regular cycle.

13. Security

Beyond CSD content encryption, we apply defense-in-depth: TLS for all connections; bcrypt password hashing; authenticated encryption (AES-256-GCM) for escrowed keys; 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 recovery is disabled; SSD processing, recovery-enabled keys, endpoints, and visible 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 escrow 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

This document describes the design of the OWL service as implemented. It is a starting point and should be reviewed by legal counsel before being published as a binding policy.