Privacy notice

Who we are

605Buzz is a South Dakota discovery + civic-data + editorial platform built by Jason Comes (currently solo-founder; an Editor-in-Chief hire is targeted for a later phase). Reach us at hello@605buzz.com for general questions or privacy@605buzz.com for anything on this notice.

What we collect on the waitlist

The waitlist form at 605buzz.com collects five things when you submit it. Every field is enumerated so you can see the exact shape of the row we store:

• Your email address — required. Used to send you one email when your first chosen vertical launches, plus optional follow-ups when subsequent verticals go live. Normalized to lowercase + trimmed before storage.
• Your vertical of interest — optional. Defaults to "any" (every launch). Used to filter which launch emails reach you.
• Submission timestamp — server-stamped. Used as the audit record of when you opted in.
• Truncated IP prefix — the /24 or /48 network prefix of the IP address your request arrived from (last octet zeroed for IPv4 or last 80 bits for IPv6). Never the full IP. Used for rate-limit + abuse triage only.
• Referrer origin — optional. If you arrived via a link with a referrer, we store only the origin (`https://example.com`), never the path or query parameters. Used for attribution reporting only.

What we do NOT collect on the waitlist: we deliberately do not capture your user-agent string, browser fingerprint, or any product tracking cookie. The submission is a plain HTML form POST; no JavaScript telemetry runs. Cloudflare, our CDN + edge infrastructure provider, may set strictly-necessary infrastructure cookies as part of serving the site: __cf_bm (bot detection), __cflb (load-balancer session affinity), __cfruid (session affinity), _cfuvid (rate-limit unique-visitor identifier), and cf_clearance (set only when a bot-challenge is passed). We do not read these cookies or use them for tracking; they are covered by Cloudflare's own privacy policy.

Lawful basis

We process your waitlist submission on the basis of your consent (GDPR Article 6(1)(a) / equivalents). You give consent by submitting the form; you can withdraw it by emailing privacy@605buzz.com with the subject "Waitlist erasure request" or by unsubscribing from any launch email we send you.

Retention

Waitlist rows are retained for one year from submission and then automatically expire from our storage layer. If you request erasure before then, the row is deleted from our primary storage; global edge propagation completes within approximately 60 seconds. Rate-limit counters (a separate key on our storage layer) expire after 1 hour and are never associated with your email in the rate-limit shape.

Alongside the primary storage row we also maintain a strongly-consistent Durable Object entry, keyed by your email address, that stores the same row fields (submission identifier, receipt timestamp, vertical of interest, referrer origin if any, and truncated IP prefix) for the same one-year retention window. The entry exists so a concurrent second submission for the same email cannot race the first into two distinct records with different consent trails; it is atomically purged when you request erasure — the erasure endpoint issues an explicit purge to the Durable Object alongside deleting the primary storage row, so the pseudonymized personal data does not outlive the erasure request. A separate Durable Object keyed by a truncated IP prefix stores only a per-window submission counter for the rate-limit gate and holds no per-subject information; it is not purged on individual erasure because its counter is shared across every caller on the same prefix.

When you request erasure, we also create a pseudonymous audit record retained for 7 years to satisfy GDPR Article 5(2) accountability obligations and align with standard enterprise audit-evidence windows. The record stores an HMAC-SHA-256 of your email address under a keyed secret (not a bare SHA-256 — the keyed construction is not reversible by dictionary), deletion-outcome flags, a timestamp, and a separate HMAC signature over the whole row. The plaintext email itself is never stored on this row.

The identifier key is separate from the signing key. Retiring the identifier key on incident grounds is what we call crypto-shred — after retirement, the pseudonymous identifier on your erasure record becomes permanently non-recoverable, meaning the row still exists for accountability but no one (including us) can prove which subject it belongs to. Two important limits on the crypto-shred story you should know as a subject: (a) it affects the erasure audit record's identifier only, not any live waitlist row you may have on our list — the live row's plaintext is separately governed by its 1-year TTL or an explicit erasure request, and (b) if we ever retire the identifier key, the pseudonymous receipt we retained for accountability becomes non-verifiable in the sense that neither we nor a third-party auditor can any longer prove the receipt corresponds to your erasure specifically.

The pseudonymous record is not used for any other purpose and is not linked back to plaintext email addresses on our end.

Tamper-detection artifacts. If we detect that a stored erasure record's cryptographic signature no longer verifies (a possible signal of unauthorized tampering with our storage layer), we preserve a copy of the pre-tamper bytes under a shadow storage key for the same 7-year retention window and we write a fresh signed record of the actual deletion event under a server-generated identifier. This keeps our Article 5(2) accountability posture intact even when the primary storage row's integrity is compromised. In that scenario your erasure event ends up represented by two signed records (the original identifier you supplied or we minted, plus the server-minted recovery identifier) alongside the preserved quarantine copy. When you exercise your Article 15 right of access by writing to privacy@605buzz.com, our operator response includes all applicable identifiers so the accountability chain is fully traceable to you. The processing basis for retaining the tamper-attempt copy AND for writing the fresh recovery record itself is GDPR Article 6(1)(f) legitimate interest in audit-log integrity (both artifacts are required to preserve provable accountability when the primary record's integrity is compromised); each row contains only the same pseudonymous identifier already in scope, no additional plaintext.

Two limitations on the tamper-detection apparatus you should be aware of. First, the quarantine copy preserves the MOST RECENTLY observed tampered payload at each shadow storage key; if a tamper campaign rotates payloads over multiple detection rounds, earlier tamper evidence at the same key may be overwritten by later detections. Full detection history is preserved separately in our internal log stream (7-day retention under the Cloudflare Workers Logs sub-processor entry below), and our operator response to an Article 15 request will include the log correlation. Second, in the rare case where a storage-layer outage prevents us from writing the recovery record at the exact moment we detect tampering, your physical waitlist rows are still deleted but the fresh signed recovery artifact does not persist; when this happens we will notify you at the address on file and explain what preserved artifacts remain, and we will reconcile the accountability trail out-of-band via our operator log stream. If the correlation trail itself is lost past our 7-day incident window (the Workers Logs retention period on our sub-processor entry below), we escalate to a blanket notification of every subject whose erasure ran during the affected window, since we can no longer identify the specific rows involved.

Automated decision-making

We do not use automated decision-making or profiling within the meaning of GDPR Article 22. No decision that produces legal or similarly significant effects on you is made by an automated system on our side.

Children under 13

605Buzz is directed to users 13 and older. We do not knowingly collect personal information from children under 13 (COPPA, 15 U.S.C. §6501 et seq.) or from users under 16 in the EU without verified parental consent (GDPR Article 8). If you believe a child has submitted personal information to us, please email privacy@605buzz.com and we will delete the submission promptly.

US state privacy law rights

Residents of the following US states with comprehensive privacy laws have equivalent rights to the ones enumerated below (access, deletion, portability, correction, and — where applicable — opt-out of sale or targeted advertising):

• Virginia (VCDPA)
• Colorado (CPA)
• Connecticut (CTDPA)
• Utah (UCPA)
• Texas (TDPSA)
• Oregon (OCPA)
• Florida (FDBR)
• Delaware (DPDPA)
• Iowa (ICDPA)
• New Hampshire (SB 255)
• Nebraska (NDPA)
• Maryland (MODPA)
• Minnesota (MCDPA)
• Tennessee (TIPA)

Use the privacy@605buzz.com contact address for any of these requests; we honor every request regardless of your state of residence.

No sale or sharing of personal information (California)

If you are a California resident: we do not sell your personal information as defined by the California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA), and we do not share it for cross-context behavioral advertising. There is no opt-out mechanism required because there is no sale or sharing to opt out of.

Sub-processors

We use the following third-party processors to deliver the service. Each processes personal information only on our instructions and under a written data-processing agreement:

• Cloudflare, Inc. — Workers + Workers KV + Pages — edge CDN, Workers + Workers KV storage, Cloudflare Pages hosting, DNS. Waitlist rows live on Cloudflare Workers KV; the site itself runs on Cloudflare Pages. Sub-processor of every request. Note: erasure log KV keys are composed as erasure:<emailHmac>:<uuid>, so the pseudonymous emailHmac identifier (a keyed HMAC, not reversible by dictionary) appears in Cloudflare's KV operation audit logs — governed by Cloudflare's own log retention terms under the DPA. No plaintext email ever appears in KV keys. (DPA)
• Cloudflare, Inc. — Pages / Workers Secrets — separate Cloudflare product from Workers KV that provisions secrets for both Pages and Workers deployments under the same DPA; holds two distinct HMAC keys used by the waitlist substrate: the erasure-log signing key that anchors every erasure audit record's authenticity, and the erasure-log identifier key that computes the pseudonymous emailHmac stored on each audit row. The two keys are held separately so the signing key can rotate on a regular cadence without invalidating identifier lookup for pre-rotation rows; the identifier key rotates on incident / crypto-shred grounds only. Same DPA applies. Personal data does not flow through this service; it processes signing-key + identifier-key material only.
• Cloudflare, Inc. — Durable Objects — strongly-consistent per-key storage inside the Cloudflare runtime. The waitlist substrate uses two Durable Object classes as atomic gates the eventually-consistent Workers KV product cannot provide: WaitlistDedupDO, keyed by your email address (idFromName(email)), stores the row's canonical fields (submission identifier, receipt timestamp, vertical of interest, referrer origin if any, and truncated IP prefix) for the same 1-year retention as the KV waitlist row so a concurrent second submission for the same email dedupes against the first; and RateLimiterDO, keyed by a truncated IP prefix, stores a per-window submission count for the ~1-hour rate-limit window with cleanup shortly after the window expires. On Article 17 erasure the admin endpoint issues a purge to the WaitlistDedupDO alongside the KV deletes so the pseudonymized personal data does not outlive the erasure request. The RateLimiterDO is not purged on individual erasure because its counter is per-prefix shared state, not personal data attributable to a specific subject. Same DPA applies.
• Cloudflare, Inc. — Workers Logs — structured log lines emitted by our request handlers (auth-slot signals, erasure-log write failures, tamper-detection alerts, rate-limit corrupt-row alerts) are retained by Cloudflare Workers Logs for 7 days by default. No Logpush destination is configured, so these lines do not leave Cloudflare's platform. The lines carry idempotency uuids + deletion-outcome flags but not plaintext email. One narrow exception: the admin.erasure.recovery-lost-breadcrumb line emits the pseudonymous emailHmac alongside the idempotency uuid — this line fires ONLY under a specific incident condition (a tamper-recovery write itself failed after physical deletion has already run) and provides the Article 5(2) reconciliation surface needed to identify affected subjects for Article 33/34 notification. The pseudonym is a keyed HMAC (not reversible by dictionary), and the widening is bounded to the incident case. Same DPA applies.
• Beehiiv Inc. — email service provider for launch-notification emails. Not yet wired. Before we begin sharing email addresses with Beehiiv, we will (a) email every existing waitlist subscriber with prior notice describing the new sub-processor + linking to Beehiiv's DPA and privacy policy, (b) provide an unsubscribe path in that notice so subscribers can withdraw before any transfer occurs, and (c) update this sub-processor entry + emit a dated changelog line. A silent page update after-the-fact is not sufficient notice; the prior-notice email is the required mechanism. (privacy policy)

Your rights

Depending on your jurisdiction, you have some or all of the following rights. We honor every request regardless of whether the jurisdiction technically requires it — the operational posture is "if you ask us to do it, we do it."

• Access (GDPR Art 15 / CCPA §1798.110) — email privacy@605buzz.com with the subject "Waitlist access request" from the email address the row is under. We aim to reply within 30 calendar days. Where complexity or volume requires additional time, we will notify you within 30 days and complete the response within 60 days (GDPR Article 12(3)). The response is in machine-readable JSON and contains the row's shape (submissionId, vertical of interest, timestamp, IP prefix, referrer origin).
• Erasure (GDPR Art 17 / CCPA §1798.105) — email privacy@605buzz.com with the subject "Waitlist erasure request" from the email address you want deleted. We aim to delete both the id-keyed audit row and the email-keyed lookup within 7 days and reply confirming deletion. Where complexity or volume requires additional time, we will notify you within 30 days and complete the response within 60 days (GDPR Article 12(3)).
• Rectification (GDPR Art 16 / CCPA §1798.106) — email us the correction. Email addresses can only be corrected by deleting the row and re-submitting under the new address (the address is the row's primary key).
• Portability (GDPR Art 20) — the access response is already machine-readable JSON. Ask for it if you want it.
• Right to object (GDPR Art 21) — where a processing activity is based on legitimate interests (this currently applies only to future editorial processing of subjects of articles, not to the waitlist itself), you have the right to object. We honor objections unless a compelling legal ground overrides your interests.
• Right to non-discrimination (CCPA §1798.125) — exercising any of the rights above will never trigger denial of goods or services, a different price, or any other disadvantage. Our service is free; there is no tier we could downgrade you to.
• Right to lodge a complaint — if you're an EU resident, your national data protection authority is the appropriate supervisory authority (see the EDPB member list). UK residents can complain to the ICO. US residents can contact their state attorney general.

Where the data lives

Waitlist rows are stored on Cloudflare's edge storage layer (Workers KV), which replicates globally by default. If you submit from the EU, your row may reside on infrastructure outside the EU. Cloudflare's Data Processing Agreement + Standard Contractual Clauses (Module 2, controller-to-processor) are the transfer mechanisms we rely on. If EU-regional residency of your row is a hard requirement, email us before submitting.

If you are visiting from the EU, EEA or UK

Part of this site is deliberately not served to you, and you should know that before you read the rights section below. Visitors whose requests arrive from an EU, EEA or UK IP address receive an HTTP 451 Unavailable For Legal Reasons on the routes that serve machine-drafted articles — the article pages, the desk trackers, search, the map, the per-article correction ledgers, the feeds and the API. This is a scope-reduction measure while the EU AI Act (Regulation (EU) 2024/1689) Article 50 transparency question is unresolved for this site, and it currently applies to every one of those countries with no exemptions.

What stays reachable, on purpose: the waitlist signup, this privacy notice, /about, /terms, /why-verified and the corrections policy page. That is not incidental — blocking the page a data subject uses to understand their rights, or the page they use to request a correction, is the one outcome the block must never produce. So every right described below, including the complaint route to your national supervisory authority, is exercisable from inside the EU even though the articles themselves are not served to you.

The 451 response body itself names the reason (eu-ai-act-article-50-compliance-window), the country it was applied to, a policy link, and a contact address, so the block is inspectable rather than silent. The block is decided on the country your request arrives from, and the country is read from our CDN's edge signal — it is not derived from a cookie, and we do not store it.

Editorial processing (subjects of articles)

Separately from the waitlist: when 605Buzz publishes an article that names a living private individual (obituary subjects, court-docket defendants, business owners in a WARN filing, etc.), that processing has its own lawful basis analysis under GDPR Article 6(1)(f) (legitimate interests) + Article 85 (journalism exemption) + the relevant US state law equivalents. This is the part of the notice whose legal reasoning has not been reviewed by counsel, and it is the reason the note at the top of this page exists: the balancing test is written but not signed off, and it will land as a separate linked document once it has been. The practical commitment in the meantime is unchanged — if you are the subject of an article and something in it is wrong or should not be there, we would rather hear from you and act than wait for the memo. If you're a subject of a published article and want to exercise rights over your data specifically, see the corrections page or email privacy@605buzz.com.

Changelog

We keep a dated changelog of material changes to this notice so a returning visitor can see exactly what changed:

• 2026-08-09 — replaced the “Draft — pending counsel review” header, which overstated what was unfinished: the factual description and the operative commitments were in force from the day the waitlist form went live, and only the editorial-processing lawful-basis analysis is awaiting counsel. The new header scopes the caveat to that analysis, and the editorial-processing section now carries the caveat inline. Added a section disclosing the EU/EEA/UK HTTP 451 geo-block on automated-content routes, naming the surfaces deliberately kept reachable so that every right on this page — including the supervisory-authority complaint route — remains exercisable from inside the EU. Disclosed that inbound mail routing for the domain is not provisioned, so rights-request emails currently bounce. Standardized the general contact address on hello@605buzz.com (/about had been publishing hi@605buzz.com).
• 2026-07-19 — disclosed the Durable Object storage surface used as an atomic gate for waitlist rate- limit and email-dedup checks. Added a new sub-processor entry naming both DO classes and their retention windows; added a Retention paragraph describing the DO's parallel one-year window for the same row fields as the primary storage row and the atomic-purge behavior on Article 17 erasure; noted that the rate-limit DO holds only shared per-prefix counter state, no per-subject data.
• 2026-07-18 — disclosed the tamper-detection apparatus and named its two documented limitations (quarantine payload overwrite + storage-outage recovery-log gap); named the operator-log correlation and Article 15 reply posture; disclosed the recovery-lost breadcrumb's narrow scope (only fires when a recovery-record write fails after physical delete has already run — not on routine storage blips); refined the Workers Logs sub-processor entry to describe the exact scope, retention, and lawful basis of that breadcrumb; disclosed the blanket-notification fallback if the 7-day correlation window itself is lost.
• 2026-07-15 — added Article 12(3) extension caveat to the erasure commitment (parity with the access commitment); added the pseudonymous erasure audit record's 7-year retention + its HMAC-signed shape to the Retention section; added a "US state privacy law rights" section naming VCDPA, CPA, CTDPA, UCPA, TDPSA, OCPA, and FDBR residents' equivalent rights.
• 2026-07-13 (second pass) — expanded the Cloudflare infrastructure cookie list to include __cfruid, _cfuvid, and cf_clearance; added a COPPA / under-13 statement; scoped the CCPA section explicitly to California residents; added Article 12(3) extension caveat to the access-request reply commitment; added a direct link to the EDPB member list for EU complaint routing.
• 2026-07-13 — hardening pass. Added Article 22 (automated decision-making) statement, Article 21 (right to object), CCPA §1798.120 (no sale/sharing) statement, CCPA §1798.106 (correction) + §1798.125 (non-discrimination) rights, 30-day access-request reply commitment, Cloudflare infrastructure cookie disclosure, sub-processors section (Cloudflare + Beehiiv-pending) with DPA links, hashed-email erasure audit trail.
• 2026-07-13 — initial draft. Waitlist collection + retention + rights disclosed. Editorial lawful-basis section marked as under counsel review. Full form ships after retained media-law counsel signs off on the Article 13 items + the editorial-processing balancing test.