DefenceHackYeah 2026 finalist

SafeWall

Mikformatycy · Mikformatycy/SafeWall

Council score

Median of 3 models, weighted by the task's official criteria
59.0 / 100

An honestly documented and well-designed privacy-gateway concept with a genuinely engineered router base, but the features that define it as a defence tool (Tor routing, fail-closed protection, DNS filtering, live panel) exist only as plans, mocks and a recording.

Criteria · line = median, dots = each member
Idea & Innovation30%
6.0

A concrete threat model (radio tracking, telemetry domains) aimed at a real gap for journalists, with unusually honest limits. Pocket Tor routers are a known category and every differentiating feature is listed in the team's own docs as planned or untested, so a 6 rewards strong reasoning over delivered novelty.

Relation to Category20%
8.0

Unambiguously security and resilience work: preventing radio-based exposure and traffic identification for civil-society users. The score sits below the top because the resilience half, operation in a degraded scenario, is described only as future acceptance criteria and never demonstrated.

Practical Applicability / Usability20%
4.0

The intended flow of one cable and a glance at a panel is right, but the LTE link measured about 1.4 kB/s with unresolved timeouts, the dashboard runs on demo data, and operation needs root Linux rigs and SSH over USB. Member B's 2.5 is defensible given the broken data path, but the evidence and the team's own honest documentation support the median view that the concept is right while nothing is field-usable today.

Design (visual/UI)20%
7.0

Coherent craft: a full brand system with scripted logo exports, a generated 8-slide deck, Blender CAD renders of the powerbank-like enclosure, and a clean CSP-hardened dashboard with offline preview. The score reflects real polish that rests on renders and simulated statuses rather than verified live views, which supports the median over Member C's 6.

Completeness & Implementation Value10%
3.0

The router base is real and tested (nftables isolation, DHCP/DNS, 28 test cases including a namespace suite), but the defining security features are absent from code: no torrc, no Tor redirect rules, no fail-closed kill-switch, no DNS filter, and the API returns 503. Member B's 1 is too harsh given the tested router base and Member A's 4 slightly overcredits unimplemented claims; Member C's claim that DNS filtering is present in the repo is contradicted by STATUS.md and the other two reviews, so the median of 3 stands.

Members disagree here: scores range by 3.0 points.
Source lines9,559
Tests28 cases
Claims built3.0 / 10
Task fitYes

Strengths

  • Genuine hardware prototype (Raspberry Pi 4 with PiTalk EG25-G modem) and tested router plumbing: nftables segment isolation, DHCP/DNS, WAN detection, USB admin isolation, and 28 test cases including a network-namespace router suite.
  • Exceptional epistemic honesty: STATUS.md, README and the draft consistently separate verified results from plans and label the dashboard as demo-only.
  • Clear, realistic threat model for journalists under radio surveillance that states what the device does not protect against.
  • Strong reproducible design pipeline: vector brand identity with scripted exports, a generated jury deck, and CAD concept renders of a discreet powerbank enclosure.

Weaknesses

  • The core security claims are not in code: no torrc or Tor redirect rules, no fail-closed kill-switch, no DNS filter, and the committed config still implements the earlier direct NAT to the modem.
  • The LTE data path was broken at submission (about 1.4 kB/s with unresolved timeouts on Pi, Mac and reportedly Windows), so the device has no usable connectivity.
  • The dashboard runs on simulated data while its real API endpoint returns 503 DATA_SOURCE_NOT_CONFIGURED, and no live demo was verified (demo checks empty).
  • The task's required degraded-scenario demonstration was never shown, existing only as planned acceptance criteria, and the submission form was largely empty with no reachable hosted demo or working video link.

Red flags

  • mock-check-tor is a static green Tor Check page built for presentations: disclosed as a mock, but designed to visually assert a security state the repo cannot reproduce.
  • The positive Tor Check rests on a user-confirmed recording whose demo segment was cut and sped up 1.35x, and the presentation's video link points to a placeholder youtube.com URL rather than the promised film.
  • Simulated dashboard data is presented alongside security claims while the device has no working protection path.
Built during the event: unclear: 2 commits by 1 author, 2026-10-03 17:43 to 2026-10-04 08:40 UTC, so the history is squashed
Live demo: none found in the form or README
Council v8
Aclaude:glm-5.3-flash60.090% agree
Bdots-studio/dots-3-note-preview:free56.580% agree
Cinclusionai/ling-3.0-flash-sante:free57.080% agree
Jclaude:glm-5.3–judge
A HackYeah 2026 finalist, queued automatically for a council review; the council wasn't told how it placed. The council read an evidence pack built from the repo, its decks and docs; it didn't run the code or see the pitch.
The site is open source

The council, the evidence pack, the prompts and the queue are all on GitHub. If a review helped you, a star helps other teams find it.

Star on GitHub