Receipt methodology, version 1
SignedByAHuman makes a person's declaration about specific text inspectable. This page explains the cryptographic record, every verification signal, the 365-day retention period, and the limits a reader should keep in mind.
The trust boundary
"Proves" is intentionally narrow here. The cryptography can show that recorded data has not changed without detection. It cannot make the signer's underlying statement true.
Receipt lifecycle
The service binds a claim, text fingerprints, verification signals, and time data into one signed statement. The hosted receipt then presents that record through a public URL.
The signer says they stand behind the text, wrote it, or witnessed it.
The browser and server calculate strict and formatting-tolerant SHA-256 fingerprints.
Turnstile is required. Optional account, phone, passkey, and payment checks can be attached.
The server signs the statement and returns a public receipt URL with a 365-day expiry.
Verification signals
Each signal adds a different kind of evidence or friction. None is a probability that the text is human, true, or responsibly made. A listed method means that check succeeded for that receipt.
Cloudflare Turnstile checks the issuance interaction. The current flow fails closed: a new receipt is not issued if verification fails or the provider is unavailable.
Does not mean: a named identity, human authorship, or truth.
A successful Google or Apple sign-in shows control of that provider account during the signing flow. Email address or profile image appears only when the signer chooses public disclosure and the provider returns it.
Does not mean: the account maps to a verified legal identity.
A one-time code shows access to a phone number during the signing flow. The service stores a hash for the proof; the full number is public only if the signer explicitly discloses it.
Does not mean: the phone owner wrote or approved the content honestly.
A WebAuthn ceremony shows successful use of an authenticator with local user verification for the content-bound challenge.
Does not mean: a stable named identity or proof of authorship.
A listed Stripe payment method means a completed payment proof was bound to the receipt's content fingerprints and consumed when the receipt was created.
Does not mean: identity, accuracy, good faith, or higher truth.
A salted IP hash is used for rate limiting and abuse prevention. It is operational metadata and is not presented as a public identity signal.
Does not mean: one person, one device, or one permanent identity.
About the interface score: if a receipt shows a point total or strength tier, treat it as a summary of configured verification friction. It is not an authorship confidence percentage, truth score, identity probability, or endorsement. The individual listed signals are the meaningful evidence.
Tamper evidence
The fingerprints answer whether text matches the recorded content. The ECDSA signature answers whether the receipt statement has been changed since the SignedByAHuman server signed it.
Line endings are first made consistent by replacing Windows and older Mac line endings with a line feed. SHA-256 is then calculated over the UTF-8 text. Other characters, spacing, punctuation, and case remain significant.
Interpretation: a strict match is the strongest available content match.
The normalized path makes line endings consistent, applies Unicode NFC normalization, removes spaces and tabs at the end of each line, and removes trailing newlines. It does not lowercase the text or remove punctuation, internal spacing, word boundaries, or meaningful line breaks.
Interpretation: a normalized-only match tolerates these defined formatting differences and should be labeled as weaker than an exact match.
The service serializes a stable JSON statement containing the fingerprints, claim, verification mode, listed methods, key identifier, issue time, and expiry time. The server signs those bytes with ECDSA on the P-256 curve using SHA-256.
Changing a field in the statement changes the signed bytes and causes signature verification to fail.
The active verification key is published as a JWK. A verifier needs the original statement bytes, statement signature, and the public key matching the statement's key identifier.
Open the public-key endpoint or use the API alias.
Independent verification boundary: the hosted receipt view is served by SignedByAHuman. The raw receipt response includes the statement and signature, and the public key is published separately, so another verifier can check the signature. The site does not currently advertise a versioned archive of retired keys. A long-term verifier should preserve the public key matching each receipt's key identifier.
Public data and retention
Expiry is an availability limit, not proof that the declaration became false or was revoked. At or after expiry, the service removes the receipt record and its public lookup no longer succeeds.
Verification proof records used during OAuth, payment, SMS, and passkey flows have shorter operational lifetimes. The Privacy Policy lists the current retention periods and public-data choices.
Threat model
The product reduces some forms of silent alteration and automated abuse. It still depends on honest declarations, secure accounts and devices, the service's signing-key custody, and careful receipt reading.
| Threat or failure | Mitigation in the current design | Residual risk and reader action |
|---|---|---|
| Text changed after signing | Strict and normalized SHA-256 fingerprints allow the verifier to detect a mismatch. | Verify the text, not only the presence of a badge or link. A normalized-only match is weaker than a strict match. |
| Receipt fields edited | The server signs the stable statement with ECDSA P-256 and publishes the verification key. | The hosted UI is still served by the operator. Independent assurance requires checking the raw signature with the matching key. |
| Automated mass issuance | New receipts require Turnstile and are subject to IP-based rate limits. Optional payment adds economic friction. | Bot checks and rate limits are not perfect. They do not identify the signer or prevent coordinated human abuse. |
| Signer lies about authorship or review | The exact claim is shown publicly, creating an attributable declaration when identity signals are disclosed. | The service does not observe the full writing process or fact-check the statement. Treat it as an attestation, not independent proof. |
| Account, phone, or device compromise | Provider tokens, one-time codes, and WebAuthn ceremonies are verified when the related method is used. | A successful check can still be performed by someone controlling compromised credentials or a coerced user. |
| Copied badge or unrelated receipt link | The receipt displays the signed text or allows candidate text to be checked against its fingerprints. | Confirm the receipt text and claim match the content where the badge or link appeared. |
| Signing-key compromise | The private key is held by the service and only the public key is exposed. | Compromise of the service or private key could enable forged statements. Public incident response and key history are needed for stronger long-term assurance. |
| Key rotation or lost verification key | Each statement includes a signing-key identifier, and the active public key is published. | No versioned retired-key archive is currently advertised. Preserve the matching JWK for long-term independent checks. |
| Receipt expires | The signed statement contains an explicit expiry time and the hosted record is removed after 365 days. | The service will no longer supply the record. Expiry is not revocation, correction, or proof that the underlying claim changed. |
| True but harmful or unlawful content | No technical mitigation is claimed through the receipt itself. | A receipt does not certify safety, legality, quality, originality, or truth. Those require separate review processes. |
Legacy receipts: interpret only the verification methods actually listed in the signed statement. A missing method must not be inferred. In particular, older receipts may not contain the current required Turnstile signal.
Reader checklist
Start with the declaration and content match. Verification signals add context, but they do not replace judgment.
"I stand behind this" and "I wrote this" are different declarations.
Prefer a strict match. Treat a normalized-only match as formatting-tolerant.
Read what each listed method establishes. Do not infer missing methods.
Look at both issue and expiry times. A timestamp does not show continued endorsement.
Use separate evidence for truth, originality, safety, legal status, and expertise.
Methodology FAQ
These answers describe the current receipt format and service behavior.
No. It records the claim selected by the signer and the signals completed for the receipt. Even the "I wrote this" option is an attestation, not independent authorship proof.
Yes. The "I stand behind this" claim is designed for text a person reviewed and approves, including work where AI tools may have assisted.
The strict fingerprint detects any significant byte-level text change after line-ending normalization. The normalized fingerprint tolerates a small, documented set of formatting differences. Keeping both makes that distinction visible.
It adds economic friction. It does not add evidence that the declaration is honest, that the text is true, or that the payer wrote it.
The hosted record is removed and public lookup no longer succeeds. A copy of the statement, signature, and matching public key may still be cryptographically inspected elsewhere, but SignedByAHuman no longer provides the expired record.
Create a receipt only for public text you are willing to stand behind.