Oscar ← Back

Privacy policy

1. What Oscar stores about you

Everything below is stored in a Supabase (PostgreSQL) database controlled by the owner. Every row is tagged with the account it belongs to.

Your account

What you ask Oscar, and what it answers

What Oscar remembers on purpose

Location

If you use the location features, Oscar stores individual points — latitude, longitude, reported accuracy, altitude, speed, heading, the time zone of the device, which source sent it, and any label you gave it — plus daily roll-ups summarising where you were. This is a location history. It is written directly by the device without a model involved, and it is only as complete as the number of points your phone or browser actually sends.

Devices and connected machines

2. Information about other people

Oscar can also search for public information about a named person or username across public profile sources, and read public web pages. What it finds is returned to you and stored in the conversation log like any other answer.

3. Where your data is sent

Oscar is not a self-contained system. To answer a question it sends data to other services, each with its own privacy policy and its own retention:

Oscar does not sell data, does not serve advertising, and has no analytics or tracking scripts on any page.

4. Credentials and connected accounts

Credentials are handled differently from ordinary data. Google refresh tokens and similar secrets are encrypted with AES-256-GCM before being stored, and are decrypted only when a request needs them. Your password is stored as a hash. Your Shortcut and runner keys are stored as digests: each is shown once when issued and cannot be read back afterwards — if you lose one, the fix is to issue a new one, which invalidates the old.

Signing in requires both your password and a code sent to your email address. The Shortcut key is a weaker credential — it sits in plain text inside a Shortcut on your phone — so it can ask questions but cannot read your history.

5. Who can read your data

You can. Everything Oscar has stored for you is reachable from your own signed-in session.

The owner administers accounts but has no interface for reading your content. The account tools show the owner your email address, name, request note, the IP and user-agent from your request, and your account status — enough to approve, decline, suspend or reinstate you. There is deliberately no admin view of anybody's conversations, memory, location or files.

That is a limit on the application, not on the database. The owner controls the Supabase project and can query it directly, as can anyone who obtains the service credentials. Supabase and Vercel staff have whatever access their own policies allow. An account here is a guest account on somebody else's machine, and you should not store anything on it that would be a serious problem for the owner to see.

Other users cannot read your data. Every query is scoped to a single account, and queries that fail to say whose data they want are rejected rather than answered broadly.

6. How long it is kept, and deletion

There is no automatic expiry. Conversations, memory, location points and everything else are kept until somebody deletes them.

You can delete individual items as you go: Oscar can forget a fact about you or about a person on request, and plans, schedules, protocols, MCP servers and push subscriptions can each be removed.

There is no self-service "delete my account" button. To close an account and erase its data, ask the owner at davidstall312@gmail.com. Deleting the account row cascades: conversations, jobs, memory, contacts, locations, plans, schedules, secrets, push subscriptions and command history all go with it. Copies already sent to third parties — OpenAI, an email provider, a search engine — are outside the owner's control and are governed by those services' own retention policies.

Suspending an account is not deletion. A suspended account cannot sign in, but its data remains.

7. Your choices

8. Security

Traffic is served over HTTPS. Secrets are encrypted at rest, passwords are hashed, and API keys are stored as digests. Signing in requires a second factor by email. Dangerous shell commands are refused, or held for your explicit confirmation, rather than run.

None of that makes it invulnerable. This is software maintained by one person, without a security team, formal audit, or compliance certification. If you find a vulnerability, please report it to davidstall312@gmail.com rather than disclosing it publicly.

9. Changes and contact

If this policy changes materially, the date at the top will change, and for anything that meaningfully affects what is stored or where it is sent the owner will notify approved accounts by email.

Questions, deletion requests, and access requests: davidstall312@gmail.com.