Disclosure and claims policy

This policy applies to everything published on the platform: disclosure cases (a vulnerability report coordinated with the affected party under embargo), writeups (a documented finding from a lab, a program or a public vulnerability) and articles (technical prose), and to claims filed against any of them.

It is jurisdiction-agnostic. The platform serves researchers and affected parties in many countries; it enforces one process, described here, and does not apply any national law by itself. National frameworks appear only as orientation in section 9.

The process follows international practice for coordinated vulnerability disclosure: ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), the CERT/CC coordinated-disclosure guidance, and the good-faith security research principles behind most safe-harbor programs. The disclosure window counts from the notification to the affected party, not from the discovery.

Responsibility stays with the reporter. Whoever publishes declares, under a versioned declaration recorded with the hash of its text, that they obtained the information lawfully, coordinated as described here, and answer for the content. The platform provides the process and the tools; it does not take over that responsibility.

Nothing is removed automatically, and nothing is published by the platform. Publication is always an act of the author. Removal, suspension or redaction is always a decision of a moderator adjudicating a claim under the procedure in section 6.

A disclosure case stays private until every one of these conditions holds. The platform enforces them in code, not only on this page:

• At least one documented contact attempt with the affected party. No documented contact, no publication — nothing waives this condition, not even a moderator.
• At least 90 days since the first documented contact.
• At least 30 days since the case was filed on the platform. This is the platform's own clock: the contact log can legitimately record dates earlier than the case, but the time since filing cannot be back-dated.
• Any agreed embargo has expired. Either party may propose an embargo date, or propose lifting it; the other party accepts or rejects, and the log records both. While no affected party has taken the seat, the embargo is the author's own commitment and the author sets it directly.
• The author accepts the publication declaration in force, taking sole responsibility for the content.

The only way past the time conditions is a patch confirmed by the affected party — confirmed by the person holding the affected party's seat, not declared by the author — which unlocks “publish now”. The contact condition still applies.

Moderation exception. A moderator may record, with a written reason that goes into the case log, that the author may publish before the time conditions are met — for example when coordination demonstrably happened outside the platform. The exception never waives the contact condition and never publishes anything: the author still has to publish and sign. Moderators cannot publish a case.

The case lifecycle is Reported → Acknowledged → Remediating → Patched → Published, with the Disputed and Won't fix branches. Only the author and the accepted affected party advance the state; moderators may intervene for moderation (suspension, exception, removing a contact) but not to publish. An objection filed by the affected party before publication (section 6) holds publication until a moderator resolves it. Every change is recorded in the case log.

How the case ended is shown on the public page. A case published from “Won't fix” carries a notice that the affected party declined to fix the finding; a case published after the window elapsed with no acknowledgement or reply from anyone carries a notice that the affected party did not respond. A patched case says whether the patch was confirmed by the affected party or only declared by the author.

The author records every contact attempt and reply with its date and channel and, privately, the counterparty and notes. The platform does not verify these entries, with one exception: when the author delivers the report to the affected party through the platform, the platform itself records the delivery and its date. The log is append-only; a correction is a new entry.

Entries dated before the case was filed are marked “logged after the fact” in the log and on the public timeline: they rest on the author's word alone. The public page shows only the kind, channel and date of each entry; counterparties and notes stay private to the parties.

Each case has one seat for the affected party's contact. Whoever holds it reads the full report, advances the state, confirms a patch, negotiates the embargo and can object to the report before it is published. Everything they do is recorded in the case log under their account.

The seat requires standing. It can be taken by an account whose affiliation to the affected organisation is verified — by a corporate e-mail domain the organisation listed, or by a moderator — or by the person a delivery link was addressed to. Naming someone as contact only proposes them: until they accept, they see the case's metadata and nothing of the finding.

What the platform certifies is limited to that. A verified affiliation means the account belongs to the organisation's domain or was confirmed by a moderator; it does not mean the person is authorised to speak for the organisation. A proposed contact may decline; the author may remove a contact who has not accepted; a moderator may remove any contact with a reason in the log. Verified members of an organisation also see, in their inbox, the cases delivered to it through the platform.

A writeup is a documented finding that publishes without coordinating a case. That is only acceptable when the finding has one of these disclosure bases, which the author states and a moderator checks before publication:

• Lab or CTF. A capture-the-flag or training target: no third party is affected.
• Resolved bug bounty report. A report resolved in a program whose rules allow disclosure, with a link to the report or to the program's disclosure policy.
• Already public vulnerability. A CVE id or a published advisory.
• Disclosure case on this platform. The writeup documents a case and publishes with it, under the case's conditions. Once submitted, the link to the case cannot be removed by the author.
• Other, explained in the reference; a moderator decides.

Submitting a writeup for review requires the basis, its reference where the basis calls for one, and the author's acceptance of the writeup declaration in force. Moderation checks the form of the writeup (reproducible proof of concept, consistent severity, no sensitive data) and that the stated basis matches the content and its reference. A finding on a third party's live system with none of these bases belongs in a disclosure case.

Articles are technical prose. They publish without prior review, after the author has accepted the article declaration in force (once per author and version of the text). An article must not disclose an unpatched vulnerability in someone else's system; that belongs in a case, or in a writeup with a basis.

Claims (section 6) apply to writeups and articles exactly as they apply to cases.

If you are the affected party, or connected to the system a publication describes, you have three routes. All of them are adjudicated by a moderator; none removes anything by itself:

• Takedown. You ask for the publication to be taken down. If the moderator upholds it, the publication stops being visible.
• Dispute. You contest the accuracy of the publication without asking for its removal. This is your right of reply: the moderator may show your reply next to the publication, and the author may answer it.
• Redaction. You ask for specific data to be removed — personal data, credentials, still-exploitable detail.

Who may claim. Anyone, on public content, including anonymously. On content that is not yet public — an embargoed case, a draft — only someone with standing: the accepted affected-party contact, a verified member of the affected organisation, or the recipient of a private link who opened it. A claim filed before publication holds the publication until it is resolved.

Procedure. The claimant states their relationship to the system, the justification, an optional legal ground and jurisdiction, and evidence. They receive a receipt by e-mail with a private link to follow the claim, from which they can confirm their address. The author of the publication is notified at once and may reply. A moderator may provisionally suspend the publication while adjudicating, and decides with a note; the decision is shown to the claimant and to the author.

Effects. An upheld takedown hides the publication. An upheld dispute records the decision and may show the affected party's reply, without removal. An upheld redaction suspends the publication until the author removes the indicated data and a moderator restores it. A case and the writeup that documents it are one finding: hiding or suspending one hides or suspends the other.

The claim, the evidence and the decision are kept as the file backing the decision, even if the publication is later deleted by its author.

UID Disclose is a neutral intermediary that hosts content published by third parties. Moderation reviews the form of a writeup and whether its stated disclosure basis matches its reference; it does not verify the lawfulness of the access behind a finding, the truth of a statement about an affected party, or the completeness of a contact log. The “technically verified” label a moderator may attach to a writeup means its technical content was checked; it is not an endorsement of its lawfulness or of any statement about the affected party.

Liability for a publication rests solely with whoever publishes it, as they declare when publishing. The platform responds to claims through the procedure described here, keeps the adjudication files, may suspend accounts that repeatedly publish in breach of this policy, and cooperates with lawful requests from competent authorities.

To operate this process the platform keeps:

• Account data: e-mail address, display name and handle, verification and sign-in method, language preference.
• Declarations accepted: the document type and version, a hash of its exact text, the time and a hash of the IP address, linked to the case, writeup or article it covers.
• Case logs and contact logs, append-only, for the life of the case; the public page shows only what section 3 describes.
• Claims: the claimant's name, e-mail address and organisation, the relationship and justification, the evidence, a hash of the IP address, the author's reply and the decision — kept after the publication is deleted.
• Access to private links: a hash of the IP address and the outcome of each attempt to open a delivery link.
• Moderation records: review decisions and checklists, kept after the publication is deleted.

Authors may delete their own drafts, unpublished writeups and articles. A published disclosure case is the record of a coordination between two parties and is not deleted by either of them; personal data that should not be there is removed through the redaction procedure. Requests concerning personal data are handled through the contact channel to be published on this page before launch.

These notes are for orientation. They are not legal advice, they may be out of date, and they do not determine the law that applies to the platform. The reporter is responsible for the law that applies to them and to the affected party.

• Chile. Law 21.459 on computer crimes, as amended by Law 21.663 (cybersecurity framework), provides an exemption for good-faith vulnerability research subject to cumulative requirements, including notifying the national authority (ANCI) and not going beyond what is needed to prove the finding; the case's legal-basis panel records the authority notification and the researcher's registry id. Personal data: Law 21.719.
• Argentina. Unauthorised access to a restricted-access computer system is a crime (Criminal Code art. 153 bis). There is no general statutory safe harbor for security research: written authorisation or a program's rules are what keep the access lawful. Personal data: Law 25.326.
• Mexico. Unauthorised access to, or modification of, information in systems protected by a security mechanism is a federal crime (Federal Criminal Code arts. 211 bis 1 and following). There is no general statutory safe harbor: obtain authorisation first.
• United States. The Computer Fraud and Abuse Act applies. Since 2022 the Department of Justice's charging policy states that good-faith security research should not be prosecuted under it, and many programs publish safe-harbor terms; that policy is not a defence in civil claims.
• European Union. The NIS2 Directive (2022/2555) requires member states to adopt coordinated vulnerability disclosure policies, with a national CSIRT as coordinator; criminal law on unlawful access remains national (Directive 2013/40/EU). Personal data: GDPR.

This policy and the declarations are versioned. A change to a declaration is a new document: authors are asked to read and accept the new version before their next publication, and earlier acceptances keep pointing at the text they accepted. Material changes to this page are announced on the platform.