What's in this release
This release adds the beginnings of a trust layer to RuView's WiFi sensing — the plumbing so
the system can eventually say either "here's my answer, and here's proof it's trustworthy right
now" or, honestly, "I don't know" — instead of quietly guessing when conditions have changed.
Think of it like a nutrition label for a sensor reading: not just the number, but where it came
from, whether the sensor was properly calibrated, and whether anything's changed since.
It also folds in WiFi Veil, a separate defensive project that showed up as its own new public
repository (ruvnet/wifi-veil) in the last release.
New capabilities
- Better benchmark and evaluation data pipelines — RuView can now ingest a well-known public
WiFi-sensing benchmark (Widar3.0), data from newer high-resolution WiFi hardware, and a rig for
checking vital-sign (breathing/heart-rate) accuracy against ground truth. - Five safety fixes from an outside review of the codebase, the two most important being:
- A fix for a network security gap: the sensor's data port could previously be reached by
unintended senders. It's now checked on every incoming connection. - A new automated check that catches a specific kind of broken AI model before it ships — one
that outputs a number which technically always says "someone is present," no matter what it
actually sees. (A model like this was published earlier; this release prevents a repeat, though
it does not remove what's already out there — see "Known limitations" below.)
- A fix for a network security gap: the sensor's data port could previously be reached by
- The first building blocks of a "trust chain" — nine new components for calibrating a sensor,
cryptographically signing that calibration so it can't be silently altered, and checking whether
current conditions still match what the sensor was calibrated for.
Honest status of the "trust chain" — please read this
This is a preview, not a finished, self-enforcing feature. The new components (calibrate →
sign → check → allow/deny an action) are each well-built and each pass their own tests — but
they are not yet wired together, and nothing in the live sensing server uses this chain yet to
actually stop a bad reading from being trusted. It's like building a smoke detector, a sprinkler
system, and a fire alarm — each tested separately on a workbench and working — but the wires
between them haven't been run yet.
Two of the five safety fixes above are the exception: the network port guard and the
CSI-data-policy checker (below) are fully wired in and active today.
A full write-up of this finding is documented in the codebase at
docs/user-guide.md → "Perception Certificate Spine (Developer Preview)", and in this
independent review.
Verification (independently re-run, not taken on faith)
- Full automated test suite: 4,337 tests passed, 0 failed.
- Deterministic signal-processing proof (a fixed reference signal must always reproduce an exact,
bit-for-bit fingerprint): passed. - Full workspace re-compiled cleanly after merging this alongside the WiFi Veil release.
Known limitations
- The already-published AI model mentioned above has not been taken down — that decision needs
a maintainer, and this release only stops the next broken model from shipping. - A repository check for accidentally-committed raw sensor recordings (which can contain
identifiable personal data) is active in CI and is currently failing — 6 pre-existing
recordings (~64 MB) from before this release are still tracked in git history. Their removal is
intentionally left as a follow-up decision for whoever owns that data, not something silently
swept aside. - No ESP32 hardware or Python code was touched by this release.
Docker image
docker pull ghcr.io/ruvnet/RuView:bf17fc0407e28eb136a6da3b02f0a457a724efdb