Block·Block

Demothis is a product preview, not an official City of New York service. Nothing submitted here reaches city agencies; statuses, briefings and examples are illustrative.

Notice

Security

Block by Block holds anonymous, block-level data in the United States, encrypted in transit and at rest, and its strongest protection is how little there is to steal.

Block by Block is a public demonstrator of a civic participation platform for New York City. It is not an official City of New York service, it is not endorsed by the City, and nothing submitted through it reaches a city agency. It is still built as though it held sensitive material, because people use it to describe the street they live on. This page says exactly where the data sits, who can write to it, how it is protected, and what would happen if something went wrong.

Where the data lives

The database is PostgreSQL, managed by Supabase, hosted in the AWS us-east-1 region in the United States. The serverless functions that read from and write to it run on Vercel and are pinned to the iad1 region, also US East. Both are in the United States, so data about New York City neighborhoods is stored and processed in the country it describes.

The operator is Arcano Zero – AI Lab Srl, a company based in Rome, Italy. Because the operator is European, the GDPR applies to this service in full, on top of the US hosting arrangement.

Encryption

Everything travels over HTTPS. Certificates are issued and renewed automatically, and HTTP Strict Transport Security is applied by the hosting platform, so browsers refuse to fall back to an unencrypted connection. Data at rest sits in a managed PostgreSQL service with platform-provided encryption at rest.

Who is allowed to write what

Row Level Security is enabled on every application table. The public, anonymous database key is deliberately limited: it can do the things a resident needs — file a report, add a corroboration, register for neighborhood alerts — and nothing else. It cannot change administrative statuses. Those writes go through a database function that verifies a secret held only on the server, so a leaked public key does not let anyone reclassify a cluster or rewrite the record.

The administration area

District administration staff use a reserved area at /admin. Without a valid access key, a visitor is redirected to a sign-in page. A successful sign-in issues one cookie, “bbb_admin”: httpOnly, SameSite=Lax, Secure in production, expiring after 12 hours. It carries an HMAC-signed token proving a valid sign-in and nothing else — no name, no identifier of a person. The signature is checked twice: once at the edge proxy, and again independently by every write endpoint, so no administrative write depends on the proxy alone having done its job.

Rate limiting

Public write endpoints are rate limited per client: 6 reports per minute and 4 alert-subscription attempts per minute. This is enough for a person filing several reports on a walk down one block, and not enough to flood a district with automated submissions.

Secrets

Database keys, signing secrets and any API credentials are held as environment variables on the hosting platform. They are never committed to the source code repository.

The strongest control is having almost nothing to steal

Data minimization is the primary security control here. There are no resident accounts, no e-mail addresses, no passwords, no profiles, no IP addresses in the database, no device identifiers, no advertising or analytics cookies, and no user identifier attached to a report.

So it is worth describing the worst case concretely rather than abstractly. If an attacker obtained a complete copy of the database, they would hold: anonymous free-text reports of at most 280 characters, each with a category, a sentiment, a status, a district, an interface language, a timestamp, and a latitude and longitude that were snapped server-side to a grid of roughly 150 meters before ever being written; a table of corroborations containing a report identifier, a timestamp, and a SHA-256 hash computed on the server over a random value the browser generated for itself; and, for visitors who switched on neighborhood alerts, browser push endpoints with their keys, a location snapped to the same grid, and a language.

That is a real harm and we do not dismiss it — a block-level location plus a sentence about a place can matter to someone. But there is no list of names to leak, no credentials to reuse elsewhere, and no way to reconstruct who filed what.

Who else is in the path

If there is a breach

A suspected breach is investigated without delay. Where the GDPR requires it, the Italian supervisory authority — the Garante per la protezione dei dati personali — is notified within 72 hours. A notice is published on this site describing what happened, which data was affected, and what was done about it. Given how little is stored, the realistic worst case remains disclosure of anonymous 280-character texts with block-level locations, and that is how any notice will describe it, without inflation and without minimizing.

Responsible disclosure

If you find a security problem, please tell us. Write to a.megacreator@gmail.com with enough detail to reproduce the issue. We will not pursue legal action or complaints against anyone doing good-faith security research on this site. In return we ask three things: do not access, modify or retain other people’s data beyond the minimum needed to demonstrate the issue, do not degrade the service for residents, and give us a reasonable chance to fix the problem before publishing.

That address is the only contact we have today and it is a personal mailbox. A dedicated address will replace it.

What we do not claim

This is a demonstrator operated by a small team, not a production system run by a city agency. It holds no SOC 2 report and no ISO 27001 certification, and we would rather say so here than let a reader assume otherwise. The controls described on this page are the controls that exist — there is no additional tier we have left undescribed.

If your office is evaluating this project and needs something specific — a written answer on data residency, on retention, on the screening step, or on anything above — write to a.megacreator@gmail.com and we will answer directly.

Last updated: July 27, 2026