Privacy

Three kinds of thing, and no fourth.

Your account. The email address you sign in with, your handle, and whatever you choose to put on your profile — display name, bio, a location label, a website link, an avatar. Only the address and the handle are required.

What you make. Your photographs and the information embedded in them, which for most cameras and every phone includes the time each frame was taken and the coordinates it was taken at. Then the journeys themselves: titles, the moments you arrange the photographs into, your narrative, captions, alt text, tags, and the camera and film you credit.

Counters. Likes, bookmarks and comments against your own journeys, shown to you on your analytics page. They are totals kept in our own database, not a profile of who read what.

That page also shows a reads column, and it is worth being exact about it. Nothing on this deployment records a read. There is a table for it, an index that would count one visit per reader per journey per day, and a routine that would write the row — and nothing calls that routine, so the number is zero for everybody and no row about a reader has ever been written. The column is a promise the code does not keep. If that changes, this notice changes with it and says what is recorded.

The paragraphs above are the shape of it. This is the list, because a summary is easy to write around and a list is not. Every one of these is a table in our database, and nothing here is held for a reason other than the one given.

• Your profile — handle, display name, avatar, bio, a location label, website and Instagram links, the countries you say you have visited, the interests you picked when you joined, a locale and timezone, and whether the account is suspended. It is what a profile page is made of, and what tells a reader whose journey they are reading. Your sign-in address is not here: it lives with our authentication provider.
• Your journeys and their moments — titles, subtitles, descriptions, city and country, dates, narrative, the whispered aside line, the clock label, the camera settings and film reference you credit, tags, visibility, whether it is a draft, and the coordinates of each moment. This is the work itself.
• Your photographs’ records — where the file sits with our image host, its format and size in bytes, its pixel dimensions, the original filename you uploaded it under, a colour, a blurred placeholder small enough to inline, alt text, and the metadata read out of the file. That metadata is stored whole rather than in the two fields we use, so whatever your camera wrote — the make and model, the lens, the exposure, the capture time, the coordinates — is kept. The clause below is about that. The image bytes themselves are never in our database.
• Likes, bookmarks, comments and follows — which account did which, and when. A like and a follow are public by nature; a bookmark is visible only to you. Comments are kept with their author so a thread makes sense.
• Collections — the sets of journeys you assemble, their titles, notes and order. Private to you today; there is no public page for one.
• Notifications — one row per like, follow or comment on your work, with who caused it, what it points at and whether you have read it. Written by the database at the moment the event happens, never by another account.
• Drafting records and the credit ledger — for each run of the Story Director: which journey, which model, which version of the prompt, how many moments, how many tokens went each way, how long it took, and whether it succeeded. The text of the prompt is not stored, because it is reproducible from those facts. The ledger beside it is every movement of credit on your account, signed and dated, so a balance can always be re-derived rather than asserted.
• Reports and moderation records — kept if somebody complains about content, so that a decision has a reason attached to it. There is no report button in the product yet, so this is at present an empty table waiting for a route into it.

The schema also carries an audit log and a rate-limit table, and nothing writes to either of them on this deployment. They are named here so that the absence is on the record: if either starts recording, this notice says so before it does.

Photographs carry more than a picture. Almost every phone and many cameras write a block of metadata into the file — the make and model, the lens, the exposure settings, the moment the shutter opened, and, unless you have turned it off, the latitude and longitude the shutter opened at, often to a precision of a few metres.

We keep that block whole. Two values are pulled out and used: the capture time, which is what puts your photographs in order and groups them into moments, and the coordinates, which are the entire basis of the map at the end of a journey. The rest is stored alongside them rather than discarded. Some of it surfaces publicly — the map, and the times printed beside each moment — and the remainder simply sits in the record.

The coordinates are read twice, and it is worth knowing both. Your own browser reads them out of the file before it is uploaded, which works for JPEG. Our image host reads them again from the uploaded file and its answer takes precedence — and for a HEIC from an iPhone it is the only reader that succeeds, because no browser here parses HEIC metadata. So “my browser did not find a location” is not the same as “no location was stored”.

Which means a journey that begins with a photograph taken in your kitchen will publish the location of your kitchen. That is not a bug and we cannot guess which frames you meant. Before publishing, look at the map.

Getting a location out again. There is no control in the Builder for editing or clearing a moment’s coordinates, and we would rather say so than let you hunt for one. What works today: delete the moment, which removes its point from the route; or make the journey private, which withdraws the whole map at once, including from the copy cached at the edge; or delete the photograph, which takes its stored metadata with it. The most reliable method is upstream of us entirely — most phones can be told to stop writing location into photographs at all, and a photograph that never carried a coordinate cannot publish one.

Nothing you make is public until you publish it. A journey is created private and stays private — visible to you and to nobody else, excluded from every list anyone else sees — until you press Publish. There is no soft launch and no partial exposure in between.

Once you publish a journey, this becomes readable by anyone with the address, with no account needed: the journey and its moments, the narrative and captions, the photographs, the map and the coordinates behind it, the times each moment happened, the tags, and the like, bookmark and comment counts. It is listed on your profile page. It has a permanent address that search engines may index and that other people may share further.

Your profile is public in the same way from the moment you finish joining: handle, display name, avatar, bio, location label and links, and your published journeys. Likes and follows are public by their nature — a follower count is a count of people who can be named.

What stays private regardless: your sign-in address, your drafts and everything in them, your bookmarks, your collections, your notifications, your credit balance and drafting history, and the photographs sitting in your library that you have not placed in a published journey.

Make private is the way back and it is a real one. It returns a journey to a draft and clears the copy cached at the edge, so it stops being readable at once rather than minutes later. What it cannot do is reach a page somebody has already saved, a search engine’s cache, or an archive. Publishing is the decision that is hard to fully undo, which is why it is a separate button.

Four companies, each doing one job, and none of them given your data for their own purposes.

• Supabase — accounts and the database. It receives your sign-in address and password, which it holds rather than us; every record listed above, because it is the database those records live in; and whatever your browser sends when it reads or writes any of them. It runs the email, one-time-link and Google sign-in flows, and sends the transactional mail those flows need — a sign-in link, a password reset, a confirmation when you change your address. It is the only processor that sends you email, and it sends nothing that is not one of those.
• Cloudinary — the photographs. It receives the image files themselves, going straight from your browser without passing through our servers, and therefore the metadata inside them, including any coordinates. It reads that metadata on our behalf and hands back what it found. It serves every photograph on the site, so it also sees the request each reader makes for one.
• Vercel — hosting. It receives every request your browser makes to this site, which necessarily means the address you asked for, your IP address, your browser’s user agent and your cookies. It runs the application code, so anything the application handles passes through it in transit.
• Anthropic — the Story Director, and only when you run it. It receives the shape of the journey in text — each moment’s time and timezone, its coordinates to four decimal places, the resolved place name, how many photographs it holds, the gap since the previous moment, how you travelled, and the title and subtitle you have already typed. It does not receive your handle, your email address, your account identifier, or any photograph. Your photographs are not sent, which is precisely why the model is instructed to write only from that evidence and never as though it had seen them.

Nothing else is given anything. There is no advertising network, no analytics vendor, no error-reporting service, no email marketing platform and no customer support tool in this product, so none of them appear on this list.

Reading a page here makes a small number of requests to other people, all of them for content rather than for tracking.

• Map tiles and styles from CARTO, drawn from OpenStreetMap data, on any page with a map. They load only when the map is about to come into view, so a reader who never scrolls that far never requests them.
• Photographs from Cloudinary, and one landscape from Unsplash behind the footer on the front page.

Typefaces are not among them. The three faces this site uses are served from our own domain, so displaying a page makes no request to Google Fonts and sets no cookie on their behalf.

One thing, in two parts, and it is the sign-in session. The cookie is set by the Supabase authentication library when you sign in and cleared when you sign out. It is named after our project rather than after us — a name of the form sb-<project>-auth-token — and because the token inside it is longer than a single cookie may be, it is split across numbered parts: sb-<project>-auth-token.0, .1 and so on. Seeing several of them is normal and is one session, not several.

It is strictly necessary in the plain sense of the phrase: it is the only thing that tells the server which account is making a request, so there is no version of a sign-in that does without it and no consent banner that could sensibly offer you the choice. Reading a published journey while signed out sets no cookie at all.

One other thing, and it is not a cookie: your light or dark preference is written to local storage in your own browser, under the key jo-appearance, so the page can be painted the right way round before the first frame instead of flashing. It is never sent to the server and never leaves your machine.

That is the complete list. There are no advertising cookies, no analytics cookies, no tracking pixels, no fingerprinting, no session-recording scripts and no third-party tags of any kind on this site — not because they have been switched off, but because none is installed. No consent banner appears because there is nothing to consent to.

• No advertising, anywhere, and no advertising network is given anything.
• No selling, renting or sharing of your personal data or your photographs with anyone beyond the four processors above.
• No use of your photographs or your writing to train machine-learning models.
• No profiling of readers, no cross-site tracking, and no attempt to work out who somebody is from what they read.

Most of it you can exercise yourself, immediately, without asking. Every journey is private until you publish it, and Make private in the Builder withdraws a published one at once — including from the copy cached at the edge. Your profile fields, your handle and your sign-in address are all editable in settings.

Deleting the account is in the same place. It takes effect in two stages: the moment you confirm, every journey you own goes private, so nothing of yours is readable; thirty days later the account and its contents are erased. You can cancel inside that window — though cancelling does not put your journeys back on the public web, which is deliberate, because the likeliest reason to cancel is that the request was not yours in the first place.

Two things this notice will not overstate. There is no one-click machine-readable export of your data yet — if you want a copy of your photographs, keep your originals. And the job that carries out the erasure at the end of the thirty days is not yet scheduled on this deployment, so the date you are shown is the earliest erasure can happen rather than a guarantee of the hour. Both are being fixed; neither is hidden. The clauses below say what that means in practice.

Depending on where you live you may have rights over the information we hold about you — to see it, to correct it, to have a copy of it, to have it erased, to object to or restrict what we do with it. We do not ask which country you are in before honouring the ones we can honour. Here is what each looks like here, including where the answer is unsatisfying.

• Access. Most of it you can simply look at. Your profile fields are on the settings page as editable values, your journeys and moments are in the Builder, your photographs and their filenames are in Media, your bookmarks and collections are their own pages, your notifications are a list, and every movement of credit on your account — grant and charge, dated and reasoned — is on the credits page. There is nothing held about you that these surfaces do not show except the technical fields listed earlier in this notice.
• Correction. Also self-service, and immediate. Display name, bio, location label, website, avatar and handle in settings; titles, narrative, captions, alt text and dates in the Builder. Changing your handle keeps every link you have already shared working, so correcting it costs you nothing.
• A copy. This is the one we cannot yet give you properly, and we would rather write it plainly than bury it. There is no export — no download button, no machine-readable file, no archive. What exists is what you can see and copy by hand from the pages above. Keep your original photographs; they are the part that would be hardest to reconstruct, and Journeo is not a backup of them.
• Erasure. Piece by piece, immediately, in the product: delete a photograph in Media, delete a moment or a whole journey in the Builder, delete a comment, remove a bookmark. For everything at once, the account deletion request in settings — read the clause below before relying on the timing.
• Objection and restriction. Making a journey private restricts its processing in the only sense that matters — it stops being served. Beyond that there is no processing to object to: nothing here profiles you, targets you, scores you, or makes a decision about you.

Anything the controls do not cover would have to be asked for, and this deployment has no support address to ask at. That is stated at the foot of this page and on the contact page, and it is a genuine deficiency rather than a policy. It is also why so much of the above is built as a control instead: a control acts in a second and does not depend on anybody reading a message.

Your account and your journeys are kept until you delete them or close the account. Nothing here expires on its own, because a travel story you wrote four years ago is the whole point of having written it. Deleting a single thing — a photograph, a moment, a journey, a bookmark — takes effect at once and is not reversible; there is no recycle bin, and it does not wait for a nightly job.

Closing your account is different, and this is the paragraph to read carefully. What happens the instant you confirm is real and immediate: every journey you own is returned to a private draft, so nothing of yours is readable from that moment on, and every other device you are signed in on is signed out. Your request is recorded with the date it was made, and a date thirty days later is shown to you as the point at which erasure falls due.

What does not happen is the erasure itself, automatically, on that date. The routine that erases an account and everything cascading from it is written and in place; nothing on this deployment is scheduled to call it. So the honest description is this: your request is recorded, your account and your work are taken out of public view immediately and stay out, and the final erasure is performed on request rather than by a timer. The date you are shown is the earliest it can happen, not a promise that it has. We would rather tell you that than let you believe a deadline that nothing enforces.

Two further limits worth knowing about erasure when it is performed. The image files themselves are held by our image host and are removed in a separate step from the database record, so they can lag it. And comments you left on other people’s journeys are deleted along with your account rather than kept and re-labelled, which means the replies underneath them go too.

Ordinary technical copies — database backups, and images already sitting in a reader’s browser or in a content delivery network — age out on their own schedule rather than instantly. They are not served as your journey and are not searchable; they simply exist for a while.

Journeo is not built for children and is not directed at them. It is a publishing tool: everything it is for involves putting photographs, dates and locations on the open web under a permanent address, which is not something a child should be doing unsupervised and not a product we have designed any protections into.

There is no age gate on this deployment and these terms set no minimum age, because settling one is a legal question and inventing a number here would be worse than admitting it is open. If you believe an account here belongs to a child, or that a child’s photographs have been published without the right consent, we will act on that — the routes that exist are on the contact page, and their present state is described there candidly.

Four things are worth naming because they are structural rather than aspirational.

• The database enforces the boundary, not the application. Every table carries row-level security, switched on and forced, so the rule about who may read or write a row is evaluated by Postgres against the session making the request. A bug in application code cannot hand somebody another person’s draft, because the query itself comes back empty. A suspended or closed account is treated as anonymous by that same layer, in one place, rather than by a check that each page has to remember.
• Uploads are authorised before they happen. Your browser cannot write to our image host on its own. It asks our server, which checks your session and that the journey is yours, and only then signs a short-lived permission for that one file. When the upload finishes, the host’s reply is verified with a signature check before anything is recorded, so a crafted request cannot make us record a photograph that is not yours.
• Sign-in is not ours to get wrong. Passwords are held and verified by our authentication provider, never by this application and never in a form we can read. The session cookie carries a signed token that the server validates against that provider rather than trusting it, and changing your email address requires confirming it from the new address.
• Ordinary hygiene. Everything is served over HTTPS. Every form submission is checked to have come from Journeo before it is acted on. The site declines to be framed by other sites, tells browsers not to guess at content types, and sends only the origin — not the full address — as a referrer when you follow a link away.

What we will not claim. No independent security audit or certification has been carried out. There is no bug bounty. Nothing here is encrypted in a way that would stop us reading it, so a lawful demand or a compromise of one of our processors reaches the same data we can see. And no measure on this list protects against the most common way a photograph ends up somewhere unwanted, which is that somebody published it deliberately.

It will change, because the product is being built and several clauses above describe a gap rather than a settled behaviour. The date at the top of this page is when it last changed, and it is moved for every change including a small one.

Where a change means we start collecting something we did not, or start sending something somewhere new — a fifth processor, an analytics tool, a reader-tracking feature, or photographs being sent to a model — this page is edited in the same release as the code, and we will say so prominently rather than moving a date and hoping. Where a change is a correction or a clarification that does not affect what is collected, the date moves and nothing more is said.

There is no archive of earlier versions yet, so the date is currently the only version marker. That is a gap and it is named here for the same reason as the others.

There is no support mailbox on this deployment yet, and the contact page says so plainly rather than printing an address nobody reads. It is also where the address will appear once there is one. In the meantime, the controls described above are real and they act immediately, which for most privacy questions is faster than any reply would have been.