Privacy Policy

Signing in with Google

The only door either app offers.

Both the extension and the web app sign you in with Google and nothing else — neither one has a password field, and an account created through them is given no usable password at all. When you sign in, Google hands your browser a signed ID token, and our server verifies that token’s signature and audience directly against Google’s keys before it creates or opens your account. An unverified email is never believed.

From that sign-in, we receive and store your Google account email address, your name, your avatar/profile picture URL, and your Google account ID (the “sub” claim), so we can recognize you the next time you open StickyFriend. We access only your basic Google profile via Google Sign-In, and our use of that data complies with the Google API Services User Data Policy, including its Limited Use requirements.

We generate a starting username from the part of your email address before the “@”, so you have something to be called right away. You can change it any time in the web app.

The legacy password endpoints, stated plainly

This page used to say “no passwords, ever.” That was not true, so here is what is. Our server still exposes four HTTP endpoints left over from the version of StickyFriend that predates Google sign-in: /api/auth/register/, /api/auth/login/, /api/auth/change-password/ and /api/auth/password-reset/. Nothing in the extension, the web app or this website calls them, and no button anywhere leads to them — but they are live, and a request sent to /api/auth/register/ with an email and a password really does create an account with a working password on it.

What that means for you: if you signed in with Google, you have no password, and there is nothing on your account for a password to unlock. What it means for us: an unused door is still a door, and we would rather you read about it here than find it in a write-up. We are removing these endpoints; when they’re gone, this section goes with them and the changelog will say so.

One related note while they exist: this deployment has no outgoing mail set up, so password reset by email genuinely cannot work here. The endpoint now says so — it refuses the request outright and points you at Google sign-in — rather than replying “check your inbox” for a message that was never going to arrive.

What we store

Everything, in four groups.

Once you’re signed in, StickyFriend stores the things you’d expect from a workspace that remembers you — and one thing you might not, which is why it now has a group of its own below. This is the inventory of what the live product writes, grouped by who put it there. We’ve written it out rather than summarising, because “and some other bits” is how privacy policies stop being useful. If we add a kind of content that isn’t here, this page changes and the changelog says so.

Things you write

• Chats and messages — your prompts, the AI’s replies, and the tool calls the agent made along the way with their results and labels.
• Projects and everything inside them: to-dos, notes, plan/roadmap bars, and calendar items.
• Notebook entries — the pages you and the AI write into together.
• Saved highlights — the text you highlighted, enough of the surrounding page to find it again, and any note you attached to it.
• Bookmarked messages — which replies you starred, and in which chat.
• Bookmark metadata for the pages you save through StickyFriend.
• Guidelines — the rules you write for the AI, title and body (a Silver-and-up feature).
• Your AI’s persona — its name, avatar, colour and theme, plus the description, writing style, never-do list and the “about me” text you give it.
• Support tickets, and the full body of every message in them — yours and ours — plus any upgrade request you open and the note on it. Anything you paste into a ticket is stored with it, so please don’t paste passwords or card numbers.
• Documents you upload to a project or a knowledge base: the file itself, the text extracted from it, and the chunks of that text we index so the AI can search it.

Things the AI writes about your work

• Memory items — preferences and facts it has picked up, each one citing the exact turn it came from. Every item is viewable and deletable by you, in the app.
• Chat recaps — when a long conversation is compacted, the AI writes a summary of it, its open threads and its progress, and that summary is stored. Compaction never deletes the original messages; they stay.
• Project mindmap nodes and the links between them, and timeline entries for a project.

Things the extension records as you browse The one people don’t expect

StickyFriend lets you open a project in its own browser window. While a window is bound to a project, the extension’s background script watches that window and sends two things to our server, saved on the project so that reopening it puts you back where you were:

• Your open tabs in that window — the title, full URL and pinned state of every tab in it, up to 60 tabs, re-sent about a second and a half after any tab is opened, closed, moved or finishes loading, and once more when you close the window. Each save replaces the previous one.
• A browsing history for that project — the title and full URL of every http/https page that finishes loading in that window, with a timestamp. This is a history we keep, separate from Chrome’s own; the newest 100 entries per project are kept and older ones are dropped. Pages loaded in the first ten seconds after the project window opens are skipped, because those are your tabs being restored rather than you browsing.

Two limits worth stating precisely, because “the extension can see my tabs” deserves a precise answer. This tracking runs only for a window you have bound to a project — browse in any other window and none of it is recorded. And it is URLs and titles only: page contents are not sent by this path. (The agent does read page content, but only when you ask it to act on a page — that’s the chat above, not this.)

Things the service produces or records

• Generated files — the Word, Excel and PowerPoint deliverables you ask for are written to our server (not just streamed to you) so you can download them again later, along with their titles and which project they belong to.
• Documents you upload to a 📚 Library — the file itself, its name, its size and which folder you put it in, all stored on our server. To make a library searchable we also read the text out of each file and keep it as indexed extracts, plus the numeric representations (vectors) that let your AI find the right passage. On Gold and Diamond, files with no text layer — scans, photographs and image-only pages — are additionally read by OCR, which turns those pages into text we then store the same way. (Slide decks are read as text on every library plan; OCR only fills in an individual slide that carries no text at all.) All of it belongs to your account and only your account: every read is filtered by owner on our side, not merely hidden in the interface. Delete a file, a folder or a whole library and the stored bytes, the extracted text and the vectors go with it; so does deleting your account.
• Screenshots, but only if you switch cloud saving on yourself — see Screenshots below.
• Usage metering — the weighted token counts behind your 5-hour window, your golden-credit balance split into granted and purchased, and a ledger row for every grant, top-up and charge. This is what your usage screen is built from.
• A per-call usage record — separately from the meter above, every time a model answers you we write one row with the timestamp, the provider and model that answered, the token counts, our cost, and the id of the chat. No message text is stored in it. This is one of the two records that outlive a deleted account, and deletion strips it down to the tokens, the cost and the date.
• Billing records tied to your subscription (see Payments below).
• The API key issued to your account, which is what lets your web app and your extension talk to our server as you.
• Ordinary server logs — the requests our server handles, with the usual timestamps, status codes and error traces. They exist to keep the thing running and to debug it, not to profile you.

Two things exist in the database but are switched off for everybody right now: an old, separate “shelf” feature — a bag of saved notes, links and pages that shares the word library with the document libraries above and is otherwise unrelated to them; it is refused for every account, including paid ones — and a product-analytics event log, which has an endpoint on our server but which neither the web app nor the extension calls, so nothing you do writes to it. (The handful of rows in that table are from our own test runs, not from any user.) If either is switched on, this page changes before it happens.

📚 Libraries — the document feature — are live on the paid plans, and what they store is listed above. Bronze has no access at all; the refusal happens on our server, not in the interface.

StickyFriend also carries some dormant tables from an older version of its backend, whose code paths were removed in July 2026. Nothing writes to them any more. If your account predates that and left rows behind, they’re covered by everything on this page — including deletion.

Screenshots Cloud saving: off by default

The agent has eyes; that means pictures.

StickyFriend’s browsing agent is a vision agent: to act on your current tab, it processes a screenshot of that tab in real time to decide what to click, type, or scroll next. That’s how it does its job — it can’t act on a page it can’t see.

Saving those screenshots in the cloud is a separate, opt-in toggle, and it ships off. With it off, our server strips screenshot data out of a message before the row is ever written to the database — that rule is enforced server-side, not just hidden in the interface. Turn the toggle on, and screenshots captured during agent steps get stored with that chat so you can look back at what the agent saw. Turn it back off and new screenshots stop being saved; it doesn’t retroactively delete ones already stored. To remove those, use the separate purge screenshots action — in the web app’s Settings, or in the extension’s — which strips the images out of stored messages for one chat or for all of them, leaving the text of the transcript intact.

How your chats get answered

Our model by default; MiniMax only when you ask for it. And a transport warning you should read.

By default, your prompts and chats are processed by our own self-hosted AI model, running on a server we rent and administer — no third-party AI provider is involved in a normal chat. Only when you turn on a specific chat’s “Smarter” toggle does that chat get sent to MiniMax, a third-party AI provider we use as a subprocessor for that feature. It’s off unless you turn it on, and it applies per chat. If you’re on Gold or Diamond, Smarter requests are additionally marked as priority to MiniMax; that’s a queue position, not a difference in what is sent.

Plain-HTTP warning

This page used to say a normal chat “doesn’t leave infrastructure we control”. That was misleading, and here is the correction. Our web server and the machine running the Standard model are two different servers, and the hop between them is made over plain HTTP, not HTTPS — that machine has no TLS listener at all today; we checked. That hop crosses the public internet. So while your Standard chats are not shared with any third-party AI company, the text of a Standard prompt and its reply travels between our two servers unencrypted, and anyone positioned to observe that network path could read it. Please treat Standard chats accordingly and don’t put secrets in them.

To be precise about the scope: this is one hop, between two machines we run, on the Standard route. It does not apply to ✨ Smarter — MiniMax is reached over HTTPS. The real fix is TLS on the model server, not better wording here; when that is done, this warning is deleted and the changelog will record the date.

Web search is a live lookup, not a stored dataset of your searches — and it happens in the browser, not on our server. When the agent searches, your extension queries DuckDuckGo directly and reads the results page, so the search terms go from your browser to DuckDuckGo without passing through us. We keep no record of your searches beyond whatever ends up quoted in the chat transcript itself.

Payments

Stripe handles the money; we handle references to it.

All billing runs through Stripe’s hosted checkout. We never see or store your card number — Stripe does, under its own security and compliance obligations. What we keep on our side is limited to references: your Stripe customer ID, subscription ID, and invoice records, which is how we know what plan you’re on and how we show you your billing history.

How long we keep it

As long as your account exists — three things roll off, and three things outlive a deletion. All six are named below.

Nothing you write is on a clock. Your chats, messages, projects, notes, notebook entries, highlights, memory items and files stay with your account for as long as that account exists: compacting a long chat writes a recap but leaves the original messages in place, and switching a setting off never rewrites what is already stored.

This page used to say “nothing quietly ages it out”, full stop. That was too strong. Three things the software collects on your behalf are capped, and past the cap the oldest entries are dropped without telling you:

• A project’s browsing history keeps its newest 100 entries. Visit a 101st page in a project window and the oldest one falls off the end. It is not archived anywhere; it is gone.
• A project’s open-tab snapshot is a snapshot, not a history. Each save overwrites the last one, so only the most recent state of that window survives, and only its first 60 tabs are recorded.
• The extension’s offline outbox holds 500 undelivered messages. If our server is unreachable for long enough for a 501st to queue up behind them, the oldest queued message is discarded to make room — in your browser, before it ever reaches us.

All three are described in more detail in What we store and what lives in your browser. Everything else keeps the rule at the top of this section.

What deleting your account actually removes

We didn’t want to describe this from memory, so we ran a real deletion against a throwaway account that had been given invoices, a subscription and credit-ledger entries, then dumped every surviving row and every field of the record it left behind. What follows is that dump, in words. Deleting an account erases, in one transaction: your account row itself, your chats and every message in them, chat recaps, projects and their to-dos, notes, plan bars, calendar items, timeline entries and mindmap nodes, notebook entries, saved highlights, bookmarked messages, memory items, your persona, your guidelines, your libraries and their items, your knowledge bases and uploaded documents (including the files on disk), generated files, support tickets and the messages inside them, upgrade requests, your API keys, your usage window, your golden-credit ledger, your invoice and subscription rows, and the product-analytics event log rows belonging to you. Any live Stripe subscription is cancelled first, before anything is erased, so a deleted account can’t keep being billed — and if that cancellation fails, the deletion is refused rather than leaving you paying for an account you can no longer log into.

Three things survive, not two. This page used to name two and describe the third — the receipt — as holding less than it does. Here is all of it.

1. The raw notifications Stripe sent us about payments on the account, kept as a payment audit trail. The link to your account is cut, but the payload Stripe put inside is left exactly as Stripe wrote it — and a Stripe payload can name the customer, including the email address used to pay. We re-checked this by reading the surviving row after a test deletion: the address was still in it. This is the one survivor that can still contain a personal detail, so we say it in as many words rather than calling it “anonymised”. Legal basis: GDPR Art. 17(3)(b) (a legal obligation to keep payment records) and Art. 17(3)(e) (the establishment or defence of legal claims).
2. Per-request usage records — one row per AI reply, used for cost-of-goods accounting. These are emptied out, not merely unhooked: the account, the project, the session id and the attached metadata blob are all cleared. What is left is the provider and model name, the token counts, our cost, an internal metering id and the date — “N tokens on model X cost $Y on day Z”, which names nobody. No message text was ever in them. Legal basis: GDPR Art. 17(3)(b) for the accounting obligation; once stripped, the residue is no longer personal data.
3. One deletion receipt, described in full immediately below.

The deletion receipt, field by field

This page used to say the receipt records “that an account was deleted and when, a fingerprint of the email address, the Stripe customer id, and a count of how many rows were removed from each table”, and that “it contains none of your content.” That was wrong in two places, and both are on the receipt of every deletion we have ever run. Here is everything it holds:

• The date and time of the erasure, and whether you ran it or support ran it for you.
• A SHA-256 fingerprint of your email address — not the address. Someone who already knows the address can recompute the fingerprint and confirm we deleted the account; the fingerprint cannot be turned back into an address.
• The account’s short public identifier — the id the app used in URLs. It no longer resolves to anything.
• The Stripe customer id, if the account ever paid, and the Stripe subscription ids we tried to cancel together with whether each cancellation succeeded. That is how a “you are still charging me” question can be answered after the account is gone.
• Whatever you typed in the “why are you leaving” box — verbatim, up to 500 characters. This is the first of the two things the page got wrong: the receipt does hold content you wrote, when you choose to write any. It is optional, so leaving the box empty keeps it off the receipt entirely. We keep it as product feedback under legitimate interests, not under any legal obligation — so if you want it struck after the fact, ask support and it is struck.
• Per-table counts of what was removed, what had to be removed by hand, what was stripped rather than removed, and how many files were unlinked. Numbers only.
• Your billing history in detail — not as counts. This is the second thing the page got wrong. It said invoice totals “survive only as counts on that receipt”. They do not. Before the invoice and subscription rows are deleted, each one is copied onto the receipt in full: per invoice, the Stripe invoice id, the amount paid, the payment status, the description of what was bought and the issue date; per subscription, the Stripe subscription id, the plan name, the status and the start and end dates; and from the credit ledger, a count of all entries plus every purchase entry (amount, credits bought, the reason line and the timestamp, up to the first 500). Grant and spend entries — the ones that are not records of a sale — are counted and copied nowhere.
• A count of anything the erasure failed to remove. Empty on a clean deletion, and permanently non-empty if one ever isn’t, which is the whole point of writing it down.

Why the financial detail is kept: an invoice is proof of a completed sale, and tax and accounting law require a seller to keep proof of what was sold, for how much and when — typically six to ten years depending on the jurisdiction. GDPR Art. 17(3)(b) exempts exactly this: erasure does not apply where processing is necessary to comply with a legal obligation. The subscription copy is what makes an invoice explicable (“this $50 was Gold, monthly, from this date”); without it the retained invoice is an unattributable number. The purchase entries are the only record that could adjudicate a refund request after the fact, and our published refund policy would be unevaluable without them (Art. 17(3)(b), and Art. 17(3)(e) for legal claims). Stripe holds the authoritative copy of all of it regardless of what we do, under Stripe’s own retention policy, which we cannot delete on your behalf — that is what the carve-out in our Terms refers to.

The receipt contains none of your chats, messages, notes, highlights, memory or files. What it does contain that came from you is the optional leaving note, and the description lines on your own invoices.

One correction that runs the other way: the product-analytics event log is no longer a survivor. It used to be, and it is now erased with the account.

The same list is machine-readable, so you can check it rather than take our word for it. It ships inside every data export (under retained_after_deletion and deletion_receipt_contents) and it is shown on the confirmation screen before you delete anything.

Ordinary server logs age out on the normal rotation of the machine they’re on rather than on an account’s timetable. They are not part of the erasure above.

Your rights and controls

• View and delete individual AI memory items, any time, in the app — and switch memory off entirely in the extension’s settings.
• Delete your own chats, notes, projects, to-dos, notebook entries, highlights, mindmap nodes and guidelines yourself, in the app.
• Purge stored screenshots in one action — Settings in the web app, or the extension’s own settings — for a single chat or for every chat at once. This is a deliberate button rather than a side effect of flipping the screenshot toggle off, because deleting part of a transcript you can still see shouldn’t happen behind your back.
• Erase your account entirely, yourself. The button is live: web app → Settings → Your data → Delete my account. It shows you the real per-table counts of what is about to go before you confirm, and it lists what will survive — the same three things written out above. It cancels any live Stripe subscription first, so deleting can’t leave you being billed, and if that cancellation fails it refuses to proceed rather than erasing an account that would keep being charged. Support can run it for you instead; it is the same code path and the same outcome.
• Download everything you’ve written — chats and messages, projects, notes, notebook, highlights, memory and the rest, as one JSON file. Also live, in the same place: Settings → Your data → Download everything. The file documents itself: it carries a plain-words description of every table in it, a complete list of what it deliberately leaves out and why, and the field-by-field contents of the deletion receipt, so you can check the section above against the software rather than against this page.
• GDPR- and CCPA-style rights — access, correction, deletion, portability — are available to anyone on request, not only residents of those regions.

Cookies, and what lives in your browser

No cookies from us — but browser storage holds more than a token.

StickyFriend sets no cookies on you. Not for sign-in, not for preferences, not for tracking — we checked the responses, and our API returns no Set-Cookie header at all. What keeps you signed in is your browser’s own local storage, and both halves of the product use it for a good deal more than a session token. Here is everything that is written there.

One honest footnote so this isn’t an absolute we can’t defend: the staff-only Django admin console on our server does set a CSRF cookie on its own login page, as that framework does by default. It is not part of the website, the web app or the extension, no customer surface links to it, and nothing you do as a user goes near it.

The web app (localStorage on stickyfriend.ai)

• Your session — the sign-in token, your API key, and the profile that came back with them: email, name, username and avatar URL.
• Your chat list — the id, title, project and last-updated time of each of your chats. Worth knowing: a chat’s default title is taken from the first thing you said in it, so those titles are your own words.
• Per-chat context counts — how many tokens each chat’s last turn used, which is what draws the context bar.
• Your AI’s persona — its name, avatar, colour and theme, and the prompt text you wrote for it, cached so the app can render it before the server answers.
• Preferences — light/dark theme, answer tone, language, the server address the app talks to, and the context-window size the meter is drawn against.
• Offline chat transcripts — this is the big one. If our server can’t be reached, the app falls back to a local chat and writes the actual text of that conversation — your messages and the replies — into local storage, so the tab still has its contents after a reload. Normal, server-backed chats are never written there, and disposable chats are never written anywhere at all.

Signing out empties the session record and deletes the chat list, the context counts, the persona and every offline transcript.

The Chrome extension (chrome.storage)

• Your session and connection — sign-in token, API key, your profile, the server address, and your language.
• Your settings — theme, light/dark mode, whether the AI may record memories, auto vs manual recaps, answer tone, and the screenshots-in-the-cloud switch.
• Your AI’s persona, cached the same way the web app caches it.
• An outbox — up to 500 messages that couldn’t reach our server yet, with their text, so a dropped connection doesn’t lose what you said. Each one is deleted from the outbox the moment it’s delivered. Note the cap is a real cap: if a 501st message queues up, the oldest one waiting is dropped to make room, and that message is then lost rather than merely delayed.
• Bookmark folder ids — which Chrome bookmark folder belongs to which project. The extension also creates real folders in your Chrome bookmarks under a parent called “StickyFriend”; those are ordinary bookmarks in your own browser, not something we hold.
• Until you close Chrome only: which browser window a project opened into, and the text of a right-click prompt while it’s on its way to the side panel.

Other people’s requests from these pages

Two third-party requests exist and you should know about them, because a request is enough to reveal your IP address: the sign-in screen loads Google’s Sign-In script from accounts.google.com, and this website’s pages load their typefaces from Google Fonts. Google can set cookies on its own domains when you interact with its sign-in. That’s the entire list — there is no analytics tag, no ad pixel and no tracker of any kind in StickyFriend, and we do not sell your data to anyone.

Children

StickyFriend is not directed at children. See our Terms for the minimum age to hold an account; we don’t knowingly collect data from anyone below it.

Changes to this policy

This policy is effective 25 July 2026. If it changes, the “last updated” date above changes with it, and anything material gets a note in the changelog.

Questions

Who we are: StickyFriend is operated by iSamurai L.L.C., a Delaware (USA) limited liability company — the data controller for the personal data described in this policy.

Support is in the app. Open Support and start a ticket — it’s a real thread, not a mailto: link, so replies land in the same place. You can also reach us at support@stickyfriend.ai.