Privacy
What this site stores.
Last changed 2026-09-21. This applies to app.phaeacia.ai only. The company site at phaeacia.ai has its own notice and this one does not describe it. Below is the whole of it, in the order that matters.
What is collected when you read a page
Reading sets no cookie, first party or third. Voting is the only thing that sets one; its later transmission with ordinary requests is described under Voting below. No analytics product runs on any page: no tag manager, no advertising pixel, no session recorder, no heatmap, no experiment framework. Our application does not keep a history of the pages you open or how long you stay. The passport and setup-copy counters below record totals without identifying readers.
Our server does count page requests. For each page it serves, it records the date, the page's path and the host name of the site the link came from, if any, and nothing else: no IP address, no browser signature, no cookie and no identifier of any kind, so two requests from you look the same as one request each from two people. A passport page is recorded as "a passport page", never by its link. A request that carries the Do Not Track or Global Privacy Control signal is not counted at all. The counts live in our hosting account at Netlify, a morning report reads them, and raw entries are deleted after 45 days.
Nothing loads from another domain either. Both typefaces are served from this site, as is every script, stylesheet and image, and there are no embeds. While one of these pages is open, your browser is talking to this site and to nowhere else, unless you follow the optional feedback link, which opens a form hosted by Notion in a new tab.
Opening somebody's passport link adds one to a counter on that passport, so the person who published it can see it was read. It records no time, no address, no browser and no referrer.
When the copy control on a passport page succeeds, the page asks us to add one to a second counter on that passport. This count can miss copies if the request does not reach us or is refused, and it does not tell us whether you installed the agent. Nothing about you is stored with the counter. Copies made by selecting the text yourself are not counted.
The buttons that copy text for you elsewhere on this site work the same way: a successful copy adds one to a count of these copies, and nothing about you is stored with it. A counting request that never reaches us, or is refused, means the copy is not counted, and a copy made by selecting the text yourself is not counted either.
Your theme choice is kept in your browser, and only if you use the theme control in the header. It is not a cookie, it is not sent with any request, and clearing your site data removes it. The one cookie this site sets is described under Voting below, and reading never sets it.
Voting, and the one cookie
A passport listed in the gallery can be voted up or down. Voting is the only action that sets a cookie, named pv. A vote attempt can set it even if the vote cannot be recorded. It holds a random identifier generated here and a signature proving this site issued it, and nothing else. It is not derived from you, your file or your network, and it is the only cookie this site sets. After it is set, your browser also sends it with ordinary requests for pages, images and other files on app.phaeacia.ai. Our application reads it only when you submit a vote; it does not read it on an ordinary page load. Copy-count requests do not send it.
It is marked HttpOnly, so no script on any page can read it, and is set to last a year unless your browser clears it sooner. Your votes are stored against that random identifier and the passport listing you voted on. This limits one browser to one vote on each listing. Clearing the cookie lets you vote again, and we would rather say that than pretend one vote per person is something this design can deliver.
When a passport is deleted or unlisted, its former votes stop counting immediately. A passport listed a second time starts from zero. We also delete the former vote records; any records left by incomplete cleanup are retried later. Your identifier is used only for voting: there is no account to attach it to and nothing else in our application reads it.
What publishing a passport stores
There is no sign-up and no login anywhere on this site. Publishing a passport, opening somebody's link, copying an install block and deleting a passport all work without an account and without an email address.
Publishing stores the following, and nothing else:
- The text of the passport you uploaded, as you sent it, so it can be rendered at its link. The step before the upload button says plainly that publishing puts it on a public web page.
- A random identifier, the long unguessable part of the link. It is generated here and is not derived from you, from your file, or from your network.
- A hash of the delete token. The token itself is shown to you once and never stored, which is why nobody, ourselves included, can reissue it for you.
- One integer counting views, kept apart from the passport itself so that a page still loading while somebody deletes their passport cannot write it back.
- One integer counting copies, kept the same way, counting successful uses of the copy control whose counting requests we receive and accept.
- Whether it is listed in the gallery, and if it is, which of the eight categories you picked and the date you listed it. Both are shown publicly on the gallery card. A random identifier distinguishes this listing from earlier listings of the same passport and is stored with its votes and any category changes too. It identifies the listing, not a visitor.
- Two counts of votes, up and down, for a listed passport, and the time those counts were last updated. The counts are shown on the card and on the passport page. Who voted is covered under Voting above.
- Two dates and a small number: when it was published, when it expires, and how many times it has been renewed.
- A one-way hash of the file, for one hour, so the site notices the same passport being uploaded twice by accident and hands back the link you already have.
- A short record of the passport's shape, described in the next section.
Nothing is attached to any of that about who published it: no author, no organisation, no session and no upload address. A passport is not associated with a person, because the system never learns which person it was.
The record of what was published
Publishing writes one short record describing the shape of the passport: which capabilities from the format's fixed list it named, whether the agent runs on a schedule, how many rows its consent table had, and about twenty further counts and fixed values of the same kind. We keep it to see what kinds of agents people build, which is what decides what gets built next.
It holds no text you wrote. Not the title, not the description, not the agent's name, not one sentence of the file. It carries the date but not the time, and no identifier of any kind, so nothing in it points back at your passport or at you.
It is the one thing here that is kept when a passport is deleted or expires. Since it holds no identifier there is nothing in it to look up and nothing to remove. The honest limit: on a quiet day there may be only one passport published, so somebody holding both this record and your passport could work out which row was yours. Somebody holding only the record cannot.
What a refused upload leaves
Not every upload becomes a passport. A file can be too large, or missing a section, or still carrying something that looks like a credential. A refused upload leaves one row: the date, and which refusal it was. It holds no text you wrote. What is stored is a code from the fixed list of refusals this site ships, not the sentence you were shown, because that sentence sometimes quotes your own file back at you to say what was wrong with it. The code is kept and the quotation is not.
It leaves the same hashed-address entry that rate limiting writes for every attempt. An upload turned away for arriving too fast is the exception: it is refused before anything reads it, so it leaves that entry and no row. That is deliberate. The entry clears itself and the row does not, so counting somebody who knocked too often would turn a trace that expires into one that stays.
We keep it because a refusal nobody can see is a refusal nobody can fix. The honest limit, and it is sharper than the one under the record of what was published: a refusal and the retry a minute later are the same person, so on a quiet day a run of rows describes one person's session rather than one attempt. The row carries the date and not the time, which blunts that without removing it.
When publishing is stopped for a review
A passport that nobody confirmed the description of is stopped rather than published, and getting past that stop is the one place the site has to remember something between two of your requests. What it keeps is random and holds nothing of yours: it only means anything when it comes back alongside the same file, which is how your retry is recognised as the same upload rather than a new one.
It stops working after fifteen minutes. If you come back it is used and gone; if you close the tab and never return, it is deleted by the same sweep that clears expired passports.
Rate limiting
Upload, deletion, status, email, vote and copy-count requests are counted per source address to limit flooding, and emails are counted a second time per passport so one link cannot become a small mailing. What is written down is a one-way hash of the address, never the address itself. Each entry stops contributing to the limit when its time window ends and is removed by later scheduled cleanup. Incomplete cleanup is retried. That is a count against a pseudonym rather than a list of who used the site; it is not anonymity, and we would rather say so than call it that.
The two boxes that take an address
Both appear only after you have published a passport, neither is a step you have to pass, and the passport and its link work exactly the same if you ignore both. Nothing anywhere on this site asks for an address before you can use it.
Sending the link. You may ask us to email your passport's link to somebody. One message is sent to that address and nothing about it is written down: not stored, not added to a list, not counted, not used to recognise the same person later. There is nothing for the recipient to unsubscribe from because there is nothing they were subscribed to. If you ask for your own copy, your address is treated the same way. That copy carries your delete token, so anyone who can read that mailbox can take the passport down.
Hearing what comes next. You may leave your own address to be told when this stops being a testbuild. This one is kept, which is the difference between the two, and it is why the box has a checkbox you have to tick rather than a default you have to notice. The address goes on one list held at Resend and is used for occasional notes about what changed. It is not sold, not shared with anyone else, and not used for anything but that. Every message carries an unsubscribe link, and unsubscribing leaves your address on a suppression list so that it sticks; ask us instead and the record is deleted outright.
Both go through Resend, an email delivery provider, whose systems handle the address in order to deliver the mail and who keep their own delivery records as any mail provider does. For the first box that is the whole of Resend's involvement. For the second, Resend also holds the list itself.
Deletion, expiry and where this runs
A passport published without a gallery listing expires after thirty days unless you renew it. A listed passport does not expire. Unlisting removes it from the gallery and gives its link a fresh thirty-day expiry; the link continues to work during that time. With the link and the delete token you can remove a passport at the manage page or the delete page.
When deletion succeeds, the passport text is removed immediately and permanently. We also remove its view counter, copy counter, gallery card, saved category changes and votes. Some of that cleanup may finish later, and scheduled cleanup retries what remains. A gallery page already open or cached may still show the old card. There is no soft delete and no tombstone, because a tombstone would answer the question of whether a passport ever existed at that link, which the not-found response is written to refuse. An expired link, a deleted link and a link that never existed are the same page, the same status and the same headers. The record of the passport's shape is not covered by this, for the reason given above.
Server logs and the companies involved
The site runs on Netlify, which serves the pages, runs the small programs behind the upload and delete endpoints, and holds the stored passports in its own key-value storage in the same account. Netlify's servers necessarily receive your request in order to answer it and keep ordinary request logs containing an IP address, a timestamp, the path and a user agent, under their retention policy for the plan this site runs on. Those logs exist to run and defend the server. Our page counter above is a separate record and does not read them. We do not query them to build profiles, and do not join them to stored passports.
Resend delivers both optional emails described above and holds the list the second one subscribes you to. The processors involved are named in full in section 05.
The page you see after publishing a passport links to an optional feedback form, and so does the copy of your passport link that you can ask us to email you. The form is hosted by Notion (Notion Labs, Inc., United States), not by us. Following a link opens it in a new tab and takes you off this site: your browser contacts Notion, which sees your IP address as any site would and may set its own cookies. From our pages we pass no referrer; a link in an email is opened by your mail program, which we do not control. What you type into the form is stored by Notion on our behalf, and we read it. If you do not follow the link, nothing is sent anywhere.
Where the agent itself goes, and what reaches us
The passport does. Uploading it is what reaches us, and once published, it is stored and served at its link for as long as it stays published. A passport is a description of an agent: what it is for, when it runs, what it reads, what it puts in front of you, and one to three real examples of its output. That is the file's whole purpose.
The agent itself does not, and neither does its execution: capture runs inside the assistant you already use, install runs inside the recipient's, and the agent never runs on our side. The one thing on our side that does call a model is the check on the passport text described in section 05, which runs only after you upload and only on what you uploaded. A passport names the kinds of access an agent needs and never a credential value, and an upload that still carries a recognisable credential is refused and not stored. The description travels, the execution does not.
Who is responsible, and what you can ask for
The controller is Raffael Hueberli, St. Gallen, Switzerland, reachable at hello@phaeacia.ai. Contact details are on the imprint.
The basis for storing a passport is your request: you uploaded it and asked for it to be published. The basis for keeping your address on the list is your consent, given by ticking the box, and you can withdraw it at any time with the unsubscribe link in any message or by asking. Withdrawing does not affect anything sent before you did. The basis for the counts described above, and for the rate limiting, is our legitimate interest in understanding and defending a service we run. Five processors act on instruction: Netlify, which serves the site and stores the passports, Resend, which sends the optional email, Cloudflare, which resolves this domain, Notion, which hosts the optional feedback form and holds what you type into it, and TypeSafe, a United States company, which checks the passport text, the words you wrote and any personal detail they hold, for what our own checks and a secret scan might still miss. All five are companies with United States parents. For now its result does not change whether a passport is accepted. TypeSafe's published privacy policy says it does not train its models on what is sent to it. TypeSafe does not state a deletion period for what it reads; its policy commits only to keeping it 'as long as reasonably necessary.'
Under Swiss data protection law and the GDPR you may ask what is held about you, ask for it to be corrected, ask for a copy, and ask for it to be erased. You may also complain to a supervisory authority: in Switzerland the Federal Data Protection and Information Commissioner, and in the EU the authority where you live.
The honest version here is short. What you can ask us to remove is the passport you published, which you can also delete yourself with the token you were given, your address on the list, if you ticked the box, and your address from the suppression list described above, which unsubscribing leaves behind on purpose, and anything you typed into the optional feedback form, which is held by Notion: ask us and we will delete it or have it deleted, if you tell us which entry is yours. The record of the passport's shape and the refusal count hold no identifier at all, so there is nothing in either to find or to remove. The rate-limiting entries are one exception, and the block above says it plainly rather than claiming otherwise: they are keyed by a hash of your address, that is a pseudonym and not anonymity, and they clear themselves when their window has passed. The copy TypeSafe holds is the other: once it has been sent, we cannot promise its removal, because TypeSafe states no fixed deletion period. Write to hello@phaeacia.ai and it is answered without a process.
Changes
If this changes, the date at the top changes with it. This page describes how the site behaves today and does not describe anything that is planned, because a privacy page that promises the future is worth nothing to the person reading it now.