Privacy

The short version

Vigil does not use advertising cookies, does not build profiles of readers, and does not sell or share data with advertisers. Reading Vigil requires no account and no personal information of any kind. Every conflict module, brief, Note, record, map, Watch question and search on this site is open to a reader who has never identified themselves, sets no cookie, and stores nothing in your browser. The one place Vigil asks for something is the newsletter, and it asks for an email address and nothing else.

There is now one part of Vigil that does involve an account — a Vigil Professional subscription — and it is described in its own section below. It is separate by construction: an account exists only if you create one, and nothing about the paragraph above changes for anyone who does not.

Vigil Dispatch — the newsletter

What is collected

Your email address. That is the whole subscriber record. Vigil does not ask for your name, your country, your employer, your job title, your age, your interests or which conflicts you follow, and there is nowhere in the signup form to provide them. There is one list, so there is nothing to segment you into.

Vigil does not send the newsletter provider your IP address, the page you subscribed from, or anything about what you have read. Those fields exist in the provider's interface and are deliberately left empty — the signup request carries the address alone.

Why

To send you Weekly Briefs, to send you significant Analytical Notes, and to manage your subscription status — confirming it, and ending it when you ask. It is not used for anything else.

Who processes it

Email delivery and subscription management are handled through Buttondown, a newsletter provider. Your address is stored there so that it can be sent to, and so that an unsubscribe can be honoured. Buttondown publishes its own privacy policy and terms; this page describes only what Vigil does and what Vigil sends.

Confirmation is required

Subscribing uses double opt-in. Submitting the form does not subscribe you: it sends one email asking you to confirm, and until you click the link in it you receive nothing further. If you did not ask to subscribe, ignoring that email is enough — no further mail follows it.

Unsubscribing

Every edition carries an unsubscribe link, and your mail client's own unsubscribe button works too. Unsubscribing takes effect without needing to give a reason, and you will not be asked to confirm it.

How long it is kept

Vigil has not set a fixed retention period, and states that rather than inventing one. Your address is held while your subscription is active. After you unsubscribe, the provider retains a record for the purpose of not mailing you again — a suppression record is how an unsubscribe is honoured, and deleting it entirely would make a later re-import able to undo your choice. To have your record removed altogether, write to the address below and it will be deleted through the provider's own deletion mechanism.

Tracking in the emails

Open tracking is off and click tracking is off. Vigil's editions contain no tracking pixel, so Vigil cannot tell whether you opened one, and links in them are ordinary links to Vigil pages rather than redirects through a tracking domain. The provider defaults both to off and Vigil leaves them off.

Links from an edition do carry campaign tags — see below. Those describe the link, not you.

Vigil Professional accounts

Everything above describes Vigil as read by someone with no account, which is how Vigil is read by default and how the public corpus is meant to be used. This section describes the one part of Vigil that involves personal data: a Vigil Professional subscription, and the account it runs on.

It applies only if you create an account. An account exists because you asked for a sign-in link; it is never created by reading, by visiting a page, or by anything Vigil does on its own.

What is held

The complete list for the account itself. The Professional tools add one further family of rows, your saved work, listed in its own section below; there is no other table and no other field:

• Your email address, lowercased and trimmed. It is the account — there is no name, no organisation, no job title and nowhere to enter one.
• An internal account identifier, a random value Vigil generates. It is what PayPal is told about instead of your address.
• When the account was created, and when it was first seen.
• Sign-in tokens, hashed. The link emailed to you is never stored: what is kept is a SHA-256 hash of it, with the address it was for, when it was issued, when it expires and whether it has been used.
• Session tokens, hashed. Same rule — the value in your cookie is not in the database. The row holds the hash, the account it belongs to, when it was created, when it expires and when it was last used.
• Subscription records, if you subscribe: the PayPal subscription identifier, the plan, its status, the date access runs to, and the timestamps Vigil uses to keep its copy in step with PayPal's.
• A log of PayPal's notifications: PayPal's event identifier, the event type, the subscription it concerned, and what Vigil did with it. This is what makes billing auditable after the fact.

What is not held, in any of those tables: no name, no postal address, no card number or payment credential of any kind, no IP address as a stored field, no user agent, no referrer, no analytics identifier, no record of which pages you read, and no profile. Vigil does not know what a signed-in reader has looked at, because nothing writes it down.

Your saved work, if you use the Professional tools

The Professional tools let a subscriber follow a Watch question, an observable, a Tempo series or a Standing Watch scope; gather records into a named collection; save a query, a comparison, a Tempo view, a scenario run or a timeline; keep brief drafts; and attach a private note to a record. Each of those is one row in a saved-work table, and the complete list of what a row holds is:

• What kind of item it is — one of: follow, collection, query, comparison, tempo, scenario, brief, timeline, note, monitor.
• A reference to the Vigil record it concerns, as an identifier such as watch:iran-gulf/hormuz-commercial-access. The record itself is never copied into your row; if Vigil corrects the record, your saved reference shows the corrected record.
• A title you gave it, if any.
• Your own parameters and text — the filters of a saved query, the options of a scenario run, the ordered list of references in a collection and the note you wrote on it, the rows you removed from a timeline and the notes you attached to the rows you kept, the order of the blocks in a brief draft and the annotations you wrote on them, the text of a private note. These are lists of references and your own words; no Vigil record is copied into them, and Vigil does not read them to change anything it publishes.
• When the row was created and last changed.

One further row per subscriber holds three surface preferences: which brief draft is the active one, when you last opened the My Vigil page (so the page can mark what changed since), and whether you have asked for reviewed changes by email. Nothing else is recorded — not which pages you read, not which records you opened, not what you searched for unless you chose to save the search.

Saved work is private to your account, is never shared with another account, and is never an input to any Vigil assessment. You can delete any item from the Library page at any time. Deleting your account deletes every saved-work row and the preferences row in the same operationthat removes your email address.

Reviewed-change email, if you turn it on

A subscriber can ask to be emailed when something they follow is reviewed by Vigil and materially changes, or gains new evidence. It is off unless you turn it on: following a record puts it on your desk and does not enrol you in anything. The setting is the third surface preference described above, and you can change it at any time on your account page.

Turning it on means Vigil records one row for each change that has been emailed to you, so that a repeated send cannot deliver the same review twice. The complete list of what such a row holds is:

• An identifier for the reviewed change, built from the Vigil record, the date it was reviewed and what the review found — for example watch:iran-gulf/hormuz-commercial-access@2026-09-13#assessment-changed. It names a published Vigil record and a public review; it says nothing about you.
• Your account identifier — not your email address, which is read from your account at the moment a message is sent and is never copied into these rows.
• That the channel was email, and when it was sent.

Nothing about the contents of a message is stored, and Vigil does not record whether you opened one: the emails carry no tracking pixel and no click tracking, exactly as the sign-in email does not. Deleting your account deletes these rows in the same operation that removes your email address and your saved work.

If you never turn email on, no row is ever created — the reviewed changes shown on your desk are worked out in your own browser from records you already have access to, and are not recorded anywhere.

Nor does Vigil hold preferences it has not built. There are no team or organisation records today — those features do not exist, so there is nothing about them to store. If they are built, this section gains the fields they need before they ship.

There is no password

Signing in sends a single-use link that expires in 15 minutes. Vigil holds no password, because none exists — there is no password column in the database and there is not going to be one, so there is nothing to leak, reuse or reset.

The sign-in link and the session cookie are never stored as written. Both are held only as one-way hashes, which is enough to recognise a value you present and not enough to reconstruct it. A used or expired sign-in link stops working immediately. Signing out deletes the session row outright, so the cookie you were holding stops being anything at all.

The one cookie

A signed-in account uses one cookie, and it is set only after you sign in. It holds a random session value and nothing else — no address, no identifier, no state. It is marked Secure, HttpOnly and SameSite=Lax, it lasts 30 days from last use, and it is removed when you sign out.

A reader without an account receives no cookie at all, exactly as before. There is no consent banner on this site and this section does not introduce one: the only cookie Vigil sets is the one strictly necessary to keep you signed in, and it is set because you asked to sign in.

One thing is remembered in your browser without an account: if you choose a billing currency on the Professional pages, that choice — USD or EUR, and nothing else — is kept in your browser's local storage so the pages stay consistent. It is written only when you press the control, it is not a cookie and is not sent with any request, and clearing this site's data in your browser removes it. The currency reaches Vigil only when you start a checkout in it.

Who else is involved

• Cloudflare hosts the site and stores the account database, which is located in the European Union.
• Resend sends the sign-in email. It is sent your address and the link, and nothing else — no tags, no metadata, and neither open tracking nor click tracking, which are switched off deliberately.
• PayPal processes the subscription. Vigil sends it your email address, so the checkout is pre-filled, and the internal account identifier above so that later notifications can be matched to the right account. PayPal returns a subscription identifier, its status and the billing dates. Vigil never receives your card details, and no payment form exists on this site.

PayPal holds its own record of the payment, under its own terms, and that record is not Vigil's to delete.

One detail worth stating because Vigil chose it: the sign-in and checkout endpoints read the connecting IP address to apply a rate limit, hold a shortened one-way hash of it in memory for a few minutes, and write it nowhere. It is not stored, not logged and not sent to anyone.

How long it is kept, and how to have it removed

Sessions expire 30 days after they were last used, and signing out deletes one immediately. Sign-in tokens expire after 15 minutes and cannot be used twice. Vigil does not yet delete the expired rows on a schedule — they are dead values that authorise nothing, but they are still rows, and saying so is better than implying a sweep that is not written.

Account and subscription records are kept while the account exists. Vigil has not set a fixed retention period beyond that and states it rather than inventing one.

You can delete the account yourself, from your account page. It takes two presses and no correspondence. Deleting removes your email address from Vigil, deletes any outstanding sign-in links for it, and ends every session you have — so the account can no longer be signed in to, on any device.

What remains is the record that a subscription was paid: the PayPal subscription identifier, its status and its dates, together with the log of PayPal's notifications about it. Those rows carry no address — they are attached only to the random internal identifier described above, which was never derived from your email. They are kept because they are the evidence that a payment happened, which is the one thing a deletion should not destroy. The row that used to hold your address keeps a placeholder built from that same random identifier, so the original address cannot be recovered or recognised from it.

Cancelling a subscription and deleting an account are different things, and Vigil does neither on your behalf. Cancelling is done at PayPal and leaves the account in place; deleting the account does not cancel anything at PayPal. For that reason an account cannot be deleted while Professional access is still running — cancel first, let the period you have paid for finish, then delete — which prevents the one genuinely bad outcome: PayPal continuing to bill a subscription whose Vigil account no longer exists.

If anything about this does not work, or you want something checked, write to [email protected].

Everything Vigil holds about an account is listed above, so the answer to "what do you have about me" is on this page rather than behind a request. The address on the account is visible to you at any time on the same page.

What a subscription does not change

An account is used to sign you in and to decide whether a subscription is active. It is not used for anything else: not for advertising, not for profiling, not for analytics, and not to change what Vigil publishes or how it is assessed. The Vigil Professional terms state the same thing as a commitment rather than as a data fact.

Campaign attribution

When Vigil publishes a link somewhere — a YouTube Short, a post on X, an edition of the newsletter — that link carries campaign tags, and opening it records five fields:

• source — the channel the link was published on
• medium — the kind of publication it was
• campaign — which piece of Vigil content it was promoting
• content — optional, which of several links it was
• landing path — the Vigil page the link opened

A timestamp is added by the storage layer. That is the entire record, and it describes a link, not a reader.

What is not recorded, at any layer: no cookie, no browser storage of any kind, no visitor identifier, no session identifier, no fingerprint, no advertising identifier, no IP address as a stored field, no referrer, no user agent, no country, no full URL, and no name, email or account. There is nothing in the record that could be joined to a person, and nothing stored elsewhere to join it to. The tags are also removed from the address bar after the page loads, so a URL you copy and share is the clean one.

This is described in full, including the code that implements it, in Vigil's own attribution documentation. The two files are src/lib/attribution.ts and functions/api/campaign.ts.

Site analytics

Vigil uses Cloudflare Web Analytics for overall site usage — how many visits pages receive, and coarse aggregates such as path, referring host, country, device type, browser and operating system. It sets no cookies and does not follow visitors between sites.

It is configured to exclude visitor data in the EU: for visitors geolocated in the European Union, Cloudflare does not inject its measurement script at all, and those visits are not counted. This is a deliberate setting, and it means Vigil's own visit figures structurally undercount European readers.

Hosting

The site is served by Cloudflare Pages. As with any web server, requests reach Cloudflare's network and are handled there; Cloudflare's own processing is covered by its documentation, not by this page.

One detail worth stating because Vigil chose it: the subscription endpoint reads the connecting IP address to apply a rate limit, holds a shortened one-way hash of it in memory for a few minutes, and writes it nowhere. It is not stored, not logged, and not sent to the newsletter provider.

What Vigil does not do

• No advertising, and no advertising or analytics cookies.
• No selling, renting or sharing of reader data.
• No cross-site tracking and no third-party trackers embedded in pages.
• No profiles of individual readers, and no attempt to build one.
• Nothing that requires you to identify yourself to read. An account exists only for a Vigil Professional subscription, is created only when you ask for one, and is never needed to read anything Vigil publishes publicly.
• No advertising, profiling or analytics use of an account, and no record of what a signed-in reader has read.

Contact

Questions about anything on this page, or a request to delete a subscriber record, or a request to delete a Vigil Professional account: [email protected].

This notice describes what the software does. It is informational, and it is not a legal determination about which regulations apply to Vigil or to you.