Privacy

Last updated: 2026-05-14

zz-drop is a command-line program that runs entirely on your machine. The only hosted service we operate is this website. There is no OAuth callback server — the CLI talks to each provider's API directly. This page describes what zz-drop and zz-drop.net do and don't collect.

What we don't collect

• No telemetry from the CLI. The binary makes no calls home, ever.
• No product analytics, page-view trackers, or third-party scripts on this site.
• No cookies. This site sets none.
• No IP or user-agent logs are tied to your zz-drop profiles or OAuth identities. Web-server access logs (raw IP, path, status code) are kept transient — rotated every 24 hours and never joined to any account.
• No advertising networks. No remarketing pixels.

What stays on your device

• Your passphrase. It is never transmitted, in any form.
• Your encrypted profile file (profiles-local.zz), stored in your local zz-drop configuration directory (for example ~/.config/zz-drop/ on Linux, ~/Library/Application Support/zz-drop/ on macOS). This file holds your OAuth refresh tokens (Google Drive, OneDrive, Dropbox), your Nextcloud credential (app password or Login Flow v2 token), and the account email address each OAuth provider reports at setup time (used only as a display label so you can tell multiple accounts apart). The file is sealed with XChaCha20-Poly1305 using a key derived from your passphrase via Argon2id.
• The plaintext file content you transfer. During an upload, zz-drop reads the file from your source path, holds the bytes in memory, and sends them to the configured cloud provider over TLS. During a download, zz-drop receives the bytes from the provider, holds them in memory, and writes them to the destination path you chose. zz-drop does not keep additional temporary or cache copies.

Cloud provider data

zz-drop integrates with four cloud providers — Google Drive, Microsoft OneDrive, Dropbox, and Nextcloud. Each section below documents how zz-drop accesses, uses, shares, stores, retains, and deletes data at that provider. The structure of each section mirrors the categories required by the Google API Services User Data Policy and the equivalent disclosure expectations of Microsoft Entra and Dropbox app review.

File content encryption (applies to all providers)

In v1, file content is uploaded to the configured provider as-is. The provider sees the file the same way it would if you used the provider's own client. zz-drop does not add an additional encryption layer on file content in v1; client-side end-to-end encryption is on the v1.1 roadmap. For sensitive content today, encrypt the file before passing it to zz-drop.

Authentication flow (applies to all providers)

For Google Drive and OneDrive, zz-drop uses the OAuth 2.0 Device Authorization Grant (RFC 8628): the browser is sent to the provider's authorization page, the user approves there, and the CLI polls the provider directly for the resulting tokens. For Dropbox, zz-drop uses the OAuth 2.0 Authorization Code + PKCE flow without a redirect_uri: the provider shows a code, the user pastes it into the CLI. For Nextcloud there are two paths: (a) app password — the user generates an app password in their Nextcloud security settings and pastes server URL, username, and that app password into the CLI; or (b) Login Flow v2 — the user enters only the server URL in the CLI, opens the browser link the CLI prints, signs in and approves on their Nextcloud server, and the server returns both the login name and a scoped app password to zz-drop over its polling endpoint (the user never types their Nextcloud username or password into the CLI). None of these flows redirects through a host operated by zz-drop — there is no OAuth callback server in the data or authentication path. Tokens, app passwords, and Login Flow v2 tokens are written only to the local encrypted profile and are never seen by any zz-drop-operated server.

Google Drive

Data accessed

zz-drop requests a single Google OAuth scope: https://www.googleapis.com/auth/drive.file (the drive.file scope). This is a non-sensitive, per-file scope: it grants zz-drop access only to files zz-drop itself creates in the user's Google Drive. zz-drop does not integrate with Google's file picker, so it cannot gain access to files the user created previously with other applications. The Google user data zz-drop accesses under this scope is:

• File content — the bytes the user uploads to, or downloads from, zz-drop's folder in their Google Drive.
• Basic file metadata — the fields zz-drop requests via fields=files(id,name,size,mimeType) on the Drive API: the file identifier, filename, size, and MIME type. zz-drop does not request creation or modification timestamps, ownership, parents, permissions, or any other Drive metadata field.
• Account email address — at setup time, immediately after the OAuth consent succeeds, zz-drop calls GET /drive/v3/about?fields=user(emailAddress) once to fetch the email address of the Google account that just granted consent. This address is shown by the CLI and TUI as a label so the user can distinguish multiple Google accounts, and is stored locally in the encrypted profile (the user_email field). It is never used for any authentication decision and is never transmitted off the user's device.
• Refresh tokens — issued by Google as part of the OAuth flow so the user does not have to re-consent on every session.

zz-drop does not request userinfo.email, userinfo.profile, or any Google Workspace scope. zz-drop does not access Gmail, Calendar, Contacts, Google Photos, files in the user's Drive created by other applications, or any Google service or Drive content beyond what is described above.

Data usage

Google user data is used solely to perform the user-facing upload, download, list, and delete actions the user explicitly initiates from the zz-drop CLI. The account email address is used solely as a display label. Every action is started by a CLI command typed by the user — there is no background sync, no automatic upload, no scheduled job. zz-drop does not use Google user data for advertising, profiling, behavioral analytics, training or developing AI or machine-learning models, or any purpose other than the user-facing file transfer feature.

Data sharing

zz-drop does not share Google user data with any third party for any purpose. File content and metadata transit directly from the user's device to Google's Drive API over TLS — no zz-drop-operated server sits in the data path. zz-drop does not sell, rent, lease, license, or otherwise transfer Google user data to any party. zz-drop has no subprocessors and no affiliates that receive Google user data, and does not produce or share any aggregated, anonymized, or derived datasets from Google user data.

Data storage and protection

zz-drop operates no server-side storage of Google user data. Google user data lives only at Google itself (in the user's own Google Drive) and on the user's local device. On the local device, the OAuth refresh token issued by Google and the account email address (label) are stored inside the encrypted profile file profiles-local.zz in the local zz-drop configuration directory (for example ~/.config/zz-drop/ on Linux, ~/Library/Application Support/zz-drop/ on macOS). The file is sealed with XChaCha20-Poly1305 using a key derived from the user's passphrase via Argon2id. The passphrase never leaves the device and is never transmitted to any server. During a transfer, file content is held in memory: uploads read from the user's source path and stream the bytes to Google; downloads write the bytes received from Google to the destination path the user specified. zz-drop does not create additional temporary or cache copies of file content.

Data retention and deletion

Server-side retention of Google user data is zero: zz-drop operates no server that receives or holds Google user data. On-device retention persists only until the user removes the credentials:

• Revoke zz-drop's access to your Google account — visit myaccount.google.com/permissions and remove zz-drop.
• Delete the local OAuth refresh token and stored email label — run zz w (wipe) in the CLI, or delete the profiles-local.zz file from your zz-drop configuration directory.
• Files previously uploaded — remain in the user's Google Drive and are managed there.
• Deletion requests — if you believe zz-drop holds any Google user data of yours and want it removed, contact privacy@zz-drop.net. Because zz-drop holds no Google user data on any server, such a request will result in a written confirmation that no data is held.

Google API Services — Limited Use

zz-drop's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. zz-drop uses Google user data only to provide the user-facing upload, download, list, and delete features described above and to label which Google account granted consent. zz-drop does not use Google user data for serving advertisements. zz-drop does not transfer Google user data to third parties — the only data transfer is the user-initiated transfer between the user's device and Google's own API. zz-drop does not allow humans to read Google user data; because zz-drop operates no server that receives Google user data, the standard Limited Use exceptions (user's affirmative agreement to view specific files, security investigations, legal compliance, or aggregated internal operations) do not apply in practice. zz-drop does not use Google user data for training or developing AI or machine-learning models.

Microsoft OneDrive

Data accessed

zz-drop requests three Microsoft Graph OAuth scopes: Files.ReadWrite, offline_access, and User.Read. The Microsoft user data zz-drop accesses under these scopes is:

• File content — the bytes the user uploads to, or downloads from, zz-drop's folder in their OneDrive.
• Basic file metadata — the fields zz-drop deserializes from each DriveItem Graph response: item identifier, filename, size, and whether the item is a folder. The full Graph payload contains additional fields (created and modified timestamps, etag, parent reference, etc.) but zz-drop does not read or store them.
• Account email address (or User Principal Name) — at setup time, immediately after the OAuth consent succeeds, zz-drop calls GET /me?$select=mail,userPrincipalName once to fetch the mail field (with a fallback to userPrincipalName, which personal Microsoft accounts often use when mail is empty). This address is shown by the CLI and TUI as a label so the user can distinguish multiple OneDrive accounts, and is stored locally in the encrypted profile (the user_email field). It is never used for any authentication decision and is never transmitted off the user's device.
• Refresh tokens — issued by Microsoft because offline_access is requested, so the user does not have to re-consent on every session.

zz-drop does not access Outlook, Teams, Calendar, SharePoint, OneNote, or any other Microsoft 365 service.

Data usage

Microsoft user data is used solely to perform the user-facing upload, download, list, and delete actions the user explicitly initiates from the zz-drop CLI, and to display the account's email address in the CLI and TUI so multiple accounts can be distinguished. Every action is started by a CLI command typed by the user — there is no background sync, no automatic upload, no scheduled job. zz-drop does not use Microsoft user data for advertising, profiling, behavioral analytics, training or developing AI or machine-learning models, or any purpose other than the user-facing file transfer feature.

Data sharing

zz-drop does not share Microsoft user data with any third party for any purpose. File content and metadata transit directly from the user's device to Microsoft's Graph API over TLS — no zz-drop-operated server sits in the data path. zz-drop does not sell, rent, lease, license, or otherwise transfer Microsoft user data to any party. zz-drop has no subprocessors and no affiliates that receive Microsoft user data, and does not produce or share any aggregated, anonymized, or derived datasets from Microsoft user data.

Data storage and protection

zz-drop operates no server-side storage of Microsoft user data. Microsoft user data lives only at Microsoft itself (in the user's own OneDrive) and on the user's local device. On the local device, the OAuth refresh token issued by Microsoft and the account email address (label) are stored inside the encrypted profile file profiles-local.zz in the local zz-drop configuration directory (for example ~/.config/zz-drop/ on Linux, ~/Library/Application Support/zz-drop/ on macOS). The file is sealed with XChaCha20-Poly1305 using a key derived from the user's passphrase via Argon2id. The passphrase never leaves the device and is never transmitted to any server. During a transfer, file content is held in memory: uploads read from the user's source path and stream the bytes to Microsoft; downloads write the bytes received from Microsoft to the destination path the user specified. zz-drop does not create additional temporary or cache copies of file content.

Data retention and deletion

Server-side retention of Microsoft user data is zero: zz-drop operates no server that receives or holds Microsoft user data. On-device retention persists only until the user removes the credentials:

• Revoke zz-drop's access to your Microsoft account — visit account.live.com/consent/Manage for personal accounts, or myapps.microsoft.com for work or school accounts.
• Delete the local OAuth refresh token and stored email label — run zz w (wipe), or delete the profiles-local.zz file from your zz-drop configuration directory.
• Files previously uploaded — remain in the user's OneDrive and are managed there.
• Deletion requests — if you believe zz-drop holds any Microsoft user data of yours and want it removed, contact privacy@zz-drop.net.

Dropbox

Data accessed

zz-drop requests four Dropbox OAuth scopes: files.content.write, files.content.read, files.metadata.read, and account_info.read. The Dropbox application is registered as an "App folder" application, which sandboxes all access to a single dedicated App folder Dropbox creates in the user's account for zz-drop — zz-drop cannot read, write, list, or even see anything outside that folder. The Dropbox user data zz-drop accesses under these scopes is:

• File content — the bytes the user uploads to, or downloads from, the App folder.
• Basic file metadata — the fields zz-drop reads from the /2/files/list_folder response: the file-or-folder type discriminator, filename, and size. zz-drop does not read or store modification timestamps, content hashes, sharing state, or other extended metadata.
• Account email address — at setup time, immediately after the OAuth consent succeeds, zz-drop calls POST /2/users/get_current_account once (this is the only use of the account_info.read scope) and reads the email field. This address is shown by the CLI and TUI as a label so the user can distinguish multiple Dropbox accounts, and is stored locally in the encrypted profile (the user_email field). It is never used for any authentication decision and is never transmitted off the user's device.
• Refresh tokens — issued by Dropbox because the authorize URL sets token_access_type=offline, so the user does not have to re-consent on every session.

Data usage

Dropbox user data is used solely to perform the user-facing upload, download, list, and delete actions the user explicitly initiates from the zz-drop CLI, all confined to the App folder, and to display the account's email address in the CLI and TUI so multiple accounts can be distinguished. Every action is started by a CLI command typed by the user — there is no background sync, no automatic upload, no scheduled job. zz-drop does not use Dropbox user data for advertising, profiling, behavioral analytics, training or developing AI or machine-learning models, or any purpose other than the user-facing file transfer feature.

Data sharing

zz-drop does not share Dropbox user data with any third party for any purpose. File content and metadata transit directly from the user's device to Dropbox's API over TLS — no zz-drop-operated server sits in the data path. zz-drop does not sell, rent, lease, license, or otherwise transfer Dropbox user data to any party. zz-drop has no subprocessors and no affiliates that receive Dropbox user data, and does not produce or share any aggregated, anonymized, or derived datasets from Dropbox user data.

Data storage and protection

zz-drop operates no server-side storage of Dropbox user data. Dropbox user data lives only at Dropbox itself (in the user's own App folder) and on the user's local device. On the local device, the OAuth refresh token issued by Dropbox and the account email address (label) are stored inside the encrypted profile file profiles-local.zz in the local zz-drop configuration directory (for example ~/.config/zz-drop/ on Linux, ~/Library/Application Support/zz-drop/ on macOS). The file is sealed with XChaCha20-Poly1305 using a key derived from the user's passphrase via Argon2id. The passphrase never leaves the device and is never transmitted to any server. During a transfer, file content is held in memory: uploads read from the user's source path and stream the bytes to Dropbox; downloads write the bytes received from Dropbox to the destination path the user specified. zz-drop does not create additional temporary or cache copies of file content.

Data retention and deletion

Server-side retention of Dropbox user data is zero: zz-drop operates no server that receives or holds Dropbox user data. On-device retention persists only until the user removes the credentials:

• Revoke zz-drop's access to your Dropbox account — visit dropbox.com/account/connected_apps and remove zz-drop.
• Delete the local OAuth refresh token and stored email label — run zz w (wipe), or delete the profiles-local.zz file from your zz-drop configuration directory.
• Files previously uploaded — remain in the user's Dropbox App folder and are managed there.
• Deletion requests — if you believe zz-drop holds any Dropbox user data of yours and want it removed, contact privacy@zz-drop.net.

Nextcloud

Data accessed

zz-drop authenticates to the user's Nextcloud server over WebDAV (HTTPS) with HTTP Basic authentication. The credential is provisioned in one of two ways during setup:

• Manual app password — the user generates an app password in their Nextcloud account security settings and types the server URL, their username, and that app password into the CLI.
• Login Flow v2 — the user types only the server URL into the CLI. zz-drop calls POST {server}/index.php/login/v2, prints the resulting browser link, and polls the server while the user signs in and approves in the browser. Once the user approves, the server returns three fields to zz-drop over the polling endpoint: the server URL (echoed back), the user's loginName, and an issued appPassword scoped to zz-drop. The user never types their Nextcloud username or main password into the CLI in this path.

In both paths the credential is an app-scoped secret distinct from the user's main account password, and can be revoked independently from the Nextcloud security settings. zz-drop never sees the user's main Nextcloud login password. The Nextcloud user data zz-drop accesses is:

• File content — the bytes the user uploads to, or downloads from, their Nextcloud account.
• Basic file metadata — the WebDAV properties zz-drop requests on each PROPFIND: displayname, getcontentlength, and resourcetype (filename, size, and whether the item is a file or a folder). zz-drop does not request modification timestamps, ETags, ownership, or other WebDAV properties.
• Login name — either typed by the user (manual app-password path) or returned by the Nextcloud server (Login Flow v2 path). Used to construct WebDAV request URLs and as the Basic auth username. Stored locally in the encrypted profile alongside the credential. Not transmitted off the user's device, except in the WebDAV Authorization header to the user's own Nextcloud server.

Data usage

Nextcloud user data is used solely to perform the user-facing upload, download, list, and delete actions the user explicitly initiates from the zz-drop CLI. Every action is started by a CLI command typed by the user — there is no background sync, no automatic upload, no scheduled job. zz-drop does not use Nextcloud user data for advertising, profiling, behavioral analytics, training or developing AI or machine-learning models, or any purpose other than the user-facing file transfer feature.

Data sharing

zz-drop does not share Nextcloud user data with any third party for any purpose. File content, metadata, and the Authorization header bearing the app password / token transit directly from the user's device to the user's own Nextcloud server over TLS — no zz-drop-operated server sits in the data path. zz-drop does not sell, rent, lease, license, or otherwise transfer Nextcloud user data to any party. zz-drop has no subprocessors and no affiliates that receive Nextcloud user data.

Data storage and protection

zz-drop operates no server-side storage of Nextcloud user data. Nextcloud user data lives only at the user's Nextcloud server and on the user's local device. On the local device, the username, server URL, and Nextcloud credential (app password or Login Flow v2 token) are stored inside the encrypted profile file profiles-local.zz in the local zz-drop configuration directory (for example ~/.config/zz-drop/ on Linux, ~/Library/Application Support/zz-drop/ on macOS). The file is sealed with XChaCha20-Poly1305 using a key derived from the user's passphrase via Argon2id. The passphrase never leaves the device and is never transmitted to any server. During a transfer, file content is held in memory: uploads read from the user's source path and stream the bytes to the user's Nextcloud server; downloads write the bytes received from the server to the destination path the user specified. zz-drop does not create additional temporary or cache copies of file content.

Data retention and deletion

Server-side retention of Nextcloud user data on zz-drop infrastructure is zero: zz-drop operates no server that receives or holds Nextcloud user data. (The user's own Nextcloud server's retention policy is set by the user or their administrator and is outside zz-drop's scope.) On-device retention persists only until the user removes the credentials:

• Revoke zz-drop's access to your Nextcloud account — delete the app password (or Login Flow v2 token) from your Nextcloud account security settings.
• Delete the local credential — run zz w (wipe), or delete the profiles-local.zz file from your zz-drop configuration directory.
• Files previously uploaded — remain in the user's Nextcloud account and are managed there.
• Deletion requests — if you believe zz-drop holds any Nextcloud user data of yours and want it removed, contact privacy@zz-drop.net.

Changes to this policy

If zz-drop changes how it accesses, uses, stores, shares, or retains user data, this page is updated and the "Last updated" date at the top is revised. Material changes to how Google user data is handled also require resubmission to Google for verification under the Google API Services User Data Policy.

This website

The site is static HTML and CSS, served from an OVH VPS. No JavaScript is required to read any page. No fonts, scripts, or images are loaded from third-party CDNs.

Contact

Questions, corrections, requests: privacy@zz-drop.net.