What we hold about you

Who is responsible for this

The business that will run this catalogue has not been formed yet. Until it exists there is no entity name or address to publish here: TBC — Name and postal address of the business responsible for this catalogue (awaiting operator)

That is not a formality on this page. Some of the questions below — how long records are kept, and whether one particular record can be deleted on request — are answered by counsel acting for that business, and it does not yet have counsel because it does not yet exist.

Kept in your browser, not sent to us

• Your entry acknowledgement. When you confirm you are 21 or over and that you are here for laboratory research use, that confirmation is written to your own browser and never leaves your device.
• The date of birth you type at the entry gate. The day, the month and the year are written to your own browser as you typed them — not turned into a fingerprint, not reduced to a yes-or-no. They are kept in two places there: one that survives closing the tab, so you are not asked for the date again, and one that lasts only as long as that tab, which is where the order form reads it from. This is the one thing in this list that can later be sent to us. It reaches us only if you submit an order request, and what happens to it then is set out in If you submit an order request. Clearing this site's stored data in your browser removes both copies.
• Your basket. The items you add are held in your own browser so the list survives a page reload. Nothing is sent to us until you submit a request.
• Your sign-in session. Once you sign in, your browser holds a session token so you stay signed in between pages. Signing out clears it.

This site sets no advertising cookies and runs no analytics. Nothing here follows you to other sites, and we do not sell or share anything about you with advertisers.

Recorded by the hosting platform, on every page

This site is served by Google Cloud, and its server code runs there too. Google Cloud keeps its own record of the requests it serves — the network address your connection came from, what your browser said about itself, which address was asked for, and when — for every visitor and every page, including this one. That happens in the platform, underneath this site's own code, and it happens whether or not you sign in, send a message or submit anything. We are naming it because it is collection, and a page that listed only what our own code writes would be describing a smaller site than the one you are reading.

How long the platform keeps those logs, and how they may be used, is set by the platform rather than by this site: TBC — Retention and use of hosting and server request logs (awaiting operator)

If you create an account

An account needs two things: an email address and a password. We ask for nothing else — no name, no phone number, no date of birth.

Your password is set and checked by Google's Firebase Authentication service, which holds it in a form this site never sees. Our own pages never read a password, never keep one in memory beyond the moment you press the button, and never write one into any record of ours.

Alongside the address itself we hold:

• whether the address has been confirmed, and when the account was created;
• a record of each request to confirm your address or reset your password, including the one-time link generated for it. Nothing on this site sends email, so those sit in a queue for a person to send by hand;
• a one-way fingerprint of the address, and a one-way fingerprint of the network address the request came from, for each of those requests — so neither the same address nor the same connection can be used to flood the queue. Neither fingerprint can be turned back into a readable list by anything in this system.

What you agreed to when the account was made

Setting up an account records two separate things, and they are separate on purpose.

• The account terms you accepted. One record against your account holding the wording of every statement you agreed to, in full, the version of that wording, and the time our own server recorded it. It is stored as the words themselves rather than as a pointer to a version number, so a later question about what you were shown is answered in the words you were actually shown.
• Each earlier version, kept beside it rather than on top of it. When the wording changes and you accept the new terms, the new agreement is filed alongside the old one instead of replacing it. The earlier record, and its original time, are not rewritten.
• Your answer about marketing. Whether you agreed to be written to, held as a separate record with the wording you were shownand the time. A no is recorded, not skipped — "no" and "never asked" are different facts and only one of them means we may not write to you later. It is optional, and refusing it costs you nothing: the account exists either way.

All three of these are held against your account reference and none of them holds your email address. That has a consequence worth stating rather than leaving to be discovered, and it is said again in the copy and deletion sections below: a request handled from your address alone does not find them.

If you send us a message

The message form records:

• the name and email address you type;
• the subject, the category you pick, and the message itself;
• an order reference, if you choose to quote one;
• your account, if you are signed in and the address you typed matches the one on your account.

If you are signed in you can also reply on a conversation you already started. A reply records what you write, and stores with it the name and address already held on that conversation, so the thread reads as one exchange. It also reopens the conversation. A reply is limited by how many you have already sent from your account, which is counted against your account reference rather than against your address.

We use it only to answer you. A message body is free text, so please do not put anything in it you would not want held — including other people's details.

For a message sent through the form we also keep a one-way fingerprint of the address you used and of the network address the message arrived from, purely to limit how many messages can be sent in a short window. Neither fingerprint can be turned back into a readable list by anything in this system.

A closed message thread becomes eligible for deletion once it is older than an agreed period. That period has not been agreed: TBC — How long a closed message thread is kept before deletion (awaiting counsel)

Whether a period has been set on this build is decided by settings held outside this site's own published code, so this page does not tell you from memory that none is set today. What does not depend on those settings: nothing in this system deletes a message thread on a clock. There is no timed or scheduled job of any kind in what is deployed. The only thing that removes a thread on age is a member of our own staff running it deliberately — and that refuses outright while no period is set, rather than picking a number for itself, and reports what would go without removing anything unless deletion is asked for in as many words.

If you submit an order request

An order request records:

• the email address on your account;
• the delivery name and address you enter — street, city, state, ZIP code and country;
• what you asked for, the quantities, the reference we give the request, and every status it moves through afterwards, with a note of who moved it. That trail of statuses is kept as a separate record attached to the request, not as a field on it. Each step can also carry free text a member of our staff typed at the time, in their own words — there is nothing in this system that restricts what that text may say about you. It is in the copy we would give you, and a deletion keeps it;
• a one-way fingerprint of your account reference, and a one-way fingerprint of the network address it came from, so the same account or the same connection cannot submit request after request. A request that arrives with no signed-in account has no account reference to count against, so it is counted in a single shared bucket that every such request shares — not against anything personal to you. That is how the server counts such a request, not a route through these pages: this site's own checkout will not start one until you are signed in and have confirmed your address, so a request submitted through the site always has an account to count against. Neither fingerprint can be turned back into a readable list by anything in this system.

The record of what you agreed to

Submitting a request writes one record of the conditions you accepted. It is the document we would have to produce if a dispute or a review ever asked what you were shown and what you agreed to, so it is built to be complete and to make a later edit obvious. It holds:

• the wording of every clause you accepted, in full;
• the name you typed as your signature, and — where the name you typed mixes writing systems — a note our server made about that, so the name is never quietly judged on the strength of the alphabet it is written in;
• your date of birth — the day, the month and the year you typed — kept in the record in readable form.It is not turned into a fingerprint and it is not reduced to a yes-or-no. It is also one of the fields the record's integrity seal covers;
• the age floor that was in force when you submitted — 21 or over — stored on the same record, beside the date;
• the time our own server recorded, not your device's clock;
• the network address our server saw the request arrive from, and separately the forwarded-address header your connection carried, which is a claim rather than an observation and is stored as one;
• what your browser said about itself.

Where the date is before it reaches us. You type it at the entry gate, and the order form asks for it again with what you typed already filled in. Until you submit a request it stays in your own browser — set out in Kept in your browser, not sent to us. When you submit, our own server re-reads the three numbers you typed and works the age out itself; the answer your browser worked out is not read.

Correction, 18 August 2026 — this page said the opposite until today. It said no date of birth was held, and that we had never asked for one. One is held, in readable form, as set out above. The old wording is named here rather than quietly swapped.

Not on this record: anything about anyone's health, and no card or bank details.

Checks we run on a request

The delivery name is checked against a denied-party list before a request can be accepted. The check reads the name you already gave and asks for nothing extra. It leaves a record of its own, and that record holds a one-way fingerprint of the name that was checked rather than a second copy of it — but it also holds your account reference in the clear, alongside the outcome and the time. That record is kept separately from your request, and it is one of the things a copy or a deletion does not currently reach — see below.

Money records

We never receive your card number. This site holds no field that a card number, expiry date or security code can be typed into. If a card step is ever offered, those details go into fields served by the card processor's own systems, and the only thing this site receives back is a one-time reference that cannot be turned into a card number.

Whether a card step is offered at all is decided by settings held outside this site's own published code, so this page does not tell you from memory that one is switched off today. What does not depend on those settings: the server code has no way to reach a card processor. Nothing in what is deployed can open an outbound connection to one, and a check that reads every file the server ships — and separately runs the charge code itself with the network cut off — refuses any change that adds the means to. Where a sum is recorded against a request by hand, what is kept is the reference our own staff type and the amount — not an account number.

If an invoice is raised against a request, the invoice itself records the request it covers, the items, the amounts and which member of staff issued it — not your email address. Your address is used to address the message queued to tell you about it, and that queued message is described above.

Where it is held and who can reach it

Records are held in Google Cloud Firestore. The server code that reads and writes them runs in a United States region.

Which region the database itself sits in is set outside this site's own code, so this page does not state it from memory: TBC — Region the customer database is held in (awaiting operator)

No browser can read these records directly. Every read goes through a server check that decides what the caller is entitled to see: you can see your own account, your own requests and your own messages, in a deliberately narrow form, and nothing belonging to anyone else.

When one of our own staff opens a record, that is logged — which member of staff opened which record, and when. That log exists for our own accountability, and it is a record about them as much as about you. It is also, unavoidably, a record that names you: to say whose file was opened it has to hold your account reference and your email address. It is not released in a copy, and it is not removed by a deletion. Both of those are said again, in full, in the section below.

We use Google Cloud to run and host the site and to hold these records. No third party has been appointed to advertise to you or to profile you, and nothing on this site reports what you do here to an advertising or analytics service.

One other party can receive a request straight from your browser, and we would rather name it than let the sentence above read wider than it is. Where a card step is offered, the card fields are not ours: your browser loads a script from the card processor's own systems, and each field is a small page served by the processor and shown inside this one. So the processor's own servers see a request from your browser directly — including the network address it came from and what your browser says about itself — and what you type into those fields goes to them and never to us.

Whether a card step is offered on this build of the site is decided by settings held outside this site's own published code, so this page does not tell you from memory that one is switched off today. It is named here so the paragraph above it is true either way. This page makes no claim to any certification, audit or formal standard, because none has been obtained.

How long we keep it

No retention schedule has been agreed for the records described above: TBC — How long each kind of record is kept before deletion (awaiting counsel)

One thing about it is already settled by how the system is built: the record of what you agreed to has the longest claim on being kept, because it is the only thing that answers a later dispute about what you were shown.

And one thing that sounds settled is not. The queued one-time links are the most sensitive rows here, and it would be reasonable to assume they expire quickly. They do not. Nothing in this system gives a queued link an expiry, and no scheduled job removes one. A queued row is removed only when a deletion is run, and only when that deletion is given the address the row was addressed to — an account reference on its own does not find it, as the deletion section below says in full. When those rows should expire, and what should remove them, is unresolved: TBC — Expiry and automatic removal of queued one-time links (awaiting operator)

Asking for a copy, or asking us to delete

Ask through the contact page and a person will handle it.

A copy. We can assemble what we hold about you. It is built from six sources: your requests, your message threads, the record of what you agreed to for each request, the account terms you accepted and their wording, your answer about marketing, and the list of queued messages addressed to you — and, since 18 August 2026, everything filed underneath each of them.Some values are withheld because handing them over would defeat their purpose or would expose someone else — one-time sign-in links, internal integrity values, and our own staff's identities. A copy says what was withheld rather than quietly leaving it out. Nothing else is held back: there is no separate category of internal note that we look at and decline to show you.

One omission is not announced, and we would rather say so than leave the sentence above sounding absolute. The copy lists the record of what you agreed to for each request. If a request has no such record, the copy simply contains one fewer of them and does not remark on it — so a shorter list is not, by itself, something you can read as meaning every request was accounted for.

The queued messages are found by the address they are addressed to, not by your account. That matters when a copy is assembled from your account reference alone: nothing is addressed to an account reference, so a copy put together that way contains none of them, however many are queued. Give the address as well as the account and they are found.

The account terms you accepted and your marketing answer are the other way round: they are found by your account reference, not by your address. Neither record holds an address to search on. So a copy assembled from an address alone contains neither, exactly as a copy assembled from an account reference alone contains no queued message. Give both and everything above is found. We do not close that gap by asking the sign-in service to turn your address into an account reference, because a copy that read the sign-in account record would be doing something this page tells you it does not do.

Records filed underneath another record used to be outside a copy entirely. Since 18 August 2026 a copy reaches all of them, and this page said the opposite until that day. The wording it carried — that four kinds of record were filed beneath another and that a copy reached none of them — was true of what the system did, and what the system did was wrong. The most obvious casualty was the words you actually typed into the message form: a copy of what we hold about you that leaves out what you wrote is not a narrow copy, it is the wrong document. A copy now asks each of your own records what is filed beneath it and returns whatever it finds.

So a copy now includes the messages inside your message threads — the words you typed and the name and address stored on each one — the trail of statuses attached to each request — including any free text a member of our staff typed on a status move — the money ledger attached to each request, and every earlier set of account terms you accepted. Where one of our own staff replied on a thread, their name and address are withheld from the copy and named as withheld, exactly as every other withheld value is.

A deletion did not change with it, and the two are no longer the same answer. Of those four, a deletion still removes only the messages inside a thread. The status trail — with any free text typed on it — the money ledger and the earlier account terms are kept. What did change is that a deletion now counts them and tells you they were kept, instead of them being invisible to a copy and a deletion alike — which is how all four came to be missed in the first place.

A copy has a ceiling, and it says so by name rather than stopping quietly.There is no limit on how many messages a thread can hold or how long a request's status trail can get. If a copy hits its ceiling reading one of them, it names that exact place in the copy itself, so a partial answer can never be handed to you looking like a complete one.

And if something is filed beneath your records that we have taken no decision about, a copy returns it and a deletion leaves it alone. It is listed by name so the decision can be taken. We would rather show you a record we have not finished thinking about than delete one by accident: a copy is reversible and a deletion is not.

What a copy does not reach, said plainly. It is assembled from the six sources above, and what is filed beneath them, and nothing else. So it does not include: the account record held by the sign-in service (your address as held there, whether it has been confirmed, and when the account was created); the denied-party check record; invoices and payment records; the record that a dispatch hand-off for a request was claimed, which holds the request reference rather than your name or address; the note that a member of our staff released your account to check out, which holds your account reference and the address it was granted for; the log of which member of staff opened your records; the running record of each agreement record as it was written, one entry per request, which holds the request reference, its place in the sequence and a one-way value and nothing of your name or address; or the one-way fingerprints used for rate limiting, which hold no readable address. Ask through the contact page for anything in that list and a person will answer it by hand.

Four things left this list on 18 August 2026, and we name them rather than let the list quietly get shorter. The messages inside a message thread, the status trail on a request, the money ledger on a request and each earlier set of account terms were all on it. All four are in a copy now. A list of what you cannot have is the last place a page should be allowed to shrink without saying why.

Deletion. A deletion removes your message threads and the messages in them; every message queued to your address — not only the one-time links, but the notices queued about a request or an invoice, and the wording of each; the delivery address on each of your requests; your answer about marketing; and your sign-in account itself.

Your marketing answer is deleted rather than kept as a do-not-contact flag, and that is deliberate. It permitted a future message to an account that no longer exists after this, and it settles no past dispute, so there is nothing left for it to be kept for. Keeping a stated preference belonging to somebody who asked to be forgotten, for a purpose nobody could name, is not caution.

It would be untrue to tell you that no trace of your address is left, so here is the narrower claim that is the true one. The marketing record itself holds no address — it is filed against your account reference, and the sign-in account it belongs to goes in the same call — so a flag kept out of it would have nothing left to be matched against. Set against the surfaces a message can be sent from, and only those, and where the deletion is given your address — the case the next paragraph sets out is the one where it is not — no address survives for a suppression flag to protect: the queued messages, the address on each of your requests, and the sign-in account all go. Three records listed further down do keep your address in the clear, and none of them is one of those surfaces — the record of your deletion request, the log of which member of staff opened your records, and the note that a member of staff released your account to check out. None of the three is a list anything sends from: nothing in this system reads an address out of one of them to queue a message.

One case does not fit that argument, and we would rather set it out than leave it to be found. A deletion run against your account reference with no address removes your marketing answer, which is filed against the account, while leaving every message queued to your address standing — exactly as the paragraph below describes. Your stated answer goes and the queue it applied to does not. Whether that is the right way round is part of the same unresolved question recorded below about finding queued messages by account.

The queued messages are found by your address, so a deletion run against your account alone reaches none of them. A queued message carries the address it was addressed to and, for a one-time link, the account it belongs to — but the search that finds them reads the address only. A deletion given an account reference and no address therefore leaves every queued message standing, including the one-time links, and reports nothing missing. Whether that search should also look up the account is unresolved: TBC — Whether a copy or a deletion should find queued messages by account as well as by address (awaiting operator)

Your marketing answer and your account terms are the mirror image: they are found by your account reference, so a deletion run against your address alone reaches neither. Neither record holds an address to search on. What that costs you is not the same for the two of them, and only one of them is a loss. A deletion given only an address leaves your marketing answer standing and reports nothing missing — the same failure as the one just described, with the two handles swapped. Your account terms are the other case: a deletion never removes them whichever handle it is given, as the list below sets out, so what an address-only deletion loses there is not the record but the account of it — it cannot see the record, so it tells you nothing about having kept it. Give both handles and each is found and accounted for. Whether either search should look the other handle up is the same unresolved question as the one above.

What survives a deletion, and why we say so. More survives than the list above removes, and this is the full account rather than the short one:

• The record of what you agreed to. It is chained to the ones around it so that a removal from the middle is detectable. Deleting one would break that chain and would be indistinguishable from someone tampering with the evidence. So we keep it, and we tell you we have kept it, rather than reporting a deletion that did not happen.
• The account terms you accepted, and their wording. Kept on the same footing as the record above, and for the same reason: it is what answers a later question about what you were shown and agreed to, and it cannot be rebuilt once it is gone. Each earlier version filed beneath it is kept with it. This is a retention and we would rather name it than let "a deletion removes your account" read as covering it — your sign-in account does go; the record of what you agreed to does not. Whether that is the right answer in law is the same unresolved question as the one recorded below, not a second one.
• The request itself. The delivery address is removed and the email address on it is cleared, but the request is not deleted: what you ordered, the quantities, the amounts, and the state it was to be sent to all remain. The state is kept deliberately — it is the jurisdiction the sale happened in, which a later tax or licensing question is answered from.
• The record of your deletion request. It holds your account reference and your email address; a deletion log that cannot say who was deleted proves nothing.
• The log of which member of staff opened your records. It also holds your account reference and your email address, for the same reason.
• Records a deletion does not reach at all. The denied-party check record, which holds your account reference; the trail of statuses attached to each request; the money ledger attached to each request, which records amounts charged and sent back; invoices and payment records; the record that a dispatch hand-off for a request was claimed, which holds the request reference rather than your name or address; the running record of each agreement record as it was written, one entry per request, which holds the request reference, its place in the sequence and a one-way value and nothing of your name or address; each earlier set of account terms, filed beneath the one you accepted most recently, which holds that wording and the time you accepted it; the note that a member of our staff released your account to check out, which holds your account reference and the address it was granted for in the clear; and the one-way rate-limiting fingerprints, which hold no readable address; and anything filed beneath one of your own records that we have taken no decision about, which a deletion deliberately leaves alone and names instead. None of these is removed. Of the four kinds of record filed underneath another, a deletion reaches only one: the messages inside a message thread go with the thread, and the status trail, the money ledger on a request and the earlier account terms all stay.Since 18 August 2026 the deletion counts those three and reports them to whoever ran it, with the reason each was kept. Before that they survived without appearing in the report at all, which is precisely how nobody noticed a copy was not reaching them either. The rest of the records in this paragraph are listed here because nothing else lists them.

Whether keeping the agreement records — the one written for each request and the one written when your account was made — is the right answer in law is not settled, and neither is the treatment of the records in the last item: TBC — Whether a consent record may be deleted on request, and on what footing (awaiting counsel)

Your rights under US state privacy law

Everyone who buys from this catalogue is in the United States, so the privacy laws that matter here are the state ones. A growing number of states now have a general consumer privacy law of their own, and we do not give a count here: we have not verified one, and a number on this page would read as a checked fact. They are not identical, and the rights set out below are the ones they broadly share.

Whether any of them binds us is not settled, and we would rather tell you that than write a confident sentence. Most of these laws only reach a business once it is above a size — how many of that state's residents it holds information about in a year, or how much of its money comes from selling data. This catalogue has no customers, and the business that will run it has not been formed. Nothing here is over any of those thresholds today, and no state law has been confirmed to apply to us: TBC — Which US state privacy laws apply to this business, and from when (awaiting counsel)

That is a reason to say what we will do anyway, not a reason to say nothing. Everything in this section is offered to anyone who asks, from any state, whether or not a law compels it. If it later turns out that one does, nothing here has to change.

• Know what we hold, and get a copy of it. What we collect, why, and who can reach it is the whole of this page. What a copy actually contains — and the several things it does not reach — is set out in full in the section directly above, and we would rather you read that than take the word everything from a list of rights.
• Have it deleted. Also set out above, including what survives a deletion and why. A right to ask is not a promise that everything goes, and the section above is the honest account of which is which.
• Have it corrected. Tell us something we hold about you is wrong and we will change it. There is no screen that does this — a person does it by hand, the same as a copy and a deletion. One record cannot be corrected, and we would rather say so here. The record of what you agreed to is chained to the ones around it so that any change to it is detectable, which is the only reason it is worth anything as evidence. Editing it would be indistinguishable from tampering with it. Tell us it is wrong anyway and we will tell you, in writing, that we have not changed it and why.
• Take it with you. A copy is the records as we hold them, not a summary written about them, so it is the same thing you would hand to someone else.
• Opt out of your information being sold or shared. The next section is that, in full.
• Limit what your account credentials are used for. They are used to sign you in and for nothing else. They are never used to work out anything about you, and never shown to anyone outside the people running this catalogue.
• Not be treated any worse for asking. Nothing you are charged changes, nothing you can buy changes, and no request is answered more slowly because of what you asked for.
• Ask us to think again. If we turn a request down we will say why in writing, and you can ask us to look at it a second time.

Two things about this process are unresolved, and both matter more than the list above.

• How we satisfy ourselves that you are who you say you are, before handing over everything we hold about a person. Handing a copy to the wrong person is the worst thing this process could do, and no method has been agreed: TBC — How a person asking for a copy or a deletion is identified before it is given (awaiting counsel)
• How long we take. No response time has been set, and a number invented here would be a promise nobody has made: TBC — How long a copy, correction or deletion request takes to answer (awaiting counsel)

These laws are addressed to an identified business, and there is not one yet. The first section of this page says so and names who owes that answer. When the business exists, its name and address appear there.

Do Not Sell or Share My Personal Information

We do not sell your personal information, and we do not share it for advertising that follows you around other sites. This site sets no advertising cookies, runs no analytics, and reports nothing about what you do here to an advertising or analytics service. Nothing about you has been handed to anyone in exchange for money or for anything else of value.

So there is no opt-out switch on this page, and we would rather explain that than build one. A switch that turned off something we do not do would tell you nothing about what we actually hold, and it would read as a protection while protecting nothing. If that ever changes, this page changes first and the way to opt out appears in this section.

One arrangement is worth naming rather than leaving for you to weigh. Where a card step is offered, the card processor's own systems receive a request straight from your browser — described above, in the section on who can reach your records. We receive nothing in return for that, and it is not advertising. Whether an arrangement of that kind counts as a sale or a share under any particular state's definition is a question we have not had answered: TBC — Whether any current arrangement counts as a sale or a share under state privacy law (awaiting counsel)

To ask for any of this, or to have it confirmed in writing, use the contact page. Give both your email address and your account, for the reason the section above sets out at length: a request made with only one of them silently reaches less than you would expect.

Age

This catalogue is for people aged 21 or over. It is not directed at children and we do not knowingly hold anything about one. Everything listed here is for laboratory research use only, and is not for human or veterinary use.

Changes to this notice

When the open items above are answered, this page changes to say what was answered. The items are shown rather than hidden so you can see what is still unresolved instead of reading a confident page that quietly omits it.