Privacy by Architecture,
Not by Policy

Threat Model

We design against three adversary classes:

1. The Curious Manager — wants to know who said something. Has access to Teams/Zoom admin, email logs, corporate network monitoring. Motivation: performance management, retaliation.
2. The IT/Legal Team — operates under legal pressure. Has access to eDiscovery tools, Microsoft 365 compliance center, corporate email servers, potentially a subpoena. Motivation: compliance, litigation hold.
3. The Abuser — a participant using anonymity to harass, threaten, or probe moderation. Motivation: harm to others or circumventing content policy.

We defeat the first two by architecture. We mitigate the third by moderation and rate limiting — without breaking anonymity for the first two.

Data Retention Matrix

Every datum we touch, what happens to it, and when it's gone. TTL=0 means it never reaches storage.

Identity Stripping

SMS path

Twilio delivers an inbound SMS webhook to our server. The payload includes the sender's phone number. Our processing order:

1. Receive webhook from Twilio
2. Compute HMAC-SHA256 of the normalized phone number (E.164 format)
3. Use hash to look up active session (routing only)
4. Discard raw phone number from memory
5. Extract message text only
6. Moderate content (text only — no phone, no hash sent to OpenAI)
7. Relay "💬 Anonymous: [message]" to Teams/Zoom chat
8. Increment session message counter (integer only)

At no point is the phone number stored, logged, or included in the relay payload. The HMAC hash is stored in-memory only for session routing and is not logged.

Web form path

User submits message via browser form. Processing order:

1. Receive HTTP POST
2. Rate limit check using IP address (express-rate-limit, in-memory only)
3. IP address goes no further — not stored, not logged, not included in session
4. Extract message text
5. Moderate content
6. Relay to Teams/Zoom chat

Voice call path

User provides recipient phone/email and message text. Processing order:

1. Pre-moderation check (before payment)
2. HMAC-hash recipient for cooldown check — raw identifier not stored
3. Stripe payment intent created (we store payment intent ID only)
4. On payment confirm: TTS generates audio, Twilio places call
5. Recipient identifier discarded; only cooldown hash retained in-memory

Keyed Hashing (HMAC-SHA256)

We use HMAC-SHA256 rather than raw SHA-256 wherever we hash identifying information (phone numbers, email addresses).

Implementation

// Normalize first to prevent bypass via formatting variation
const normalized = phone.replace(/\D/g, '').replace(/^1?/, '+1').slice(0, 12);

// HMAC-SHA256 with server secret
const hash = crypto
  .createHmac('sha256', process.env.HMAC_SECRET)
  .update(normalized)
  .digest('hex');

Normalization

We normalize identifiers before hashing to prevent bypass via formatting variation:

• Phone numbers: Stripped to digits, normalized to E.164 (+1XXXXXXXXXX)
• Email addresses: Lowercased. We intentionally do not normalize Gmail + addressing to avoid false coupling between unrelated users who happen to share a domain prefix.

Secret rotation

The HMAC secret is set via environment variable (HMAC_SECRET). Rotation is supported but resets in-memory cooldown continuity — existing sessions are unaffected since sessions are scoped to meeting lifetime. A process restart after rotation is sufficient.

Provider Metadata and Linkage

This is the most important architectural section for enterprise reviewers. The risk: NotOnRecord touches multiple providers (Twilio, Teams/Zoom, Stripe, OpenAI). Could a determined adversary join records across providers to identify a sender?

The joinable graph — what each provider sees

Join path classification

We formally enumerate three categories of linkage risk:

• ❌ Architecturally impossible — the data required for the join does not exist in any system we control or any provider we use
• ⚠️ Subpoena-dependent + probabilistic — requires coordinated legal action against multiple providers, and even then yields probabilistic inference rather than deterministic identity
• 🔶 User-opt-in — user explicitly chose a path that creates linkage; documented in UX; cannot be subpoenaed away because the user made the choice

Temporal obfuscation: the Bayesian model

For paid channels (voice, email), the primary residual linkage vector is timestamp correlation: an adversary with both a Stripe record (payer at time T₀) and a Twilio record (call at time T₁) could attempt to infer P(same person | T₁ − T₀ = Δ).

We address this with a non-uniform randomized delay between payment confirmation and call/email dispatch. The delay distribution is heavy-tailed:

P(Δ ∈ 10–60s)    ≈ 60%   // most calls
P(Δ ∈ 60–180s)   ≈ 25%
P(Δ ∈ 3–8 min)   ≈ 10%
P(Δ ∈ 8–20 min)  ≈  5%   // long tail — high anonymity window

Why heavy-tailed rather than uniform? A uniform distribution over [5s, 120s] is statistically fingerprintable — an attacker with enough observations can model it and narrow the correlation window. A mixture distribution with long tails has higher entropy H(Δ), which directly reduces the posterior confidence of timestamp-based linkage.

Formally: if Stripe events arrive as a Poisson process with rate λₛ and Twilio events with rate λₜ, and the introduced delay follows distribution D, then the posterior probability that a specific Stripe event caused a specific Twilio event is:

P(match | Stripe=T₀, Twilio=T₁) ∝ P(Δ = T₁−T₀) · P(T₀ from λₛ) · P(T₁ from λₜ)

As H(D) increases:
  → More candidate Stripe events fall within the plausible delay window
  → Posterior P(match) drops from ≈1.0 toward 1/N where N = candidate set size
  → At scale (high λ), N grows — anonymity increases with volume

The goal is not zero correlation — it is plausible deniability under realistic adversary models. An adversary cannot determine with certainty which Stripe payment corresponds to which call. They can only make probabilistic inferences under conditions that require multi-party legal coordination.

Additional mitigations

1. Meeting chat has no payment linkage — SMS and web form messages involve no Stripe events. Twilio and Teams are temporally separated by 50–500ms jitter. No payment join vector exists.
2. No shared session identifier across providers — Session IDs are never sent to Twilio, Stripe, or OpenAI.
3. Nginx access_log suppressed on all anonymous-path endpoints — No IP-to-action log exists at the reverse proxy layer. The "IP never stored" claim holds at all layers.
4. Recording stored in-memory, not disk — Recordings are held in Node.js heap and served directly. No filesystem artifact is created. Recording is GC'd immediately after serving.

Content Moderation & Degraded Mode

We moderate message content to prevent harassment, threats, and abuse. Moderation operates on message text only — no sender identity is included in moderation API calls.

Moderation state machine

The dual recovery condition (successes + time) prevents oscillation on intermittent outages where the API alternates between passing and failing.

Degraded mode policy

Anti-probe rate limiting

The moderation API is a content oracle — attackers could probe it to learn what content is blocked and craft circumventions. Mitigation: identical message content submitted more than 3 times within 5 seconds is rejected without calling the moderation API. The rejection is indistinguishable from a moderation failure.

Moderation before payment

For paid channels (voice, email), content is moderated before Stripe payment intent creation. This eliminates paid-abuse scenarios (where an attacker pays to send prohibited content) and reduces chargeback exposure.

Health endpoint

Moderation system state is exposed at GET /health for operational monitoring:

{
  "moderation": {
    "available": true,
    "degraded": false,
    "failStreak": 0,        // consecutive failures (0 = healthy)
    "successStreak": 14,    // consecutive successes since last recovery
    "lastFailureTs": null,
    "lastSuccessTs": "2026-03-01T09:00:00Z",
    "degradedSince": null
  }
}

Abuse Handling Policy

Per-recipient cooldown

For voice calls and email, the same recipient cannot be contacted more than once per 10 minutes from any session. The cooldown is keyed on an HMAC hash of the recipient identifier — we track targets, not senders.

Abuse report mechanism

Each delivered message includes a report link containing a signed opaque token:

• Voice calls: "To report this message, visit notonrecord.com/report and enter code XXXX"
• Emails: Report link appended to message body

The token is single-use and expires after 24 hours. It encodes the session ID in a non-guessable way — the report endpoint does not accept raw session IDs. This prevents:

• Spam reports by parties who never received the message
• Session enumeration via brute-forced report attempts

What triggers action

Retention of abuse artifacts

Abuse reports are logged to stdout only (not persistent storage). Log rotation occurs at 30 days. No sender identity is present in any abuse log entry — by design, we don't have it.

Subpoena Resistance

If we receive a subpoena for records identifying who sent a specific anonymous message:

• We do not have a sender phone number or IP address — it was never stored
• We do not have message content — it was relayed and not retained
• We have a session ID, session timestamps, and a message count integer
• We have an HMAC hash of a phone number, keyed on a server secret we hold — this is of limited use without also having the source phone number to verify against

What a subpoena to us produces: a meeting happened, N anonymous messages were sent, the meeting started and ended at these times. Nothing linking any individual to any message.

Provider subpoena considerations

A subpoena to Twilio would reveal that a specific phone number sent a text to our Twilio number at a specific time. Twilio cannot see message content (we relay it; Twilio sees only the delivery transaction). A sophisticated adversary combining a Twilio subpoena with meeting participant lists narrows the field to meeting attendees who had their phone nearby. This is the residual privacy risk that we document honestly: we cannot protect against a scenario where an adversary has both provider subpoena responses and meeting attendance records.

For maximum protection, participants can use the web form from a non-corporate device or network — in that case, even Twilio is not in the picture.

Failure Modes

Operational Realities

This section documents constraints we cannot architect away — they are properties of operating on top of third-party infrastructure. We document them because enterprise reviewers deserve an honest picture, not a curated one.

Stripe as the strongest identity anchor

Stripe retains: card fingerprint, billing email, payer IP at checkout, payment timestamp, and amount. This is true regardless of anything we do. Stripe's privacy policy governs this data — not ours.

What we control: Stripe metadata fields (which we leave empty of message content and recipient identity), and our timing delay (which reduces timestamp correlation confidence). What we cannot control: Stripe's own data retention. Enterprise reviewers should treat Stripe's privacy policy as the binding constraint for paid-channel identity risk on the payer side.

Practical implication: A person who pays for a voice call is not anonymous to Stripe. They are anonymous to the recipient, to us, and to anyone without a Stripe subpoena. If maximum anonymity is required, use the meeting chat web form — it involves no payment processing.

Traffic volume and anonymity

Counterintuitively, the system's privacy properties improve with scale.

At low transaction volume, timestamp-based correlation is easier: few Stripe and Twilio events exist within any given time window, so the candidate set is small and inference confidence is higher. As transaction volume increases, more events fall within the plausible delay window for any given payment — the candidate set N grows, and P(correct match) approaches 1/N.

This is a structural property of the temporal obfuscation model: anonymity scales with usage. It does not degrade with scale, as is common in other systems.

Edge layer log retention

Our nginx reverse proxy suppresses access logs on all anonymous-path endpoints (access_log off). However:

• We do not currently use a CDN or edge proxy (Cloudflare, CloudFront, etc.). If we add one, that provider may retain request logs including IP and URI.
• We do not use a WAF. If we add one, WAF structured event logs could reintroduce URI-to-IP associations on blocked requests.
• Our TLS termination occurs at nginx on our own infrastructure.

Before adding any edge layer, we will audit its logging behavior and either disable logging on anonymous paths or document the exception.

Node.js diagnostic artifacts

Node.js can generate heap dumps (--heapdump) and diagnostic reports that could, in theory, capture in-memory recording buffers or session data. In production:

• Heap dumps are not enabled — no --heapdump flag, no v8.writeHeapSnapshot() call
• Node diagnostic reports are disabled (--no-report is not explicitly set, but no report triggers are configured)
• No APM agent (Datadog, New Relic, etc.) is installed — these can capture request/response bodies for large payloads

If we add APM or profiling tooling in the future, we will configure body capture exclusions on anonymous-path routes before deployment.

Future infrastructure: number pool rotation

As visibility increases, enterprise IT teams may begin blocking our Twilio numbers or flagging our domain. To maintain service continuity and resist targeted blocking:

• We plan to operate a pool of Twilio numbers, rotated per meeting session
• We plan to use multiple sending domains for email delivery
• Domain rotation infrastructure is not yet built — planned for post-launch after first blocking events are observed

Number pool rotation also slightly improves anonymity: a subpoena to Twilio against a specific phone number yields a smaller candidate set if many numbers are in use simultaneously.

What "anonymous" means in this context

We use "anonymous" to mean: sender identity is not present in any system record we hold or control, and cannot be recovered without multi-party legal action against third-party providers followed by probabilistic inference.

We do not claim: cryptographic unlinkability, protection against all possible adversaries, or anonymity in the presence of physical surveillance, device compromise, or behavioral analysis outside our system.

The threat model we are solving is: corporate IT teams, meeting organizers, and legal/compliance teams operating within normal organizational authority. We are not designed to withstand nation-state adversaries or coordinated law enforcement with full provider cooperation.

Audit & Contact

We intend to commission an independent security audit before general availability. We will publish the results (including findings) on this page.

If you've identified a security issue or privacy concern:

• Security: security@notonrecord.com
• Privacy: privacy@notonrecord.com
• Delete your waitlist data: privacy@notonrecord.com with subject "Delete my data"

We will respond to security reports within 48 hours.