Blocked.fyi — Evidence, in the Open

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

When a page becomes inaccessible, the error message rarely tells the whole story. Is the resource unavailable everywhere, restricted in one region, or affected by a temporary network problem? And where can someone find the legal context needed to investigate further?

Blocked.fyi grew from the idea that these questions deserve a transparent evidence trail. Its intake approach is inspired by bribes.fyi, its network-verification approach by OONI Explorer, and its focus on notice transparency by Lumen Database.

What it does

Blocked.fyi is a civic-tech prototype that organizes reports of inaccessible content into inspectable evidence dossiers.

The workflow has five stages:

Report → Verify → Corroborate → Legal RAG Grounding → Evidence Dossier

People can submit a public URL, describe the symptom, and provide a reported region and optional internet provider. The application records the lead, processes network-check results, and presents technical observations alongside relevant legal research.

Each dossier includes:

• The original citizen report and verification status.
• Probe responses, timings, and matched blocking strings.
• Procedural indicators with explicit unknown states.
• Retrieved legal-source summaries and citations.
• JSON export and a print-to-PDF layout.

The public feed supports filtering by status, platform, and region.

How it was built

The frontend uses React, Vite, Tailwind CSS, React Router DOM, and Lucide icons.

The backend uses FastAPI, SQLAlchemy, Pydantic, and SQLite. A persistent verification queue tracks reports and allows interrupted jobs to be recovered. HTTPX supports concurrent checks through independently configured proxy routes.

The research layer uses a local FAISS index over curated legal-source summaries. The current implementation uses deterministic, source-grounded generation rather than an external LLM.

Challenges

The central challenge was separating observable facts from interpretations.

A failed request does not establish censorship. An HTTP 451 response does not establish who issued a restriction or whether it is lawful. Similarly, an unavailable legal document does not prove that a procedural safeguard was absent.

The interface therefore preserves uncertainty: unknown indicators remain unknown, inconsistent probe results remain inconclusive, and simulated observations are clearly labeled.

Another challenge was keeping repeated probe samples visible so that a single successful response would not conceal an earlier failure.

Accomplishments

The prototype connects citizen intake, background processing, an evidence feed, statutory research, and exportable dossiers in one working application.

Its strongest feature is transparency: users can inspect the observations behind a classification and distinguish those observations from legal research.

Validation includes 28 passing backend tests, 11 passing frontend tests, and a successful production frontend build.

What I learned

Building the prototype reinforced that evidence quality depends on preserving uncertainty as much as collecting data.

It also highlighted the importance of distinguishing reported locations from verified probe locations, technical availability from content accessibility, and relevant legal context from a determination of legality.

Current prototype scope

The demonstration uses explicitly labeled mock network fixtures. These fixtures do not contact submitted URLs and do not establish real restrictions. Simulated reports are excluded from confirmed-block statistics.

Live checking requires independently configured and geographically verified proxy routes. The legal corpus is a limited source snapshot, and the prototype does not independently locate blocking orders or notices.

Automated research analysis; not a formal determination of legality or legal advice.

What's next

• Configure and validate independent regional probe infrastructure.
• Expand and maintain the legal-source corpus.
• Add document-based corroboration for notices and orders.
• Improve measurement coverage and repeatability.
• Add the privacy, moderation, and operational controls needed for public deployment.

Built With

• faiss
• fastapi
• httpx
• javascript
• lucide
• numpy
• pydantic
• pytest
• python
• react
• react-router
• sqlalchemy
• sqlite
• tailwind-css
• testing
• uvicorn
• vite
• vitest