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, once mail is live — today mail to either address currently bounces.

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.

What we collect when you follow a record

Separately from the waitlist: an article that states a followable value carries a second form — “Email me when this record changes” — where you pick one value the record already states (a highway, an employer, a permit number, a meeting body) and give us an email address. It posts to /api/alerts/subscribe. It is anonymous: there is no account, no login, and nothing on our side proves that the person typing an address owns it. That one fact decides most of what follows on this page.

One submission writes up to two rows in our database. Every field of both is enumerated so you can see the exact shape of what we store:

The address row (alert_subscribers) — written only if the address is not already on our list:

• Your email address — required. Normalized to lowercase + trimmed. It is the row's unique key.
• Creation timestamp — server-stamped. The record of when the address first arrived.
• An unsubscribe token — 32 random bytes as hex. The one-click opt-out credential; never written to a log.
• A confirmation token — 32 random bytes as hex, and deliberately a different secret from the unsubscribe token: a confirmation link goes to an address we are not yet sure belongs to whoever typed it, so it must not also carry the credential that can opt that address out.
• Two confirmation timestamps — when a confirmation link was sent, and when it was clicked. Both are empty on every row this form has ever created, because no confirmation email is being sent yet. See the lawful-basis paragraph below; this is not a detail.
• Status — active or unsubscribed, plus the timestamp of an unsubscribe if one happens.
• Two list flags — whether this address wants record alerts, and whether it wants the daily WARN layoffs digest. A row created by this form is marked as wanting record alerts. An address already on our list is left exactly as it is: this form never changes an existing row's flags, status, tokens or timestamps.
• ⚠ And an open defect, named here rather than found later. Until 2026-09-19 this paragraph said a row created by this form is marked as not wanting the layoffs digest. That was true, and it was true for the wrong reason: the form wrote that flag onto addresses it had no business deciding for — including addresses a stranger typed in — and nothing in the site could ever set it back, so following one road silently and permanently removed a person from the layoffs digest. Removing that write was the right fix. Its cost is that the database's own default applies instead, and that default is true: so if you followed a record and then confirm your address, you may receive the daily layoffs digest you did not ask for. Every one of those messages names its list and carries a one-click unsubscribe. The proper repair is for each product to record its own consent rather than inherit a default, and it is not done yet.

The subscription row (fact_subscriptions) — one per thing you follow:

• The target — the record you chose to watch. Three fields: the kind of record, the named field the value was published under (route, companyName, permitNumber, meetingId, and so on), and the value itself, stored verbatim as its source published it. This is a category of data no earlier form on this site collected, and it deserves to be named plainly rather than filed under “preferences”: it says that a person at this address is interested in this road, this employer, this permit, this meeting body. We treat it as personal data about you, not as neutral metadata. It is also why the endpoint's replies are byte-identical whether a subscription was newly created, already existed, or hit a per-address ceiling — a reply that told those apart would answer “does this person follow this road?” for anyone who asked.
• A link to the address row — an internal identifier, not the address. The subscription row holds no email address at all.
• Creation timestamp — server-stamped.
• The truncated network prefix the request arrived from (writer_bucket) — the /24 or /48 described below, stored so that a limit can be placed on how many records one sender may add against an address that has never confirmed. It is coarse by construction and is never the whole address. It is deleted with this row.
• A per-subscription confirmation token and its two timestamps — when the confirmation link for this specific subscription was sent and when it was clicked. Both empty today, for the same reason as above. The token is per-subscription rather than per-address so that confirming one thing you follow can never silently confirm another.

Your truncated IP prefix is used three times, and two of those outlive the request. The /24 or /48 network prefix of the address your request arrived from (last octet zeroed for IPv4, all but the first three groups dropped for IPv6) is used as the key of a rate-limit counter — a Durable Object keyed alerts:<prefix>, holding a count and a window-reset time and nothing else. It has its own budget, separate from the waitlist and layoffs counters, so a flood against one form cannot lock readers out of another. That counter expires with its one-hour window and holds nothing attributable to you.

The second use is stored, and this notice said it was not. The same prefix is written to the writer_bucket column of the subscription row, so that a limit can be placed on how many records one sender may add against an address that has never confirmed anything. Without it, anyone could type a stranger’s address into this form enough times to stop that person ever following anything. That is the abuse it exists to stop, and it is GDPR Article 6(1)(f) legitimate interest in preventing abuse of an anonymous form. Until 2026-09-19 this paragraph said the prefix was “not stored on either row” and that “neither database row records an IP at all”. That was true when it was written and became false when the column shipped, and it is corrected here rather than quietly rewritten.

The third use is a weekly counter, and it is keyed to your mailbox as well as your network. Anyone can type anyone’s address into this form, so there has to be a limit on how many records one sender may add against one address. A limit counted per address alone does not work: you+1@ and you+2@ are different addresses and the same inbox. So the counter is named by a keyed one-way code derived from both your network prefix and a collapsed form of your address — you+anything@ counts as you@, and at providers that publish it, so do dots and alternate spellings of the domain. The collapsed form is used to count and nothing else: it is never stored, never mailed, never used to look you up, and never used to erase you. The counter holds a number and a reset time, and it lasts seven days rather than the one hour of the counter above. Processing it is GDPR Article 6(1)(f) legitimate interest in preventing abuse of an anonymous form.

What that costs you, said plainly. If you follow a lot of records in one week from one network, a later one can be held back without the page telling you — the reply is deliberately identical whether a follow was saved or refused, so that this form cannot be used to find out whether an address is known to us. And because the counter is keyed to a network as well as a mailbox, heavy use by someone else on your network can consume part of that allowance.

What that means in practice: the stored prefix is coarse — it names a network of hundreds or thousands of addresses, not a person or a device — but it does sit on a row that also carries your email address, so it is fair to read it as network information about you rather than about nobody. It is deleted with the rest of your data when you ask for erasure, because the subscription row is deleted and this column is part of it. What it does not yet have is an expiry of its own: it stays on a confirmed subscription after the limit it exists to enforce has stopped applying to that row. Giving it one is an open item, named in the retention schedule rather than left for a reader to discover.

What we do NOT collect on this form: no user-agent string, no browser fingerprint, no tracking cookie, no referrer, and no full IP address — the stored network prefix described above is the truncated form, never the whole address. The form is a plain HTML POST with no JavaScript; the Cloudflare infrastructure cookies described above are the only cookies involved. If a submission fails, the error we log records the outcome only — never the address, the field, or the value you picked.

Lawful basis for following a record — and why it is not your consent at the moment you press the button

A form that anyone can post to cannot collect your consent, because the person pressing the button has not proved they are you. Our code is built on that premise and we are not going to describe it otherwise: the subscribe endpoint does not treat a submission as consent, does not mark an address as wanting mail, and writes the subscription in a pending state that nothing can deliver from. The confirmation token exists precisely so that an anonymous request cannot decide what an address agrees to.

So the honest split is this:

• Creating and holding the pending row is processed under GDPR Article 6(1)(f), legitimate interests. The interest is narrow and we will state it exactly: being able to ask the owner of that address whether they want this, which is the entire purpose of a double opt-in and is the step that protects you from someone else signing you up. Nothing is sent, shown or acted on from a pending row. You can object to this processing under Article 21, and we will delete the row — see the erasure path below.
• An actual, deliverable subscription is processed under GDPR Article 6(1)(a), consent, and that consent begins only when somebody holding the mailbox clicks the confirmation link for that specific subscription. The three confirmation fields on the subscription row — token, sent-at, confirmed-at — are our Article 7(1) record of it: they say which target was agreed to, that a link was sent before it was answered, and when it was answered.

The limit you should know about, stated rather than implied. No confirmation email is being sent today. Outbound mail is not switched on for this site at all, and inbound mail is not provisioned either (see the note at the top of this page). A row created by the follow form right now is therefore inert: it cannot receive anything, and it cannot become consented, because the message that would ask you does not go out. That has an uncomfortable consequence for the legitimate interest above — the interest is “so we can ask you”, and we are not currently able to ask. We are disclosing that rather than letting the notice imply a confirmation is on its way. Open item: whether unconfirmed rows are deleted after a fixed period, or kept until confirmation is switched on, has not been decided by the operator, and we are not going to publish a period we have not actually chosen. Until it is decided, the erasure path below is available to anybody, for any reason, including “I never asked for this.”

If someone else typed your address here. They can. What they get is a pending row that mails you nothing and tells them nothing back — every reply the endpoint gives is the same bytes, so a stranger cannot use it to learn whether your address is on our list or what you follow. Write to privacy@605buzz.com and we will delete it once the request reaches us. Mail to that address currently bounces; see the notice at the top of this page.

Retention and erasure for record alerts

Retention. These two rows live in our Postgres database, not on the edge storage layer the waitlist uses, and nothing expires them automatically — there is no TTL and no pruning job. A confirmed subscription is kept for as long as you want it, which is what a standing watch is: it has to outlive the article that created it in order to ever fire. An unconfirmed row is kept because nothing deletes it, which is a different and weaker reason, and it is the open item named above. The criteria that actually end retention today are: you unsubscribe, you ask us to erase, or an operator erases the row.

Unsubscribing is not deletion, and we would rather say so than blur it. The one-click unsubscribe link (which will arrive in mail once mail is switched on) sets the address to unsubscribed. The address stays on file as a suppression record, so nothing can start mailing it again by accident. If you want it gone rather than suppressed, ask for erasure.

Erasure. Email privacy@605buzz.com with the subject “Alert erasure request” (mail to it currently bounces — see the first limit below). An operator runs a hard delete of the address row; every subscription attached to it is removed with it by the database's own cascade, so there is no partial state where the address is gone and the list of what you followed survives. As with waitlist erasure, the deletion writes a signed, pseudonymous audit record to the same 7-year erasure log described above, under its own key prefix. That record carries a keyed HMAC of your address, a timestamp, whether a row was found, and a signature — never the plaintext address, and never the records you followed. The rate-limit counter is not purged on an individual erasure, because it is a per-prefix count shared with every other caller on the same network prefix and holds nothing attributable to you.

Two practical limits, because a rights path that quietly fails is worse than one you can plan around. First, mail to 605buzz.com currently bounces, so keep the bounce notice — we will treat your request as received on the date you sent it. Second, there is no self-serve page today where you can see or remove what an address follows; doing that safely needs a link sent to the mailbox, and mail is not switched on. Until it is, the erasure route above is the whole mechanism, and we will run it for anyone who asks.

Lawful basis for the waitlist

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. Mail to that address currently bounces; see the notice at the top of this page.

Retention for the waitlist and for erasure records

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 (mail to it currently bounces; see the notice at the top of this page), 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. We previously said full detection history is preserved separately in our internal log stream on a seven-day retention. That was wrong — the lines come from a Cloudflare Pages project, which retains nothing, so there is no second copy and no log correlation to give you. What survives a payload rotation is the most recent tampered payload at each key and the signed recovery artifacts described above; earlier evidence at the same key does not. 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 where one was being watched at the time. Because those lines are not retained, we must assume the correlation trail is unavailable rather than hope for it: in that case we escalate to a blanket notification of every subject whose erasure ran during the affected window, since we cannot identify the specific rows involved. Corrected 2026-09-19: this previously described a seven-day incident window to reconcile within. No such window exists.

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 once the request reaches us. Mail to that address currently bounces; see the notice at the top of this page.

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. Mail to that address currently bounces; see the notice at the top of this page.

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. Where a written data-processing agreement is in place we link it; where one is not yet executed, the entry says so rather than leaving you to assume it.

• 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). These lines are not retained at all. They are emitted by the project that serves this website, which runs on Cloudflare Pages, and Workers Logs retention is not available for a Pages project — so a line exists only while somebody is watching a live stream, and is gone otherwise. Our ingest worker is a separate deployment that does retain for 7 days, but it is not what handles the forms on this site. Corrected 2026-09-19: this entry previously stated 7-day retention for these lines, and two paragraphs elsewhere in this notice relied on that period. It was the ingest worker's figure, written about the wrong deployment. 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.
• Supabase, Inc. — hosted Postgres database (running on Amazon Web Services infrastructure in the US East / N. Virginia (us-east-1) region) — this is where record-alert data actually lives. The address row and the subscription row described in “What we collect when you follow a record” — your email address, the tokens, the timestamps, and the record you chose to follow — are stored in a Postgres database operated by Supabase, which in turn runs on Amazon Web Services. AWS is therefore a further sub-processor beneath Supabase. Our editorial database (articles, sources, the decision log) is in the same database. The connection is encrypted in transit and reaches the database through Cloudflare Hyperdrive; the site's application code runs on Cloudflare, so a single follow submission touches both providers. ⚠ Transfer mechanism: not documented, and we are not going to invent one. We hold no executed data processing agreement, Standard Contractual Clauses reference or EU–US Data Privacy Framework certification on record for Supabase or for AWS. The Cloudflare DPA and SCCs named in the entries above cover Cloudflare and do not extend to this processor. So for the purposes of GDPR Article 13(1)(f) the accurate statement today is: personal data submitted through the follow form is stored in the United States, and the Chapter V transfer safeguard for that storage is not yet in place or not yet documented. An EU, EEA or UK reader should weigh that before submitting, and privacy@605buzz.com will delete a row on request for that reason or any other, once a request can reach it: mail to that address currently bounces, as the notice at the top of this page says. Executing the agreement and naming the mechanism here is an open item on the operator, and this notice will carry a dated changelog line when it is done.
• 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." Every request below is made by email, and mail to privacy@605buzz.com currently bounces, so the timelines below run from the day a request reaches us — or, if you kept the bounce notice, from the day you sent it.

• Access (GDPR Art 15 / CCPA §1798.110) — email privacy@605buzz.com (mail to it currently bounces) 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 (mail to it currently bounces) 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.

Record-alert data lives somewhere else, and in one fixed place. If you use the “Email me when this record changes” form, your address and the record you follow are not stored on the edge storage layer at all. They are written to a Postgres database operated by Supabase, running on Amazon Web Services infrastructure in the US East / N. Virginia (us-east-1) region. There is no EU region and no replica: that database is the only copy. As the Supabase sub-processor entry above states, we hold no documented Standard Contractual Clauses, Data Privacy Framework certification or signed data processing agreement for that provider today, so a submission from the EU, EEA or UK is a transfer to the United States whose Chapter V safeguard we cannot currently point to. We would rather tell you that than name a mechanism we cannot show you.

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 homepage and 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 that explains how to request a correction, is the one outcome the block must never produce. So the block is never what stands between you and a right described below: every page describing those rights stays readable from inside the EU, and the complaint route to your national supervisory authority does not go through us at all. What does stand in the way today is our mailbox. The requests below are made by email, and mail to this domain currently bounces, from inside the EU or anywhere else — see the notice at the top of this page.

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 — though mail to that address currently bounces, as the notice at the top of this page says.

Changelog

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

• 2026-10-13 — Three corrections. The section for visitors from the EU, EEA and UK said every right on this page was “exercisable from inside the EU”; the page is readable there, but the requests are made by email and mail to this domain bounces from everywhere, so that sentence now says so. The same section listed the routes that answer EU, EEA and UK visitors with a 451 and left out the homepage, which is one of them. And the note at the top said the editorial lawful-basis analysis had not been reviewed “by retained media-law counsel”, which read as though such counsel exists; none is retained. Earlier entries below that speak of counsel review as pending describe a plan, not an engagement. Each address on this page now says beside it that mail to it currently bounces.
• 2026-09-19 — Two corrections and one new disclosure, all about the same form. This notice said your truncated network prefix was “not stored on either row”; a column added the day before stores it on every subscription row, and that is now described along with the expiry it does not yet have. It also said a row created by the follow form is marked as not wanting the layoffs digest; that write was removed — it was overwriting a consent record for a product the reader was never asked about — so the database default now applies and the opposite can happen. And the weekly per-mailbox counter described above is new. Every one of these is a change a reader might have relied on, which is why they are here rather than quietly edited.
• 2026-09-18 — disclosed the “Email me when this record changes” form, which shipped on article pages before this notice described it. This notice had been written entirely about the waitlist: its scope sentence, its lawful-basis sentence and its retention sentence all named waitlist rows, and none of them reached a second, anonymous collection point that stores an email address plus the record a reader chose to follow. Article 13 information is due at the point of collection, so the gap is named as a gap rather than quietly closed. Added: a section enumerating every field of both rows, including the target — the road, employer, permit or meeting body someone watches — which is a data category no earlier form collected; a lawful-basis section stating that consent is NOT available at submission because the form is anonymous, that the pending row rests on Article 6(1)(f) legitimate interest in being able to ask the address owner, and that Article 6(1)(a) consent begins only at a confirmation click that no mail currently delivers; the truncated-IP rate-limit counter used by this form; a retention section stating plainly that nothing expires these rows automatically and that the expiry of unconfirmed rows is an undecided question we will not paper over with a made-up period; and the erasure path, including that the subscription rows cascade with the address row. Added Supabase to the sub-processor list with its actual region (AWS us-east-1) — the previous list named only Cloudflare and Beehiiv and so was wrong about recipients under Article 13(1)(e) — and stated, rather than invented, that no SCC, Data Privacy Framework certification or signed DPA for that processor exists on our record today.
• 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, and said that every right on this page — including the supervisory-authority complaint route — remained exercisable from inside the EU (not true while mail bounces; corrected 2026-10-13, above). 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.