What leaves your machine, and what does not.

The program on your computer

• Your notes stay on your disk. The vault is a folder of Markdown files. There is no background sync, no cloud copy and no account required to use it. If you later pair your own machines, what travels does so sealed, at your command — the relay section below says exactly what that means.
• No telemetry. Nothing reports your usage, your file names, your errors or the fact that you launched it. The command-line program talks to exactly two kinds of server, both at your own command: the model provider you connected it to, and our account and billing server at api.ferrow.ai when you run the account commands yourself — activate, subscribe, billing and their kin. Those calls carry what Surfaces 3 and 4 describe and nothing more: never a note, a file name or a provider key. Working with your vault makes no network call at all.
• Your provider keys stay on your machine, in the safest place it has. On a Mac that is the Keychain. Windows and most Linux systems have no keychain, so the key goes in a file in your Ferrow folder instead. On Linux that file is locked to your account, so no other user on the machine can open it. Windows works differently: the file is protected by the permissions Windows puts on your own user folder, which keep other accounts out — but only while the folder stays there. If you point Ferrow at a folder outside your user folder (a second drive, a shared or synced folder), anyone else with an account on that PC can read the file. Wherever the key lives, it goes to that provider's API and nowhere else. It is never sent to us.
• The local browser UI is local. ferrow ui binds to 127.0.0.1, so nothing off your machine can reach it, and its API needs a token minted at boot and destroyed when you stop it. Said honestly: any program running as you on that machine can read that token. It stops a website you are visiting from reaching your vault over localhost; it is not a defence against software you have already installed.

This website

These pages are static files. They set no cookies, load nothing from anyone else's server — no fonts from a CDN, no analytics, no tag manager, no embedded video — and make no network request of their own. The headers this site is served with pin that: default-src 'self', connect-src 'self', and a test in the repository fails if any file in site/ so much as contains the code for making a network request.

Cloudflare serves the pages and, like any host, sees the request itself — the address you asked for, your IP and your browser's user-agent — as part of delivering it. We do not join that to anything, and there is no account or profile on this site for it to be joined to.

Your Ferrow account

An account exists so a purchase can find you again on a new machine. It is deliberately thin. The record holds:

• Your email address, lower-cased.
• A one-way derivation of your password — PBKDF2-HMAC-SHA256 over a random per-account salt, 100,000 iterations (the most our host will compute; the count is stored on the record so it can rise the day that ceiling moves), stored as salt, iteration count and hash. The password itself is never written down, and nothing stored can be turned back into it.
• An account id we generate — a random string, not derived from anything about you.
• Whether the address has been verified — one true-or-false, set when you follow the link in the verification email.
• Which plan you are on: your Stripe subscription id and customer id when you have bought something, and the key your purchase minted.
• The date the account was made.

That is the account record itself. There is no name field, no address, no phone number, no company and no profile. Sign-in also fails identically for an unknown email and a wrong password — same words, same timing — so the account system will not tell a stranger whether you have an account.

Running a paid product needs a few more records than the account itself, and it is not honest to leave them off a page called "what we keep". Here they all are:

• Lookups that point back to your account — your email against your account id, your email against your subscription, and your subscription against your email. They exist so a purchase made at a checkout can be matched to a login made later. Kept as long as the account is.
• Your subscription's state — plan, status, edition, spend cap, the period dates, and whether a cancel is pending — plus the product key it minted and any agent credentials you have created. Kept as long as the record is.
• Checkout session pointers, so the page you land on after paying can find the purchase you just made; and, for a prepaid usage pack bought before there was an account to credit, the parked credit until an account claims it.
• Password-reset and email-verification tokens — stored as one-way digests, never the token itself, and they expire on their own within hours.
• Rate-limit counters, so a stranger cannot grind at your password or flood the checkout. They are a count against an IP address and, on sign-in, the email being tried. They expire in fifteen minutes (five for checkout, ten for bug reports).
• A note that a given letter was sent, so you never get the same trial reminder twice. It is the kind of letter and the id it was about, and it expires after a year. The onboarding queue holds an email address and a due date and expires in thirty days.
• Bug reports you send us — what you wrote, a rating, the platform, the email address you gave if you gave one, the page URL, app version, OS version and browser user-agent, and the screenshot if you attached one. These have no expiry: they are kept until we delete them. Do not put anything in a bug report you would not want us reading, and if you want one removed, ask.
• Counts, with nobody in them — how many people reached a page or finished a signup on a given day. Integers, not rows about people.

The web client keeps your session in your browser's own storage so you are not signed out on every reload. That is the browser's storage on your device, not a cookie sent to us.

If you forget your password, self-serve reset is built in. The reset request sends your email address and nothing else; the confirm step sends the one-use token from the reset email. The server answers the request identically whether or not the address has an account, so the reset flow cannot be used to probe who is registered. Still stuck? Email support@ferrow.ai — a person will sort it out.

Paying

Stripe handles cards. Checkout happens on Stripe's own pages, under Stripe's privacy policy. Your card number, its expiry and its security code are entered there and never reach Ferrow — we could not show them to you if you asked.

What our billing worker receives from Stripe is the part it needs to know you paid: a checkout session id, a subscription or payment id, the plan, and the email address you used. It never receives a vault, a note, a file name or a provider key, because none of those are anywhere near that path.

Managed model calls, and the hub relay

These are the two places where content — not just metadata — passes through a server, so they get their own section.

Managed

On Managed, Ferrow makes the model call for you. That means the text of the request goes through Ferrow's worker to the model provider it is routed to, and the model's answer comes back the same way. Alongside it, the meter records what a call costs so your spend cap can be a hard stop rather than a guess: the model, the token counts the provider reported, the cost, and a request id. A completed answer is held against that request id for about twenty-four hours so that a retry of the same request replays it instead of calling — and charging — the provider twice. That is a real copy of a real answer, sitting on our side for a day, and it is the one thing on Managed that we hold rather than pass through.

On Private, none of this applies: your own key calls your own provider directly from your machine, and Ferrow's servers are not in the path at all.

The hub relay

If you pair a phone or a browser to the machine running ferrow hub, a Ferrow relay passes messages between your own devices. What crosses it is sealed by the devices at each end — the relay carries blobs it cannot read. It does not carry your vault, your notes or your keys, and those stay on the machine running the hub.

Nothing crossing the relay is written to disk. A bounded window of the most recent sealed frames is held in memory so that a device which drops its connection can reconnect without a gap; they are still blobs the relay cannot read, and they fall out of that window as new ones arrive.

Our own YouTube channel, and YouTube API Services

Ferrow uses YouTube API Services. Alongside the product, Ruzylo Holdings runs a small pipeline that puts Ferrow's own videos on FerrowAI, the YouTube channel we own. The Google application behind it is named Ferrow, and everything it does is described here: Google requires that disclosure, and it belongs on this page anyway.

What it touches. Three permissions, all on our own channel: youtube.upload, to put a finished video file on the FerrowAI channel; youtube.readonly, to read that same channel's own listing so we know what landed; and yt-analytics.readonly, to read that same channel's own performance figures so we know how it did. Uploads go up private while Google's verification of the application is pending. It does not read, request, or store any other person's YouTube data — there is no sign-in with Google anywhere in Ferrow, so no visitor's or customer's YouTube account is ever involved.

What we store. One credential: our own Google authorization token for our own channel, held in the keychain of the machine that runs the pipeline so it can keep publishing without a person re-approving each run. The videos and titles are ours to begin with. Channel figures are read for the run that fetched them and are not kept as a record about anybody. Nothing obtained through YouTube API Services is sold, shared with anyone else, or used to train a model.

Data we access. In raw form: the video ids, titles, descriptions and privacy status of videos on the FerrowAI channel, returned by the YouTube Data API when the pipeline lists that channel after an upload; and aggregated, non-identifying daily figures for that same channel — views, watch time, average view duration — returned by the YouTube Analytics API. That is the complete list. We do not access viewer identities, comments, subscriber lists, messages, contacts, or any data belonging to any Google account other than the FerrowAI brand account we own and operate.

How we use it. The raw listing data is used for exactly one user-facing purpose: confirming that a video we uploaded actually landed, and reconciling it against our local publishing ledger so the pipeline does not publish the same video twice. The aggregated analytics figures are used to decide which of our own videos to publish next; they are read by our own deterministic scheduling logic and are never used for advertising, profiling, credit or lending decisions, or resale. No Google user data is used for any purpose other than providing and improving these publishing features.

What we transfer, and to whom. Nothing. Data received from YouTube API Services stays on the machine that runs the pipeline. We do not transfer, sell, or otherwise disclose it to any third party — not to data brokers, not to advertisers, not to analytics vendors, and not to any third-party AI or machine-learning service. The only exception is disclosure compelled by law, which we would narrow as far as the law allows.

How we protect it. The OAuth token is stored in the operating system keychain of a single machine under our control, never in source code, never in our git history, and never in any file we publish; the repository's ignore rules and file permissions are set so a credential cannot be committed by accident. All calls to Google are made over TLS. Access to that machine is limited to the channel's owner. The application is a single-tenant desktop tool: there is no multi-user server holding Google user data, and no sign-in with Google anywhere in the Ferrow product, so no customer or visitor account is ever involved.

How long we keep it, and how it is deleted. The authorization token is kept only while the pipeline is in use, and is destroyed when it is revoked or when the channel stops publishing — revoking our access at the Google security settings page linked below invalidates it immediately. Video listing data is held only for the duration of the run that fetched it and is discarded when that run ends. Aggregated analytics figures — counts and averages for our own videos, containing no information about any person — are appended to a local ledger on that same machine so a new video can be compared against earlier ones; that ledger is kept while the channel is operating and is deleted when it is no longer needed or on request. Anyone may email support@ferrow.ai to ask what we hold or to have it deleted, and we will act on the request.

Limited Use. Ferrow's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

AI and machine learning. We do not use raw or aggregated data received from Google APIs to develop, improve, or train any generalized or non-personalized AI or machine-learning model, and we do not transfer that data to any third-party service that would use it to train its models. Ferrow does use AI services to generate the video content we publish, but those services are given only our own source material — scripts, audio and images we created — and are never given data returned by Google APIs.

The terms, and the controls. Using YouTube API Services binds this pipeline to the YouTube Terms of Service, and Google's own handling of data is governed by the Google Privacy Policy. The access this application holds — and any access you have granted to any application — can be reviewed and revoked at any time from the Google security settings page. To ask what we hold or to have it deleted, email support@ferrow.ai and a person will answer.

Things we do not do

• We do not sell or rent your data, and there is no advertising anywhere in Ferrow.
• We do not read your vault. We do not have it.
• We do not train models on your content. Ferrow trains no models at all — it routes to providers you choose, whose own terms govern what they do, and those are worth reading for the provider you pick.
• We do not track you across the web, and there is no third-party script on this site to do it with.

Getting a copy, or getting rid of it

The name behind all of this is Christopher Ruzylo, doing business as Ruzylo Holdings, in the United States — the same name on your receipt, and the one responsible for everything described on this page.

Email support@ferrow.ai from the address on the account and ask for either. A copy is small — it is the record described in Surface 3 plus your purchase history.

Deletion is done by a person, by hand, against a written procedure, and we aim to finish it within thirty days of your asking. It removes your account record and both of its lookups, your subscription record, your product key and every agent credential minted from it, any prepaid pack parked against your address, the queued and already-sent letter markers, and any bug report we can attribute to you — screenshot included. If a subscription is still running we cancel it first, and if there is prepaid credit left we tell you before we delete it rather than after.

Two things survive it, and it is better to say so than to imply otherwise. Stripe keeps its own record of payments that actually happened, because payment and tax law require it; that is Stripe's record as much as ours and we cannot delete it. And the spend counters for a Managed account live in a store that has no delete button — they are orphaned rather than erased the moment the key that names them is gone, and the only copy of anything you wrote in that store falls out of it within about twenty-four hours anyway.

Deleting your account does nothing to your vault, because it was never ours to delete. It is a folder on your disk and it stays exactly where it is.

If we ever change how any of this works, the date at the bottom of this page changes with it.