The constraint that shapes all of this
We cannot read your file after it is encrypted. That is the product, and it means our enforcement options are genuinely narrower than most services'. We cannot review a file on request, cannot investigate a complaint by opening it, and cannot filter by content after sealing. We can delete, and we can preserve records.
We would rather say that plainly than imply a moderation capability we do not have.
What you may not seal
- Child sexual abuse material. Sealing it here is prohibited absolutely, and we report what we can to the appropriate authority — but read the next section, because we cannot detect it.
- Material you have no right to submit — someone else's work, passed off as yours to seal.
- Content whose possession or distribution is itself illegal under UK law.
- Anything intended to harass, defame or endanger a specific person.
Sealing a file does not publish it. Nothing you upload is visible to another customer, indexed, or shared. That is why the list is shorter than you might expect: most of what an acceptable use policy normally guards against depends on an audience, and there isn't one.
We do not know what is in your file
No check is run on the contents of anything sealed here. Before encryption there is one automated pass, in memory, and all it does is compute the SHA-256 fingerprint your certificate carries. Nothing reads the file, nothing classifies it, no person sees it, and nothing about the contents is recorded anywhere.
After that pass, checking becomes impossible rather than merely absent: the file is encrypted with a key we do not hold. So this is not a control we have chosen to leave switched off — for all but a few seconds of a file's life here, there is nothing we could switch on.
We would rather state that than describe a screening capability we do not have. It also means we cannot tell you what is in a file, confirm a suspicion about one, or act on a report by opening it. What we can do is set out below.
Reporting something
Email support@madebyahuman.global. Include the certificate reference if you have one — it is the twelve characters printed on the card and in the file's address.
What happens next, and what will not:
- We will read your report and act on it. A person, not a queue.
- We cannot open the file to check your claim, so our decision rests on what you can show us from outside it.
- Where a report is credible and specific, we delete the stored file and retain the seal record, which is not readable and not the content.
- Where a report concerns illegal material, we act on it and cooperate with the appropriate authority.
- We will not tell you what was in the file, because we do not know.
Requests from law enforcement
We will respond to lawful requests and give what we hold: the fingerprint, the date, the order's email address, and the encrypted bytes.
Once the key is destroyed we cannot provide the contents of a file, and cannot be made to. There is nothing left to hand over and no process by which we could produce it — a property of the system's design, decided and documented before any request arrived, not a position we adopt when one does.
Until then there is a window, and we will not pretend otherwise. We hold a copy of the key from sealing until the customer has their certificate in hand — days rather than months, and the exact periods are set out in our terms. During that window a lawful order would reach that key. An absolute claim with an unstated exception is worse than no claim.