About this service

Privacy

foliom takes an unpublished manuscript and gives it back typeset. This page says what it does with the file in between, what it keeps afterwards, what leaves this server, and how to make it all go away. It describes this instance as it is configured now, not an intention.

What you upload

One Word document per conversion, up to 25 MB, and the metadata you type beside it — the journal or conference name a class file needs to typeset a title block. Nothing else about the document is asked for, and nothing is read from your browser beyond the two cookies described below.

A conversion that cannot settle a check from anything in your manuscript asks you one question about it — an address the document gives for nobody, a title no line of it states — and if you answer, that answer is stored with the conversion's metadata and printed in the paper as you typed it. It is the only text foliom puts in your output that did not come from a paragraph of your document, the report says so on the row it settled, and leaving the question unanswered is always allowed: nothing is invented in its place.

A conversion writes up to nine objects, all under a key of the form jobs/<id>/: the document you uploaded, and then whatever it produced — the PDF, the LaTeX source, the editable Word version, the submission bundle, the pre-flight report, the record of anything foliom repaired and re-checked, the submission checklist and the compiler's log. A conversion that failed writes fewer; the uploaded document is kept either way, because a failure is worth being able to reproduce. They are written to a directory on the same server that served you this page — this instance has no object storage configured — and are served back to you by this application after it has checked that the conversion is yours. No conversion is published anywhere, and every page that could show one is excluded from search engines by both the response header and the page itself.

What is in the database

One row per conversion: the file name as you uploaded it, its size, a SHA-256 digest of its bytes, which target you chose, the metadata you typed, the timestamps, how many pages came out, and the pre-flight findings — which quote the parts of your document they are about. Alongside it, one row per state change (queued, running, done, failed) with the worker that made it and the reason.

An account adds: your email address, your name if you gave one, the time you created it and the time you last signed in, and a salted PBKDF2-SHA256 hash of your password. The password itself is never stored and cannot be recovered from the hash. Each browser you are signed in on has a row holding a hash of its session cookie, its expiry and the User-Agent string the browser sent, which is what lets the account page show you where you are signed in. A password reset or an address confirmation adds a row with a hash of the single-use token and its expiry.

Asking for a journal target stores what you typed into that form — the journal, the publisher, the links, the identifiers and your message — against your account, with the files you attached, every message either side has sent about it, and a dated record of everything that has happened to it. Two things about that record are worth saying plainly. Whoever handles the request can see your email address, because a request is a conversation and somebody has to be able to answer it. And they can write internal notes on it that you are not shown: they are kept in a separate table that no page you can reach reads, and the history you see records that a note was written without a word of what it said. Deleting your account deletes your requests, the files you attached, both sides of the conversation and those notes.

How long it is kept

Nothing expires on its own. There is no retention period, no lifecycle rule on the storage and no sweeper: a manuscript you uploaded today is still there next year unless you remove it. Removing it is yours to do, one conversion at a time. Every conversion carries a delete button — on your conversions and on the conversion's own page — which erases that conversion and every file stored for it and leaves the rest alone. Deleting your account erases all of them at once. Sessions and reset tokens are the exception to the first sentence — those are swept once they expire.

What leaves this server

There are exactly three ways any part of your document or your address can reach anybody else, and each one below says whether this instance uses it. Beyond them there is no analytics, no advertising, no tracking pixel and no third-party script or font on any page — the content security policy on every response allows scripts and styles from this origin only.

Reference lookups

Switched on. For each entry in your bibliography, foliom asks doi.org and api.crossref.org whether it resolves and whether the DOI matches the work it describes. What is sent is the reference — the authors, title, year and DOI of a paper you cite, all of it already published — never your own text. Those two services are Crossref's and the DOI Foundation's, and they log requests as any public API does.

The classifier

Switched off on this instance. Every paragraph is classified by the rules alone and no part of your manuscript is sent to a language model.

Email

Two messages, both triggered by something you just did: confirm your address, and reset your password. Each carries your address and one link to Mailtrap, which delivers it, and each arrives from noreply@foliom.dev — worth allowing through a filter, because a reset link in a spam folder is how people lose accounts. No newsletter, no announcement, no marketing: those are the only two messages this software can send.

One further hop, named because it is a network call even though it is not a third party: the LaTeX and its figures are handed to the TeX compile service this deployment is configured against, which is part of the deployment rather than somebody's product. Whoever runs the server can tell you where it runs. Nothing else about your document leaves this machine.

Cookies

Two, first-party, marked HttpOnly so no script can read them, and not used to track anything across sites. foliom_owner is a random token that says a conversion belongs to this browser; it is set on the convert page and lasts thirty days. foliom_session is your sign-in, also thirty days, and is not sent at all when another site links to this one. There is no cookie banner because there is no cookie to ask about: both are needed for the thing you asked the site to do.

Logs

The web server in front of this application writes an access log — the requesting IP address, the URL, the status and the browser's user-agent string — to the server's own log, and the application logs a line per conversion holding the job id, the target, the size and the name of the file you uploaded. Those logs stay on the server and are read when something breaks. The rate limiter also keeps recent IP addresses in memory, which is lost when the process restarts.

What you can do

Signed in, your conversions lists every one on the account and every file it produced, and your account is where you change your name or your password, see the browsers you are signed in on, and delete the account.

Deleting one conversion removes, for that conversion alone: the .docx you uploaded, the PDF, the LaTeX source, the editable Word version, the submission bundle, the pre-flight report, the submission checklist and the compile log, and then the conversion's own row and its trail of state changes. Unlike account deletion, no record of it is left behind — the row goes rather than being unlinked, so the file name, the digest and the findings go with it. Your other conversions, your account and your address are untouched. It asks you to confirm on a second page, it cannot be undone, and there is no backup to restore from. A conversion still running can be deleted too; anything the compile writes afterwards is removed with it. If an object storage call fails the object is left behind and the failure is logged for whoever runs the server to sweep, exactly as during an account erasure.

Deleting the account removes your email address, your name, your password hash, your sessions and any outstanding reset or confirmation token, and deletes the stored objects of every conversion on it — the manuscripts, the PDFs, the LaTeX, the bundles, the reports and the logs — in passes until the list is exhausted, not just a first page of them. Every conversion means every one, including the one you ran a minute ago: a conversion is recorded against the account the moment you start it, so the sweep sees it without your having to sign in again. It cannot be undone and there is no backup to restore from.

What survives it, stated plainly: the conversion rows stay in the database with the account reference set to null, so the file name, the digest, the size, the target, the timestamps and the findings of every conversion remain, belonging to nobody. Nothing attaches them to anybody again — no sign-in and no sign-up moves a conversion onto an account, and the browser cookie those rows were created against is dropped from your browser when the account goes. If an object storage call fails during the erasure the object is left behind and the failure is logged for whoever runs the server to sweep. Server logs are not rewritten either. Everything else is gone.

What this instance does not do

Your manuscript is not sold, not shared, not shown to anybody else and not used for anything but the conversion you asked for. The list above is exhaustive: nothing else receives any part of a document, and none of what does is an advertising business. No profile is built from what you convert, and nothing links one conversion to another except an account you created yourself. Reading this page needs no account and sets no cookie.

Asking

This instance publishes no contact address. Whoever runs it has one; if you did not get the address from them, there is no way to guess it from here, and that is a gap in this deployment rather than a policy. See contact.