Skip to content

Privacy Policy for Spillway

Effective date: September 3, 2026
Originally effective: July 31, 2026
Last updated: September 3, 2026
Status: Pre-alpha / invited testing
Prior version: July 31, 2026 · Version archive

Privacy in plain language

Spillway does not automatically collect your email, App data, usage history, diagnostics, crash reports, or other information from your device. We do not operate a server that receives a copy of your mailbox or local App records, and we cannot remotely access them.

We have no current plans to build automatic collection of user data into Spillway. We promise not to add any feature that sends data to us—or to an additional service—without first explaining in clear, specific language what would be sent, where it would go, why it would be sent, and what choices you have. Nothing would be transmitted through such a feature unless you explicitly opt in.

A general acceptance of this privacy policy does not count as that opt-in. The choice must be presented when the specific feature is used. Where practical, you should be able to review and limit what is included, and potentially sensitive information should be excluded by default.

Our design goal is stronger than ordinary disclosure: we aim to build Spillway so that potentially sensitive information never needs to reach a Spillway-operated server at all. Local processing, user-controlled storage, minimized diagnostics, and direct connections to services you deliberately choose are preferred over centralized collection.

Spillway may still send information directly to a service or recipient that you intentionally choose—for example, Gmail, Apple services, a cloud AI provider, an email recipient, or a storage location you select—because that transmission is necessary for the function you requested. Those services are separate from Spillway and do not automatically give the Spillway operator access to the information.

Spillway is the working name of an email organization application currently developed and, in some builds, displayed as EmailSorter (the “App”). The App is independently developed and operated by Josh Pasek. It is not a University of Michigan service and is not endorsed, operated, or supported by Google, Apple, Ollama, OpenAI, Anthropic, or any other third-party provider.

This policy explains how the App accesses, uses, stores, and shares information. Because the App is in pre-alpha testing, its features and this policy may change. Prior public versions are retained in the legal archive.

1. Summary

The App is designed to be local-first:

  • Mail and App-created organization data are primarily stored on the user’s own device.
  • Google OAuth tokens, API keys, and similar credentials are stored using Apple Keychain where supported.
  • The current App does not include an operator-controlled server, automatic telemetry channel, automatic crash-reporting channel, or remote-support channel that silently returns App data to the operator.
  • The operator cannot remotely browse or retrieve a user’s device, Gmail account, Apple Keychain, local App database, local diagnostics, or local backups through the App.
  • The operator generally has access only to information a user deliberately sends to the operator, such as an email, support request, or beta-feedback submission, plus ordinary records held by the public website host.
  • The App does not sell personal information, use Gmail data for advertising, or operate its own behavioral advertising or analytics system.
  • Users may choose local AI through Ollama or explicitly configure a cloud AI provider. Cloud AI use sends selected content directly to that provider, not to the App operator.
  • Users may import user-supplied Reference Sources, such as roster files, for local contextual reasoning. These are ordinarily stored locally unless the user separately enables a future sync/export destination that includes them.
  • Users control whether the App performs supported Gmail changes such as labeling, marking read or unread, starring, archiving, moving messages to Trash, managing drafts, or sending mail.

2. Current technical limits and future transmission

No silent return channel to the operator

The current App has no technical pathway for automatically returning Gmail content, App-created records, local diagnostics, usage information, crash reports, local backups, or imported Reference Source content from the user’s device to the operator.

Installing or using the App does not create a remote operator account, remote support session, hidden upload service, remote-administration capability, or operator-accessible copy of the user’s local data.

The user may still direct information to third parties through features they intentionally configure or use—for example, Google, Apple, a cloud AI provider, an outbound email recipient, or a user-selected storage location. Those transmissions do not provide the same information to the operator unless the user separately sends it to the operator.

User-reviewed problem reports

Current builds may offer a Report a Problem flow that prepares a user-visible diagnostic report and lets the user choose what to do with it. Spillway does not automatically send that report.

The report is designed to use minimized diagnostics rather than mailbox content. Before transmission, the user can review the report and choose whether to compose an email or save the report. Oversized reports may be saved as an attachment rather than silently truncated. The operator receives the report only if the user deliberately sends it.

Users should still review any report before sending it and should not add confidential message content, credentials, student/patient/client information, private links, or other sensitive material unless they have deliberately decided the operator should receive it.

Any future operator-accessible or additional-service transmission requires explicit confirmation

If a future version adds an optional feature that could transmit data to the operator or to any additional service—for example, automatic crash reporting, hosted sync, support upload, or another diagnostic channel—the feature must not silently begin sending information merely because the App was updated or opened.

Before the first such transmission, the App should present a clear, specific, just-in-time explanation stating what is being sent, where it is going, why it is needed, what categories of information may be included, and how the user can decline or limit the transmission.

General acceptance of this Privacy Policy does not substitute for feature-specific confirmation.

3. Information the App accesses

Google account and Gmail data

When a user connects a Google account, the App running on that user’s device may access:

  • account email address and basic account identity;
  • messages and threads, including senders, recipients, subject lines, headers, snippets, message bodies, dates, labels, and read/star/archive/Trash state;
  • attachments or attachment metadata when needed to display, analyze, download, draft, or send them;
  • Inbox, Sent, Draft, and related Gmail state needed for App features; and
  • provider identifiers needed to reconcile messages, threads, drafts, and user-directed actions.

This access occurs through the App on the user’s device. It does not give the operator independent access to the user’s Gmail account or mailbox.

App-created data

The App creates local data such as:

  • categories and category hierarchy;
  • classifications, summaries, extracted requests, dates, opportunities, and other derived information;
  • user corrections, filing decisions, workflow status, sender preferences, and Work items;
  • drafts, Outbox state, templates, and links to supporting messages;
  • settings, connection status, and limited operational metadata;
  • local inference/learning evidence and rebuildable derived state; and
  • local backups and recovery records when those features are used.

These records are ordinarily stored on the user’s device or in a storage or sync location the user separately chooses. The operator does not have routine access to them.

User-supplied Reference Sources

A user may import source material such as a roster file so Spillway can derive contextual facts with provenance. Current Reference Source support is intentionally narrow and local-first.

Imported source bytes, source metadata, user-authored attachments/scopes, and derived reference facts are stored locally in the current implementation. They are not automatically uploaded to the operator or to a cloud AI provider merely because they exist.

If a user later enables a sync, export, backup, or AI-processing feature that includes Reference Source information, the applicable destination and data boundary should be disclosed separately.

Credentials

OAuth tokens, AI-provider API keys, and client secrets are stored in Apple Keychain where supported. They are not intentionally included in ordinary data files, backups, diagnostics, or the source repository. The operator cannot retrieve a user’s Keychain contents through the App.

Information a user submits directly

If a user contacts the operator, sends a problem report, or submits beta feedback, the operator receives the information the user chooses to provide. This is the principal category of user-specific App information the operator can actually possess.

Website information

Visiting the App’s public web pages may cause the website host to receive ordinary request information such as IP address, browser type, requested page, and time of access. The App does not combine ordinary website logs with Gmail content.

4. How information is used

Google user data, Reference Sources, and App-created data are used by the App on the user’s device to provide or improve user-facing App functions, including:

  • displaying, searching, threading, and organizing mail;
  • classifying messages and extracting possible requests, commitments, dates, opportunities, and other contextual information;
  • learning from user corrections and other permitted evidence;
  • grounding inferences with deterministic facts and user-supplied reference context;
  • performing actions the user initiates or enables;
  • creating, editing, scheduling, and sending drafts or messages;
  • supporting Apple-system actions the user reviews and confirms;
  • preventing duplication, recovering from interrupted operations, and protecting local data; and
  • diagnosing errors using local, minimized diagnostics.

Information voluntarily sent to the operator is used to respond to support, feedback, security, or privacy requests.

The operator does not use Google user data to create advertising profiles, sell data, determine creditworthiness, or train a general-purpose AI model.

5. Local and cloud AI

Ollama or another configured local endpoint

When the user selects Ollama at a local address, inference requests are sent to the Ollama service configured by the user, normally on the same Mac. The operator does not receive those requests.

A user who changes the endpoint to another computer or hosted service is directing data to that endpoint. “Local AI” describes the ordinary on-device configuration; the actual privacy boundary is the endpoint receiving the request.

Cloud AI providers

A user may explicitly configure a supported cloud AI provider. When cloud processing is enabled for an account or operation, selected content and task instructions may be sent directly to that provider to perform the requested inference.

The operator does not receive that content merely because the user selected a cloud provider. The provider’s terms, privacy policy, account type, and data controls apply. Users should not enable cloud processing for information their employer, institution, client, contract, or law does not permit them to send to that provider.

Account-specific AI boundaries

Different accounts may have different AI policies. Spillway’s architecture is intended to preserve those boundaries rather than treating a combined inbox as one authorization domain.

Some abstracted or user-authored knowledge may eventually be useful across accounts even when restricted source content may not cross the boundary. Any such transfer must preserve provenance and policy constraints and must not be used to reconstruct or leak protected source content.

6. When information is shared

The App does not sell or rent personal information. Information may leave the device only in circumstances such as:

  • Google: to authenticate the user and read or modify Gmail as necessary for requested App functions;
  • User-selected AI providers: when the user enables cloud AI or configures a nonlocal inference endpoint;
  • Apple services: when the user asks the App to create or work with an item and grants the relevant system permission;
  • User-selected storage or sync locations: when the user enables a backup, export, or sync feature;
  • Outbound recipients and Gmail: when the user sends, schedules, or saves a draft; or
  • Support/feedback recipients: when the user deliberately sends a report, email, or other submission.

These transmissions go to the selected service or recipient. They do not make the transmitted information available to the App operator unless the user separately sends it to the operator or the operator clearly identifies itself as controlling the receiving service.

The App’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including its Limited Use requirements.

The operator can disclose only information the operator actually possesses or controls. That may include support correspondence, user-sent diagnostic/problem reports, beta feedback, privacy requests, security reports, and ordinary website-host records available to the operator.

The operator does not have an App-operated copy of users’ Gmail content and cannot use the App to remotely access or retrieve a user’s device, Gmail account, Apple Keychain credentials, local App database, local Reference Sources, local diagnostics, recovery snapshots, backups, exports, or user-controlled sync storage.

A legal request directed to the operator cannot create technical access the operator does not otherwise have. Third-party providers may separately receive legal requests for data they hold under their own systems and policies.

7. Storage and retention

Mail caches, Reference Sources, App-created organization data, and settings are stored on the user’s device unless the user deliberately chooses another storage/sync destination for a supported feature.

Some local files may contain sensitive message or source content in readable form. Users are responsible for protecting the device, operating-system account, and any copies or backups.

The App may create local recovery snapshots. Credentials are excluded. Not every local store is necessarily included in every backup mechanism; users should not assume that a backup or derived-data reset captures or restores all source material unless the App explicitly says so.

Local data remains until removed through App controls, deleted by the user, removed with the App’s data container, or otherwise cleared by the operating system. Disconnecting Google access does not necessarily delete local backups, exported copies, or imported Reference Sources.

Third-party providers retain data under their own policies. Deleting local App data does not delete source mail from Gmail unless the user separately performs a Gmail deletion action.

8. User choices and deletion

Users may:

  • decline or revoke Google access;
  • choose local AI, cloud AI, or no AI for supported accounts/features;
  • disable supported Gmail write-back controls;
  • remove connected accounts and local data using available App controls;
  • remove imported Reference Sources using available controls;
  • delete local backups and exported files; and
  • ask the operator to delete support, diagnostic, or beta-feedback information associated with them, subject to legal or security retention needs.

Because the operator does not possess ordinary local App data or Gmail content, deletion requests sent to the operator ordinarily apply only to information the user directly submitted to the operator or that the operator otherwise actually holds.

Google access can be reviewed or revoked from the user’s Google Account security settings. Revoking access prevents new API access but does not itself remove local files or backups already created by the App.

9. Security

The App uses measures such as Apple Keychain for credentials, PKCE for supported OAuth flows, atomic local writes, validated recovery snapshots, minimized diagnostics, and explicit authority/provenance distinctions in parts of its local data model.

No software or storage method is perfectly secure. The App remains pre-alpha software and should not be treated as institutionally approved or as satisfying FERPA, HIPAA, IRB, records-retention, or other legal requirements without an independent review.

10. Children

The App is intended for adults and is not directed to children under 13. The operator does not knowingly collect children’s personal information through an App-operated service.

11. International use

Users who access third-party services or cloud AI may cause information to be processed in countries other than their own. Those providers’ terms and privacy notices govern their processing.

12. Changes to this policy

This policy may be updated as the App changes. The current page will show both an effective date and a last-updated date, and superseded public versions will be preserved in the legal archive.

If a change materially expands how Gmail or other user data is used or shared, users will be given appropriate notice or choice before the new use applies. A future feature that creates a new operator-accessible or additional-service transmission must also follow the feature-specific disclosure and confirmation requirements described above.

13. Contact

Questions, privacy requests, deletion requests, and security concerns may be sent to software@joshpasek.com.

Documentation provenance: Iterative human–AI construction. This is a project-drafted policy document and is not a claim of attorney review. See Documentation Provenance.