PlateRegistrySign in

Your data

Privacy policy

An email address and a list of plates. That is what this site needs to work, and near enough all it keeps. No advertising, nothing that follows you across sites, no card details, and two cookies that only keep you signed in and the plate checker fair.

Last updated

The short version

We hold your email address, the plates you are watching, and what your subscription is doing. That is genuinely most of it.

We do not see your card. We count page views and how quickly pages load, and that is the whole of our analytics: no advertising, nothing that follows you across sites, no profile of you. There are two cookies: one keeps you signed in, the other keeps the plate checker counting people rather than connections. We do not sell anything about you to anybody.

The one thing that is not about your account: we keep an IP address for a day when someone asks for a sign-in link, and a scrambled form of one when someone tries a plate in the plate box on the home page or the spelling ideas page. Both are there to stop the same person doing it ten thousand times.

We take a nightly backup copy of the database onto hardware we own, and keep each copy for about 30 days. So when this page says something is deleted, it means from the live database: a backup taken before the deletion can still hold it until that backup is deleted in its turn. Close the account and your plates and your email address are gone from the live database at once, and from the backups within about 30 days rather than instantly.

The rest of this page is the same thing, item by item, so you can check it.

What we store, and why

  • Your email address. It is your account name, it is where alerts go, and it is how you sign in. We store it lower-cased.
  • The plates you watch. Both as you typed them (“SO CK”) and tidied up for looking up (“SOCK”), plus when each was added, when we last alerted you about it, when we last told you it had been taken again, and, if you told us you got it, when. The “last alerted” stamp is what stops us emailing you about the same release twice, and the “taken again” one does the same for the email that follows it.
  • Your subscription. Your Stripe customer ID, which plan you are on, how many plates it covers, how often it is billed, the status Stripe reports for it, and, if you have cancelled it, the day it stops. Enough to know whether your list should be running, and to tell you when it will not be.
  • When your account was created.
  • Your session. Not the cookie value itself, but a SHA-256 hash of it, plus an expiry date. A copy of our database does not let anyone sign in as you.
  • Sign-in requests. When someone asks for a sign-in link we store the email address, a folded copy of it (any +tag removed, and the dots taken out of a Gmail address, so the limit counts the inbox rather than the spelling), the IP address the request came from, and the times. The live database keeps that for one day. It is used for one thing: rate-limiting, so nobody can spray sign-in emails at strangers or burn through our email quota. It is not used to profile you, and it is the only place we ever put an IP address next to an email address.
  • Plate checks from the public plate box. Anyone can try a plate without an account, in the plate box on the home page or the one on the spelling ideas page. Both send the same check, so this page calls either one the public plate box. Every try the limit lets through stores two things and the time. If we answered it from our own recent results the row is deleted within a few minutes; otherwise the live database keeps it for one day.

    Neither of them is your IP address. One is a random number we put in a cookie when you check a plate, which means nothing on its own and is not linked to you, your account or anything you do elsewhere. The other is a scrambled form of your IP address, made with a key only this server holds, so a copy of our database on its own cannot be turned back into the address it came from.

    A try the limit turns away stores no row about you at all; it adds one to that day’s count of tries turned away, and nothing else.

    There is deliberately no column for the plate: no row we keep names a visitor and a plate together. (A plate’s own row carries the time it was last checked, so anyone holding the whole database could line the two up by the second, and on a quiet day the per-plate count below narrows it the same way, while these rows last. What we can promise is that we never write the pair down.)

    Separately from those rows we keep two sets of counts, and neither holds anything about anybody: a plain daily count of how many plates were checked in the public plate box and how they were answered, and, so we can see which plates people are looking for, how many times each plate was checked there on each day, with no visitor, address or time of day beside it. Both are in How long we keep it below. The rows themselves do the same one job as the bullet above: rate-limiting. The state’s lookup is the scarce thing here, and the public plate box shares it with the checks paying customers rely on.

  • Plate checks from your dashboard. Adding a plate to your list usually checks it straight away, and that check is counted the same way. The row still has no plate in it, but it is filed under your account number rather than a cookie number and a scrambled address, and the live database keeps it for the same one day (a few minutes if we answered from our own recent results). It is not in the daily counts described above, which are about checks from the public plate box. Closing your account does not remove it early: it runs out its day.
  • Presses of the checkout and billing buttons. Each time you press a button that takes you to Stripe, to check out or to manage your billing, we note your account number and the time, and nothing else, so the buttons cannot be pressed in a loop to flood Stripe. The live database keeps it for one day, and closing your account deletes it there and then.
  • A few internal markers that stop the same thing happening twice: the last time we ran a live lookup for you, the last time we asked Stripe about your subscription and the last time Stripe answered, and which subscription and plan we have already sent you a confirmation for. We also note when your list last switched on or grew, so a plate is not counted as overdue for time it was not being watched. We also note whether you have ever had a plan with us, so the free days are offered once per account. And we count the plates you add, with the time you added the first of them, so one account can only add so many plates in a day. A count runs for one day from that time, and the first plate you add after it starts a new count in its place. It is a number and a time, never which plates.

    There is also a switch we can set by hand to turn an account off under the fair use rules. It is off unless we have had to do that. If we have had to turn an account off under the fair use rules, a scrambled form of its email address is kept after the account is closed, so that closing and reopening does not lift the block.

Two honest footnotes to the plate-checks bullet. The plate you type or pick in the public plate box travels in the web address of the pages after it (/login?plate=SOCK and the sign-in link we email you), so it sits in Vercel’s ordinary server request log beside the IP that asked for the page, like every other address on this site. And an alert email has the plate in it, so Resend sees the plate and your address together. Neither of those is a table of ours, but neither is nothing, so we would rather write it here than have you find it.

The plate records themselves (whether GATOR is taken, when it last changed) are shared by everyone watching them and say nothing about who is watching.

Tracking, and the lack of it

  • We count page views, and how fast pages load. The site runs Vercel’s Web Analytics and Speed Insights: one counts how many times each page was opened, the other records how quickly it appeared on real devices. A page-view report carries the page, the time, the page that linked you here, roughly where you are (country, region and city), and the kind of device, operating system and browser. A speed report carries the page, how fast it loaded, your country, your connection speed and the same device details. Neither sets a cookie, neither follows you to other sites, and in production your browser asks this domain for both scripts rather than someone else’s. Neither is joined up with your account: they tell us a page was opened, not who opened it.
  • We cut the address down before either one reports it. Both would normally report the whole web address of the page you were on, and some of ours carry things that are yours: the one-time token in a sign-in link, or the plate you typed. So the query string is cut off the address we hand them: the beacon reports …/auth/verify, never …/auth/verify?token=….

    That trim is on what those two report, not on everything your browser sends. A browser also puts the whole address of the page you are on into the Referer header of the requests it makes from it. That is why the sign-in page separately tells your browser to send only the site name as its referrer, so a live token cannot ride along in that header either. The two pages with the public plate box do the same, because the box writes the plate into their address as you type. On other pages a plate in the address is not guarded that way, and does not need to be: your browser only puts the whole address in that header on requests back to us, and it is already in our own request log, as the section above says.

  • No advertising, no ad pixels, no session recording, no cross-site tracking. No Google Analytics, no Meta pixel, nothing of that sort, and nothing that tries to recognise you somewhere else. Even the fonts your browser loads are served from this site rather than fetched from Google.

    (One exception, and it is not in your browser: our server draws a picture of a plate for the image in an alert email, and for the preview image when someone shares a link to us, and it fetches that font from Google the first time it does. Nothing of yours goes with that request: it asks for the alphabet, not for your plate.)

    You do not have to take our word for any of it. Open your browser’s network tab and look at what the page loads.

  • Do Not Track. Nothing here tracks you from one site to another, so there is nothing for that signal to switch off. The site behaves the same whether your browser sends it or not.
  • No card details, ever. Paying and managing your plan happens on Stripe’s own pages. Your card number never touches this site, so we could not leak it if we tried.
  • No password. There isn’t one. Sign-in is a one-time emailed link, good for 15 minutes, usable once.
  • No name, address, phone number, date of birth or vehicle details. We never ask, because watching a plate does not need any of it.
  • No selling, renting or sharing your data with anyone for their own purposes. The only companies that touch it are the ones listed below that we need to run the thing.

Cookies: there are two

The first is named session. It is set when you sign in, it holds a random token, and it lasts 30 days or until you sign out. It is httpOnly (scripts on the page cannot read it), sameSite=lax, and sent only over HTTPS in production.

The second is named pr_visitor. It is set when you check a plate in the public plate box, signed in or not, it holds a random number and nothing else, and it expires within a day of your last check. It exists so that the limit on how many plates can be checked can count you rather than your internet connection: phone networks put thousands of people behind one address, and without this the first busy person would use up everybody else’s turn. It is not linked to your account, it is not read anywhere else on the site, and it tells us nothing about you beyond “this is the same browser as a moment ago”. Same protections as the other one: httpOnly, sameSite=lax, HTTPS only.

Both are strictly necessary cookies: one tells us you are signed in, the other keeps the plate checker working fairly, and neither is used for anything else. Neither of the two Vercel beacons above sets one. That is why you have not been shown a cookie banner.

For completeness, a third cookie exists only on the owner’s own admin page. It holds his last search there for fifteen minutes and is never set for anyone else.

We do not use local storage or any other tracking store in your browser.

Who else touches your data

Four companies run the service, each doing one job, and two more handle the mail if you write to us. Nobody else, with one thin exception: our own server fetches a font file from Google when it draws a picture of a plate, as the tracking section says. That request carries nothing of yours, not even the plate.

  • Vercel: hosts the site, runs the checker, and provides the two beacons described above. It keeps ordinary server request logs, and the error lines our own code writes when something fails, in the USA. An error line can carry your account number, your Stripe customer ID, the plate involved, and whatever the failing service said in its error message.
  • Neon: the Postgres database where everything above is stored. Hosted in AWS US East. Neon also keeps its own recovery history of the database for six hours, so that a mistake can be wound back. A row we delete is still in that history for those six hours.
  • Stripe: payments, subscriptions and the billing portal. Stripe gets your email address and what you bought. It also receives your account number, which we file on the customer record and each checkout so we can match Stripe’s records to yours. On its own pages it also collects the cardholder name, the card, and whatever billing details it needs to take the payment; all of that stays on Stripe’s side, and we never see it or store it. Stripe is the payment processor, not us.
  • Resend: sends our email. It handles your address and the contents of the message, which for an alert means the plate that came free. Resend also tells us when a message bounced or was marked as spam. We keep a count of those and nothing else: not the address, and not the subject line it reports.
  • Porkbun, and the provider of our inbox: only if you email us. Porkbun is our domain registrar, and it forwards mail sent to our addresses on to the inbox where we read it, which a separate email provider runs. Between them they handle your address and whatever you wrote. When you email us has the rest.

Our own backup is not a company, but it is a copy, so it belongs on this list. Every night the database is copied onto hardware we own, and each copy is kept for about 30 days. It is held by us and not by another company.

The state registry is not a processor of yours. When we check your list, the FLHSMV’s public lookup page receives plate strings and nothing else: not your email address, not your account, nothing that names you. Our requests do say who we are: they carry a label naming PlateRegistry and our support address, so the state can tell us to slow down or stop rather than quietly block us.

Be straight about what that still leaves visible. The round-the-clock checker only takes on plates that are on somebody’s list, so it asks the state about the same plate again and again, from our server, under that name. Anyone reading the state’s logs could work out from the repetition that a plate we keep asking about is one somebody here is watching. What they cannot work out is who: nothing in the request says whose list it is. A stranger trying a plate in the public plate box arrives much the same way: a bare plate string, from our server, under that same name. Not identical: the checker usually asks about several plates in one request, and a try from the public plate box asks about one. Neither carries anything about a person.

It does not take the state’s logs to notice, either. A plate we have checked recently is answered in the public plate box from our own recent results, which is quicker than one we have to go and ask about, so a patient visitor could guess the same thing. They learn no more than the state would: that somebody may be watching that plate, never who.

We will also hand over data if we are legally required to, and we would tell you unless we were forbidden from doing so.

When you email us, and consultations

Mail to our support address, and mail about a plate consultation, never goes into the database described above. It arrives in an ordinary email inbox that we read by hand, and Porkbun forwards it there, as the section above says.

What is in that inbox is whatever you sent: your address, your words, and for a consultation the word or the name you want on a plate, which can say something about you. A consultation does not need an account. The fee is agreed in that same conversation, and paying it does not go through the checkout on this site, so our database holds nothing about that payment.

Closing your account does not touch that inbox. Mail stays there until we delete it, so if you want yours gone, ask from the address you wrote from.

How long we keep it

  • Sign-in requests (email address and IP): deleted from the live database after one day, by the same job that runs the checks.
  • Plate checks (a random visitor number and a scrambled IP for a check from the public plate box, your account number for one from your dashboard, no plate either way): deleted from the live database after one day too, by that same job, or within a few minutes when we answered from our own recent results.
  • Checkout and billing presses (your account number and the time): deleted from the live database after one day by that same job, or at once when you close your account.
  • Daily counts of public checks: kept indefinitely. One row a day saying how many plates were checked in the public plate box and how they were answered. Counts only: no visitor number, no IP address, no plate, and nothing tied to an account.
  • Counts of checks per plate: kept 90 days. One row per plate per day saying how many times it was checked in the public plate box. No visitor number, no IP address, no time of day, and nothing tied to an account; a plate added from your dashboard is not counted.
  • Expired sessions: cleaned out by that job too, so a session that has run out does not sit around.
  • Your account and your plates: kept while the account exists, including after you cancel and if you never subscribe at all. Your plates are still there if you come back. Close the account and they are deleted from the live database there and then.
  • Our own backups: we take a nightly backup copy of the database onto hardware we own, and keep each copy for about 30 days. So a closed account and its plates age out of the backups within about 30 days rather than instantly. We do not edit a backup to take one person out of it. If we ever had to restore the database from a backup after a disaster, an account closed since that backup was taken would come back with it. If you hear from us after closing your account, tell us and we will delete it again.
  • The shared plate records: not yours to delete, because they are not about you. The same row serves everyone watching that plate and holds no personal data. Once nobody is watching a plate and a week has gone by since we last checked it, the row is cleared out anyway.
  • Aggregate release statistics: kept indefinitely. They are counts of plates, not of people.
  • After deletion: our processors keep their own copies, for their own periods. Neon keeps its recovery history of the database for six hours, so a deleted row is still in that history for those six hours. Stripe keeps its whole customer record of you (your email address and every payment you made) because closing your account here asks Stripe to cancel the subscription but never erases you from Stripe. Resend logs the email it sent. Vercel keeps request logs and the error lines described above. We do not delete any of that on their behalf. Mail you sent us is separate again: it stays in our inbox until we delete it, as When you email us says.

How alerts work

Every email we send is about your own account: a sign-in link you asked for, a plate on your list that just became available, a plate we told you about that has since been taken, or a confirmation of something you did with your subscription. That is transactional email, not marketing.

There is no newsletter and no marketing list. We do not send offers, and we do not pass your address to anyone who does. If that ever changes, it will be something you opt into, not something you have to opt out of.

One mechanical thing worth saying: an alert has a picture of the plate in it, and that picture is served from this site. So opening the email makes your mail app (or the image proxy your provider puts in front of it) fetch a file from us, with the plate name in the address. Nothing on our side counts or records that. There is no tracking pixel, and the route that draws the picture writes down nothing about who asked for it. The request lands in Vercel’s ordinary server log, exactly like any other page on the site.

Your choices

  • Stop an alert: remove that plate from your list in your dashboard. It stops being watched immediately.
  • Stop all alerts: the three ways do not all take effect at the same moment. Remove every plate and the alerts stop immediately. Cancel your plan and the list keeps running to the end of the month, or the year, you have already paid for, then switches off; your dashboard shows the day. Close the account and everything stops there and then.
  • Stop paying: cancel in the billing portal, from the billing page in your dashboard. It stops the next charge; the month, or the year, you have already paid for runs out first.
  • Close your account and delete your data: close your account from your dashboard. It deletes your account, your plates and your sessions from the live database, cancels any outstanding sign-in links, and then tells Stripe to cancel your subscription. If Stripe cannot be reached at that moment the account still closes (we would rather delete you than trap you), and the page you land on says so and asks you to email us, so we can stop the billing by hand. You do not have to ask us to close the account, and we do not make you wait.

    Anything left of your recent sign-in requests is an IP address and a time with no email address on it, and it goes within the day like the rest. If we have had to turn an account off under the fair use rules, a scrambled form of its email address is kept after the account is closed, so that closing and reopening does not lift the block.

    What else is left, and for how long, is in the retention section above: our own backups for about 30 days, the database host’s recovery history, and what our processors keep. Stripe in particular still has its customer record of you.

  • See what we hold: ask at support@theplateregistry.com and we will send you a copy of everything on your account. Same address to correct something that is wrong.

Anything that goes through email we answer ourselves, by hand, so allow a few days. We will ask you to write from the address on the account, because that is the only way we can tell it is you.

Children

The service is for adults: you must be 18 or over to have an account, and we do not knowingly collect anything about children. If you believe a child has created an account, email support@theplateregistry.com and we will delete it.

How this is protected

No dramatic claims here, just what is actually true of the code:

  • The site is served over HTTPS.
  • There are no passwords to steal, because we do not use them.
  • Sign-in links and session cookies are stored only as SHA-256 hashes, so the database never holds a usable credential.
  • Sign-in links die after 15 minutes and cannot be used twice. That matters, because the link carries its token in the web address, so a live one sits in Vercel’s ordinary request log for as long as it is live. Short and single-use is what makes that survivable.
  • Sign-in emails are rate-limited by address and by IP.
  • The session cookie cannot be read by page scripts.

No system is perfectly safe, and we are not going to pretend otherwise. If something does go wrong with personal data, we will email the people affected and say what happened.

Changes to this policy

If we change what we collect or who we share it with, we will update this page, change the date at the top, and email you if the change matters to you. We will not quietly start collecting something new and leave you to spot it.

Contact us

A real person reads this: support@theplateregistry.com.

By post: Jahanzaib Majid, PlateRegistry, 7737 N. University Drive, Suite 104, Tamarac, FL 33321, USA. PlateRegistry is run by Jahanzaib Majid as a sole proprietor, and he is the one responsible for the data described on this page.