Privacy policy

Pilcrow · effective 2026-09-16

Your course material never leaves your phone. The photographs you take are never stored on our server. What we keep is an email address, a plan, and a count of how many scans you have used.

This policy describes exactly what happens to data when you use Pilcrow. It is written to be checkable: every claim here describes a specific thing the software does or does not do, and nothing is hedged with "may".

Who we are

The controller of your personal data is Fatih Aktas, an individual running Pilcrow in his own name rather than through a company. No company stands behind it, and nobody else is a controller of your data. He is in Ontario, Canada, and the server the app talks to is hardware he runs himself rather than a cloud provider's — with Cloudflare's proxy in front of it, which is the one part of the path we do not own. See Cloudflare, specifically.

Two privacy laws reach this service, and this page is written for both rather than for whichever is more convenient. Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) is the federal private-sector law that applies to an organization in Ontario collecting personal information in the course of commercial activity: three provinces have a general private-sector privacy law of their own and Ontario is not one of them. The UK and EU GDPR reach us as well, because Pilcrow is sold worldwide and is therefore offered to people in the UK and the EEA. What each of them gives you is set out in Your rights.

Write to hello@aktasfatih.com. It is a monitored mailbox and it is where we answer: everything in this policy, including a request to see, correct, export or erase your data, can be done by email. We answer within 30 days.

Your course material

The transcripts, slides and notes you load into Pilcrow are stored only on your phone, in the app's own database. We never receive them. There is no upload step and no server-side copy, so there is nothing for us to lose, hand over, or be compelled to produce.

Searching that material also happens on your phone. When you scan a question, the app finds the handful of passages most likely to be relevant and sends only those passages with that question, plus the course's name. In practice that is a page or two of text: the app sends at most twelve passages, and the server refuses any request whose text exceeds 64,000 bytes however it is packed. The library itself stays where it is.

Deleting a course, or deleting the app, deletes that material. We cannot delete it for you, because we cannot reach it.

The photographs you take

When you scan a question, the app takes a photograph of the screen in front of you and sends it to our server. Our server finds the screen in the picture, flattens the angle, and passes the result to Anthropic, which reads the question and answers it.

That photograph is held in memory for the length of the request and is never filed away on our server. The app sends the picture inside the request body; the server decodes it, works on it and passes it on, all in memory. There is no upload directory and no photo bucket. When the request ends, the image is gone.

It does not reach us directly, though. Cloudflare's proxy stands in front of pilcrow.aktasfatih.com, your phone's encrypted connection ends there rather than at our server, and Cloudflare opens a second encrypted connection to us. For that moment the request is decrypted on Cloudflare's machines, photograph included, and so is the answer on the way back. What Cloudflare keeps is the request's metadata and not the image — which is a different sentence from "they cannot see it", and the difference is set out in Cloudflare, specifically.

On your phone, the captured photo is deleted as soon as the scan ends — whether it answered, failed, or you abandoned it for a better picture. If the app is killed mid-scan, the leftover is swept away the next time you open it. Nothing is ever added to your camera roll.

We know the photograph may contain more than the question: your name, your grades, an email address, whatever else was on the monitor. That is exactly why the pipeline keeps nothing.

Questions and answers

The text of a question and the text of its answer are used to produce the answer and are then discarded. They are not saved in our database, and they are not written to our logs — the logging on that path deliberately records counts, field names and sizes rather than content.

Your account

We store:

• Your email address. There is no password: we email you a single-use link and an 8-digit code for the same sign-in. Tapping the link on your phone opens Pilcrow and signs you in; typing the code into the app does the same thing. We need the address to send that mail, to attach your subscription to something, and to contact you about the service.
• Or, if you sign in with Apple, an identifier Apple gives us. Apple hands the app a signed token; we check Apple's signature on it and keep two things out of it — an opaque identifier for you that is unique to us and means nothing to anyone else, and the email address Apple chose to share. If you picked Hide My Email, that address is one of Apple's @privaterelay.appleid.com forwarders, and we neither receive nor can discover the real one. We do not ask Apple for your name. We never see your Apple ID password, and Apple is not told what you scan or what you are answering.
• And a third thing, which does not come out of that token: a revocation handle for your Apple sign-in. Alongside the signed token the app hands us a one-time authorization code, and our server trades that code with Apple — a direct call from us to Apple, at the moment you sign in — for a long-lived refresh token, which we store. It is a credential at Apple rather than at us: it cannot be used to sign in here and it grants nothing against this service. The only thing we ever do with it is the thing it is kept for. When you delete your account we call Apple and revoke it, so that Pilcrow stops being listed under your Apple ID; Apple requires that of any app offering Sign in with Apple. It is deleted along with your account, in the same request.
• Your session. When you sign in, your phone gets a random token. We store only a SHA-256 hash of it, so a copy of our database contains nothing anyone could sign in with. A session ends after 30 days without use, and in every case after 90 days. You can end every session on every device at once from Settings › Sign out everywhere, which is what to do if you lose a phone.
• Your plan and your scan count — which plan you are on, when the period rolls over, how many scans you have used and how many top-up credits you hold.

We do not ask for your name, your institution, your course enrolment or your age, and we have no way to learn them.

Your address in our logs, and where those logs go

Being straight about one thing: our server writes a log line each time it tries to send you a sign-in link — whether it sent, failed, or was not configured to send — one more if a rate limit stopped that mail going out, and one each time a link or a code is redeemed or refused. Those lines used to carry your email address. They no longer do. What they carry is a fingerprint of it: the address lowercased, hashed with SHA-256, and cut to the first 12 hexadecimal characters of the result. It is operational logging and it answers operational questions — whether the mail provider is down or nobody is trying to sign in, whether this is one address retrying or ten thousand being tried once.

That fingerprint is still data about you, and we are not going to call it anonymous. It is unsalted, so anyone who already has an address to test can hash it and see whether it matches — it confirms a guess in one step. What it will not do is hand an address to somebody who does not already have one. That makes it pseudonymised rather than anonymous, which in turn means it is still personal data: everything on this page that applies to your address applies to its fingerprint too.

These logs do not stay inside the application. The application writes them to its own output; a collector running alongside it copies every line into a log store (Grafana Loki). Both of those are machines we run ourselves, on the same private network as the server — there is no logging company in this, and nothing goes to a cloud provider. That store is configured to delete anything older than 31 days, which is how long a line lives. The same path carries the server's request log, which records the address a request came from, the time, the method and path, and the response status; it does not record request or response bodies, so no photograph, question or answer is in it.

One consequence of that is worth stating rather than leaving you to work out. Deleting your account empties our database immediately, and it does not reach into that log store. What is left there is the fingerprint and never the address, it is used for nothing but keeping the service running, and it is gone within 31 days.

Metering

Every scan costs us money, so every scan is recorded. The record contains the model that was used, how many tokens went in and out, what that cost, which account it was charged to, which stage of the work it paid for, which scan it belonged to where the work was part of one, and when. It contains no part of your question, your answer or your photograph. We keep it to bill fairly, to enforce plan limits, and to notice a compromised account draining someone's allowance overnight.

Payments

Subscriptions and top-ups are sold through Apple's in-app purchase, and Apple handles the payment end to end. We never see a card number, a billing address, or anything else you give Apple.

What we receive is a signed receipt from Apple. From it we store the transaction identifiers, the product you bought, whether it is a subscription or a credit pack, whether it is active, expired or refunded, whether it is set to renew, and the relevant dates. That is what lets your subscription work on a second phone and lets a refund take back what it granted.

Who else touches your data

Four companies. We have no advertising partners, no analytics provider, and no data brokers, because there is no analytics or tracking code in the app or on this page at all.

Anthropic, specifically

We use Anthropic's commercial API. Under the Anthropic Commercial Terms of Service (effective 17 June 2025), which govern our account, Anthropic "may not train models on Customer Content from Services" — Customer Content being both what we send and what comes back. Your photographs and your passages are not training data.

On retention, Anthropic's published position for API traffic is that it "automatically delete[s] inputs and outputs on our backend within 30 days of receipt or generation", with stated exceptions: a longer-retention service we chose to use (we use none), a separate agreement, enforcing their Usage Policy, or compliance with the law. If their automated safety systems flag something as violating that policy, they say they retain the inputs and outputs "for up to 2 years and trust and safety classification scores for up to 7 years". Anthropic's own documentation additionally says image uploads "are ephemeral and not stored beyond the duration of the API request". (Anthropic privacy centre, "How long do you store my organization's data?", and their vision documentation.)

So there is a limit to what we can promise on your behalf: we cannot pull a specific scan back out of Anthropic's systems on request. Anthropic states plainly that "for paid API customers, we do not support ad hoc deletion" — the 30-day automatic purge is the mechanism, not a request form. Deleting your account with us deletes everything we hold; it does not reach into Anthropic's 30-day window.

Anthropic acts as a data processor for us under their Data Processing Addendum, and publishes their own sub-processors at anthropic.com/subprocessors.

Cloudflare, specifically

Cloudflare used to run our DNS and nothing else, and until 15 September 2026 this page said they were not in the path a scan takes. They are now. The firewall on the connection our server sits behind accepts inbound web traffic only from Cloudflare's published address ranges, so pilcrow.aktasfatih.com is reachable from the internet only through their proxy. They are a processor handling your data on our instructions, not a company we merely buy a DNS record from.

The consequence worth understanding is about the encryption. Your phone's connection is encrypted to the Cloudflare data centre nearest you, and the certificate your phone checks is Cloudflare's, not ours. Cloudflare then opens a second encrypted connection to our server, and that leg is secured by our own Let's Encrypt certificate. Between the two legs the request exists in the clear on Cloudflare's systems, which means Cloudflare is technically able to read everything that goes past: the photograph on the way in, the answer on the way out. We are not in a position to promise you otherwise, so we are not going to.

What they are able to see and what they keep are different questions, and the honest answer separates them. Bodies are proxied through memory. A scan is a POST, which their edge does not cache, and the answer comes back as an event stream marked no-cache and generated for that one request, so nothing of a scan is cached at the edge. What Cloudflare retains is HTTP metadata in its edge logs — the source IP address, the time, the method, the hostname and path, the user-agent, the response status and the byte counts. Not the image. How long that metadata lives is Cloudflare's own retention schedule rather than a number we set, in the same way Anthropic's thirty days are Anthropic's.

One thing follows from the path being logged. The sign-in link we email you carries its token in the URL, so that token goes through those edge logs like any other path. It is single-use and it expires in ten minutes, which is what bounds it. The 8-digit code in the same mail is never put in a URL by us or by the app, so it is not in those logs at all.

Data retention: what is kept, and for how long

This is the whole of it. Anything not in this table is not kept.

Deleting your account

In the app: Settings › Delete account. It is immediate and it is not reversible. One request deletes:

• your account, your email address and your Apple identifier if you have one;
• every session, on every device;
• every sign-in link row for that address, used or not;
• your subscription record, credit ledger and purchase history with us;
• every metering row and every scan-bookkeeping row;
• the Apple revocation handle, if you have one — and before deleting it we present it to Apple and ask Apple to revoke your sign-in, so that Pilcrow stops being listed under Settings › your name › Sign in with Apple. If Apple cannot be reached, your account is still deleted here: we will not hold your data hostage to somebody else's outage.

Three things it does not do, and you should know all three:

• It does not delete your course material, because that material is on your phone and our server cannot reach it. Delete the app, or delete the courses in it, to remove that.
• It does not cancel your Apple subscription. Only Apple can do that — Settings › your name › Subscriptions on your device. Deleting your account while a subscription is running means you keep paying for nothing, so cancel first.
• It does not reach our log store. What is in there is the fingerprint of your address rather than the address, plus request lines, and all of it is deleted 31 days after it was written. See your address in our logs.

A deleted account can survive in a nightly database backup for a little over a fortnight, until the sweep that deletes every dump more than 14 days old reaches it. If you would rather email than tap, write to hello@aktasfatih.com from the email address on the account.

Your rights

Wherever you live, the same things are true here. You can ask what we hold about you and get a copy of it. You can ask us to correct it. You can erase it yourself, in the app, without asking anyone. The whole procedure is an email to hello@aktasfatih.com from the address on your account — the same monitored mailbox named in Who we are — or the in-app delete for erasure. There is no charge, no form and no hoop, you do not have to explain why, and we answer within 30 days. We do not make automated decisions that have a legal effect on you.

One thing we cannot correct, wherever you are. We cannot move an account to a different email address. That address is the only proof we have that the account is yours, so changing it on request is exactly the takeover the design prevents — there is no second factor behind it to fall back on. If the address on your account is wrong, the fix is to delete the account and sign up with the right one, and we will do our end of that for you if you ask. Everything else we hold, we will correct.

What differs between the two laws that reach us is where those rights come from and what else comes with them. They are built differently enough that flattening them into one list would misdescribe both, so they get a section each, and neither repeats the paragraph above.

If you are in Canada: PIPEDA

PIPEDA is a consent statute rather than a lawful-basis one. It does not ask us to pick a justification off a list; it asks whether you knew what you were agreeing to and agreed to it. What you are agreeing to is this page, which is why it is written to be read before you hand over an email address rather than filed after. Everything we collect is collected to run the service you asked for, and we do not require you to consent to anything beyond that — there is nothing else here to consent to, because there is no advertising, no analytics, no profiling and nothing sold to anyone.

Seeing what we hold. Ask us in writing and we will tell you whether we hold personal information about you, give you a copy of it, and account for what it has been used for and who it has been disclosed to. PIPEDA sets 30 days as the limit, which is the same 30 days promised at the top of this page. It also allows an organization to take up to 30 more in limited circumstances; we do not expect ever to need that, because what we hold is an address, a plan and counts and none of it takes a month to print. If we ever did, PIPEDA requires us to tell you inside the first 30 days, with the reason, and to tell you that you can complain to the Commissioner about the extension itself. A refusal would likewise have to be in writing, with its reasons and with your recourse set out.

Correcting what we hold. Show us that something we hold about you is wrong or incomplete and we will amend it — with the one exception set out above, which is the account's own email address. If you challenge something and we do not amend it, we record the challenge alongside the record and pass its existence on to anyone we had disclosed the information to.

Taking your consent back. You can withdraw consent at any time, and it is worth being exact about what that means here. Everything we hold is what makes the account work, so withdrawing consent to it is deleting the account — which is one tap in the app, and immediate. There is no partial switch to turn off, because there is no part of what we hold that is not the service itself.

Two honest differences from the GDPR. PIPEDA has no general right to erasure, and the data-mobility provision Parliament has enacted is not in force and would not be a GDPR-style portability right if it were. We give you erasure anyway — it is the delete button — and we will export what we hold if you ask. Those are things we do, not things PIPEDA obliges us to do, and we would rather say so than let you assume a statute is standing behind them.

PIPEDA's ten fair information principles are the frame the rest of this page is built on. Rather than restate the page underneath them, here is where each one is discharged:

If you are in the UK or the EEA: the GDPR

On top of the rights everyone has, you have the right to have your data given to you in a portable form, and to restrict or object to how we use it.

The GDPR, unlike PIPEDA, asks us to name a basis for each thing we hold:

Complaining

If you think we have handled your data badly, tell us first at hello@aktasfatih.com. We would rather fix it than be told about it by a regulator, and it is much the faster way to get it fixed.

In Canada you can complain to the Office of the Privacy Commissioner of Canada, which oversees PIPEDA: their complaint page at priv.gc.ca, or 30 Victoria Street, Gatineau, Quebec K1A 1H3, or 1-800-282-1376. The Commissioner can decline a complaint you have not first put to the organization it is about, which is the only reason the paragraph above comes first.

In the UK or the EEA you can complain to a data protection authority — normally the one where you live, where you work, or where the problem happened. You do not have to raise it with us first.

Where your data goes, and what follows from that

The providers named above process data outside Canada — and, if you are in the UK or the EEA, outside those too — principally in the United States. Cloudflare is the one that does not sit still: it is a US company, but it handles each request at whichever of its data centres is nearest the phone making it, which may be in your own country or in another one. Two separate things follow.

Under PIPEDA we remain accountable for your data wherever we send it, and for the providers that process it on our behalf we use each one's own data processing terms to require comparable protection of it. Apple is not one of those, for the reason set out two paragraphs down. That does not put it beyond the reach of the country it is sitting in: while it is there it is subject to that country's law, including access by its courts and its law enforcement, and no contract we sign changes that. You should know it rather than discover it.

And for UK and EEA users the transfer out of the UK or the EEA is its own question with its own answer. For Anthropic, Cloudflare and Purelymail — the three that process data on our instructions — it relies on the Standard Contractual Clauses in each provider's own data processing terms.

Apple is the exception, and it matters which kind. Apple is not our processor in either of the roles it has here. It sells and bills the subscription as the seller of record, and it runs Sign in with Apple under the Apple Developer Program License Agreement — in both it decides for itself what it does with the data, which makes it an independent controller rather than somebody acting on our instructions. So there are no Standard Contractual Clauses between us covering it, because SCCs are not the instrument for that relationship. What governs Apple's handling of your data, including any transfer of it, is Apple's own arrangement with you under Apple's privacy policy. Our side of it is what this page describes: the identifier and address Apple gives us, and the two calls we make to Apple, listed in Who else touches your data.

Children

Pilcrow is built for university and college students. It is not intended for children under 13, we do not knowingly collect anything from a child under 13, and there is nothing in the app aimed at them. If you believe a child under 13 has an account, write to hello@aktasfatih.com and we will delete it.

Between 13 and the age of digital consent where you live (13 to 16 depending on the country), use the app with a parent's or guardian's permission.

Student data, and schools

Our position, in case an institution asks. Pilcrow is a tool a student buys and installs themselves; we have no relationship with any school, we are not a school official under FERPA, and we are not operating a school service on any institution's behalf. A student's course material never reaches us, so we hold no education record. What we hold is an email address, a plan, and counts. A photograph a student takes may incidentally contain their own coursework or grades, and that photograph is not retained by us. We have no contract with any institution and are not offering to sign one; if a school needs a vendor agreement before its students may use a tool, Pilcrow is not currently able to be that vendor.

Security

• Traffic between the app and our hosted service is encrypted in transit (HTTPS), on two legs rather than one. The certificate your phone checks is Cloudflare's, because their proxy stands in front of our service and unwraps the connection there; the leg from Cloudflare to our server is encrypted again under our own certificate. What that costs you in plain terms is in Cloudflare, specifically. Pilcrow can also be pointed at a server you run yourself on your own network, and there it is only as encrypted as you make it.
• Passwords do not exist here, so they cannot be stolen. Session tokens are stored only as hashes.
• The database has no address on the public internet: nothing outside the private network it runs on can reach it at all. The application is the only part of this service that is published.
• Per-account rate and spend limits are enforced server-side, so a stolen session cannot run up an unlimited bill.

No system is perfect. If you find a security problem, please tell us at hello@aktasfatih.com before telling anyone else, and we will credit you if you want the credit.

If our safeguards are ever breached. PIPEDA requires us to report a breach to the Office of the Privacy Commissioner of Canada, and to tell you directly, whenever it is reasonable to believe the breach creates a real risk of significant harm to you — as soon as we can, and with enough detail for you to act on it. It also requires us to keep a record of every breach of our safeguards, reportable or not, for 24 months. Where the GDPR applies we would notify the relevant supervisory authority within 72 hours as well. What you would get from us is what happened, what of yours was in it, and what to do about it.

Changes to this policy

The version on this page is always the current one, and it carries the date it took effect. If a change materially affects what we collect, who receives it, or how long we keep it, we will email everyone with an account at least 14 days before it takes effect, at the email address on their account. Small corrections — a clearer sentence, a fixed typo — just change the date.