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 writes up to six 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 submission bundle, the pre-flight report 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.

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. An upload is kept until you delete your account, which is the one action that erases it. Sessions and reset tokens are the exception — 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 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.