# Haven — security contact, per RFC 9116.
#
# ---------------------------------------------------------------------------
# ONE LINE IN THIS FILE IS DEPLOYMENT CONFIGURATION AND IS WRONG AS SHIPPED.
# ---------------------------------------------------------------------------
#
# The Contact address below points at haven.example, a domain RFC 2606 reserves
# and which will never resolve for anybody, ever. That is deliberate. An
# operator publishing this file must replace it with an address a stranger can
# actually reach, and must refresh Expires at the same time.
#
# The alternative — a plausible-looking address that quietly goes nowhere — is
# the exact failure this project has already paid for once, when two <script>
# tags shipped carrying integrity values that read like pending work and were
# silently discarded by the browser rather than enforced. A placeholder that
# fails LOUDLY is the only kind worth shipping. site/canary.html says the same
# thing about the warrant canary being unsigned as this repository ships.
#
# ---------------------------------------------------------------------------
# WHY THERE ARE NO Canonical, Policy OR Encryption FIELDS
# ---------------------------------------------------------------------------
#
# All three take a URI, and a URI needs a host. This is a static site that may
# be hosted anywhere, and its own harness asserts that no page and no file under
# site/ carries an absolute http or https URL of any kind — zero external
# requests is a load-bearing property for a product sold to people avoiding a
# well-resourced adversary, not a stylistic preference. That assertion is
# written to catch the scheme itself, so this file cannot quote one even in a
# comment. Writing three absolute URLs at a domain this repository does not own
# would either break the property or ship three more placeholders. So the same
# information is here as prose, where it is unambiguously prose:
#
#   Policy      — site/terms.html#acceptable
#   Canary      — site/canary.html, quarterly, and unsigned until an operator
#                 publishes a key. The fingerprint, once one exists, belongs on
#                 that page AND in this file: two publications of a fingerprint
#                 make substituting a key harder than substituting one page.
#   Encryption  — no key exists in this repository. A signing key belongs to
#                 whoever operates an instance, not to a source tree anybody can
#                 clone. An operator who publishes one should add Encryption and
#                 Canonical fields here at the same time, as absolute URLs at
#                 their own domain.
#
# The contact form at site/contact.html reaches a person too and is the right
# route for a commercial question. A vulnerability report should NOT go there:
# it lands in a sales queue.
# ---------------------------------------------------------------------------

# EDIT ME before publishing. See the note above.
Contact: mailto:security@haven.example
# THE POLICY FIELD IS A TEMPLATE, FOR THE REASON THE CONTACT LINE ABOVE IS.
# RFC 9116 wants an absolute URI here, and this file ships without knowing the
# deployment origin — every other page on this site is linked relatively so that
# a self-hosted instance is not quietly advertising somebody else own domain.
# Uncomment it and point it at this instance disclosure page:
#
# Policy: <this instance own origin>/disclosure.html      (an absolute URI, per RFC 9116)

# Refreshed with each statement of the warrant canary, which is quarterly. A
# security.txt whose Expires has passed is to be treated as unmaintained — that
# is what the field is for, and Haven's own site harness fails the build when
# this date is in the past rather than letting the file rot quietly.
Expires: 2027-08-01T00:00:00.000Z

Preferred-Languages: en

# ---------------------------------------------------------------------------
# WHAT IS WORTH REPORTING, AND WHAT IS ALREADY PUBLISHED
# ---------------------------------------------------------------------------
#
# Haven publishes its own limits rather than waiting to be told about them. The
# following are KNOWN, DOCUMENTED and NOT BUGS, and a report of one will be
# answered with a link to the page that already says it:
#
#   * The server holds the complete social graph in an indexed plaintext table,
#     and message timestamps at one-second resolution.
#     -> site/threat-model.html#server
#   * Forward secrecy is opt-in, per conversation, off by default, and bounded.
#     -> site/threat-model.html#forward-secrecy
#   * The client is unsigned JavaScript served by the same server it is
#     protecting you from, so a coerced operator can serve one modified bundle
#     to one account. -> site/security.html#not
#   * TOTP secrets are stored in the clear, because the server computes codes
#     from them on every sign-in. -> site/privacy.html#can
#   * Attachment byte sizes are stored unpadded, in the clear.
#   * Haven has never had an independent security audit, and every page of this
#     site says so.
#
# What IS worth reporting: anything that lets one account reach another's data;
# anything that lets the server or an operator obtain plaintext, key material or
# a password; any way past the safety-number block on a changed key; any way to
# make the authorship or transcript-continuity verifiers report a tampered range
# as clean; and anything that makes the account disclosure panel or the account
# export UNDERSTATE what the server holds — that last one is a lie in this
# product's most load-bearing surface and is treated as a security bug rather
# than a documentation one.
#
# Report in good faith and you will not be answered with a lawyer.
# -> site/terms.html#acceptable