Skip to main content
605Buzz

Privacy notice

Draft — pending counsel review. This notice reflects the waitlist + editorial data practices in effect today. The final form ships once retained media-law counsel has reviewed the GDPR Article 13 items + the editorial-processing lawful-basis analysis. If a specific claim below turns out to be inaccurate on that review, this notice rolls forward with a dated changelog entry.

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:

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):

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:

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."

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.

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. The full analysis is under counsel review and will land as a separate document + link from this notice before the first non-waitlist vertical launches. 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:

Join the waitlist Corrections + retractions →