SealRelay — vulnerability disclosure policy

sealrelay.quicktoolry.com serves these pages to the public. The matching service behind them is not running yet, so there is no live lookup to test — but everything actually served here is in scope, and a finding in it is worth reporting today. There is not yet an address to send it to; that gap, and what to do about it, is in how to report.

Safe harbor

Good-faith research will not be pursued

If you research, find, and report a security weakness in SealRelay while following this policy, the operator will treat your work as authorised. Specifically, the operator will not initiate or support a civil claim, a criminal complaint, or a complaint to your employer or your hosting provider against you on account of that research, and will not treat your access as unauthorised under any acceptable-use or terms-of-service clause that would otherwise apply.

Good faith means, concretely: you stopped as soon as you had enough to demonstrate the problem; you did not access, copy, alter, or keep another party’s data beyond the minimum needed to show the weakness is real; you did not degrade the service for anyone else; you did not extort, and you did not publish the details before we had a chance to fix them.

If you are unsure whether what you are about to do falls inside this clause, ask us first, over the channel below, and describe what you are planning. Asking first is never held against you.

This safe harbor is what the operator itself commits to. It cannot bind a third party. If your testing reaches infrastructure or software that belongs to someone else — a hosting provider, an upstream library, a Part A or a Part B organisation running its own systems — this clause does not speak for them, and their own rules still apply to you. Where we can tell that a report you sent us is really about a third party, we will say so, and we will help you reach them.

If a legal action is nonetheless brought against you by someone else for research that we can see followed this policy, tell us. We will confirm, in writing to whoever needs it, that the research was authorised under this policy.

Scope

SealRelay is a matching service. The interesting failures are the ones that break a property the protocol claims: that the operator never holds the Subject’s raw identity, that a match is pairwise and there is no global Subject key, that the four subject-side NO answers are indistinguishable, and that a lookup answer cannot be joined back to a Subject.

In scope

The matching service and its public API, SDK, and MCP surface.
Anything that lets a party recover, or narrow down, a Subject’s raw identity from what SealRelay holds or returns.
Anything that makes the four subject-side NO answers distinguishable from one another, by status, body, timing, size, or side channel.
Anything that lets one Part A learn that a Subject was looked up by, or attested about by, someone else.
Anything that lets a lookup or a billing record be joined to a Subject.
Weaknesses in the cryptographic construction: the pairwise commitment, the audit token, the per-participant-per-domain-per-epoch key, epoch shredding, or the transparency log and its inclusion proofs.
Anything that lets a log be served with two different heads without that being detectable, or that defeats the witness liveness signal.
Authentication, authorisation, and tenancy boundaries between Part A organisations and Part B organisations.
The published client code, and any mismatch between published source and what is actually running.
This website, where a weakness in it could affect a reader of an answer.

Out of scope

Anything that requires physical access, social engineering of staff, or phishing a real person.
Denial of service, volumetric load testing, and anything that degrades the service for other users. Report the design weakness that would allow it; do not demonstrate it against the live service.
Systems that are not ours. A Part A or Part B organisation runs its own systems; a hosting provider runs theirs. Report those to them.
Reports generated by a scanner with no analysis attached, and findings that amount to a missing hardening header with no path to impact.
Weaknesses in software we depend on that are already public and already have an upstream fix pending — though telling us is still welcome, and we would rather hear it twice than not at all.
The fact that a YES is only a technical hit and does not prove the underlying fact is true. That is a deliberate property of the product, described on the front page, not a weakness.
The fact that the operator cannot recover a shredded epoch key or delete a copy Part B already fetched. Both are deliberate, and both are documented.

If something falls between these two lists, send it. We would rather triage an out-of-scope report than never hear about an in-scope one.

How to report

Reports go over the security channel below, to the operator directly. Encrypt it if the finding is sensitive — the key fingerprint is published alongside the address.

Security contact: Not yet published. A dedicated security address on this host. It is not registered yet, and no address is printed here, because an address printed before it is watched drops mail silently.
Encryption key: Not yet published. A public key and its fingerprint, so a report can be encrypted before it is sent.
Machine-readable pointer: A security.txt at the well-known path will point at this page and at that address, from the day the address exists.

This is the gap in this policy, and it is stated rather than hidden: the site is live and there is not yet an address to send a report to. If you have found something in what is served here, hold it, do not publish it, and check this page — the address goes here the moment it is watched. The safe harbor above already covers the research you did to find it.

What to put in the report

What breaks. Name the property you think fails — for example “the four NO answers are distinguishable by response timing” — rather than only the symptom you saw.
How to reproduce it. Exact steps, requests, or a small script. If it needs a specific state, say how to reach that state.
What it lets an attacker do. Who has to be malicious, what they need to start with, and what they end up with.
Where you tested. Which host, which version if you know it, and roughly when.
How you want to be credited, or that you would rather not be. Either is fine.

Write in English or Norwegian. A short report that is clear beats a long one that is not, and a report you are unsure about is still worth sending.

Rules while you are testing

Use your own accounts and your own test data. Do not use another party’s Subject, attestation, or lookup as your test material.
Stop at proof. Once you can show the weakness is real, stop — do not pivot deeper, do not persist access, do not go looking for what else is reachable.
Do not keep what you found. Delete any data you touched that is not yours, and tell us in the report that you have.
Do not degrade the service. No load testing, no automated fuzzing against the live service without asking first.
Give us a chance to fix it before you publish. We will not ask you to stay quiet forever, and we will not ask you to withdraw a publication. See below.

What you can expect from us

A human reply. A person reads your report and writes back — not an autoresponder, and not silence.
A verdict, with reasoning. We will tell you whether we reproduced it, whether we agree it is a weakness, and how we rated it. If we disagree with your assessment we will say why, in enough detail that you can argue back.
To be told when it is fixed, and what the fix was, so you can check it yourself.
Credit if you want it. We will name you in the fix note, under whatever name or handle you give us, or leave you out entirely if you prefer.
Coordination on publication, not suppression. Tell us when you intend to publish. We will work to the date you set, and we will tell you honestly if a fix will not be ready by then and ask — ask, not demand — for more time, with a reason. If you publish anyway, that does not cost you the safe harbor above.
An honest answer about breach notification. If your finding shows that personal data was actually exposed, we will say so, and the operator’s own notification duties are handled separately from your report and are not your responsibility.
To be told if it is not ours. If the report is really about a third party, we will say so plainly rather than sit on it, and help you reach them.

There is no bug bounty. SealRelay does not pay for reports, and this policy does not promise money. We would rather tell you that up front than let you discover it after the work is done.

What this policy does not promise

No response time. SealRelay is operated by one person. Promising that a report will be acknowledged within some number of hours, or fixed within some number of days, would be a number we could not stand behind — so this policy does not state one, and you should not read one into it. What we do commit to is that a person reads every report and writes back.

No triage window, no fix window, no service-level commitment of any kind. Not for acknowledgement, not for a verdict, not for a patch.

No promise that everything gets fixed. Some findings will be accepted and not fixed — because the cost outweighs the risk, or because the behaviour is deliberate. When that happens we will tell you it was accepted rather than quietly close the report.

This is a draft of the vulnerability disclosure policy. The site it covers is live; the matching service it describes is not running yet, and no reporting channel is open yet.