Capabilities
What Roost looks at
Nine capabilities, in the order a household benefits from them. Each one says what it does today, gives the numbers, names the command that proves it, and states what it does not do yet. The gaps are not in smaller type, because the gaps are the reason you can believe the rest.
It finds every device
Four passes, cheapest and quietest first: a rate limited UDP nudge across the subnet so your own computer resolves who is there, the neighbour table, an SSDP M-SEARCH, and mDNS or DNS-SD. Then a short, curated TCP connect probe per device that reads an HTTP title, a service banner and whether anything asked who we were.
Naming is a pure function over what the device published plus what answered, and it says unknown rather than guessing, because a Tuya plug and a Tuya vacuum look identical on the wire. The maker comes from the public hardware registry, so a device that will not say what it is still shows who made it.
Televisions, printers, 3D printers, doorbells, thermostats, vacuums, baby monitors, smart displays, EV chargers, solar inverters, robot mowers, locks, plugs, bulbs, hubs, consoles, network storage, wearables and the rest.
Three refusals that make the list true
- An IPv6 /64 is never swept. There are more addresses in one than a scanner can visit, so IPv6 devices are found by being told about them: the neighbour table, an mDNS AAAA record, or the router's own list.
- A device on another interface is not a device on this network. AirDrop peers and virtual machines live on their own interfaces, and listing one as being on the household's Wi-Fi is a defect, not a false positive to tune later.
- Nothing wider than a /22 is enumerated, and a range you type in by hand is refused.
Verify it against your own network
cargo run --bin roost-probe network
A bench harness that is never bundled and only reads. It is how five wrong device classes and three false claims on screen were found, rather than by a test.
Not yet
A device that publishes nothing and answers nothing is a maker and an address. Roost tells you that plainly and offers what it can check, rather than inventing a class for it.
It reads your router
Three read modes, and the app always says which one it is in. Without a password it reads what the router publishes to anything on the network, including the port forwarding table over UPnP IGD. With your password it signs in the way the router's own login page does and reads the settings themselves.
The password goes to the operating system's keychain and nowhere else, one entry per router address, and disconnecting deletes it. Credentials and session tokens are types that cannot be printed, so one cannot reach a log by accident.
Your home's public address is read and deliberately never shown. A report is easy to share, and a home's public address identifies the household.
An unread setting is not a pass and not a failure. It means this router does not tell Roost, or nothing has connected to it yet. A blank tile would read as a pass, so there are none.
The Roost interface, rebuilt from the product's own design tokens with the example network from the design brief. Not a screenshot.
The honest state of the readers
Four protocols are written and unit tested against the shapes those routers return: ASUS asuswrt, NETGEAR SOAP, Synology SRM, and Ubiquiti AmpliFi. Only AmpliFi has met real hardware. The app labels every one of them verified written or planned, and says so on the screen where you would pick yours, because a green tick on an untested protocol is the same overstatement this product exists to avoid.
If your router is not one of them, Roost still reads what it publishes without a password, and Wi-Fi encryption is read from this computer's own connection, which works on the provider-supplied box that no reader can log in to.
It ranks what is exposed
Twenty rules, in a signed check pack that is data rather than code. Every rule carries its severity, how far the exposure reaches, how sure Roost is, the weight it deducts, what an attacker could actually do, and what would have to be true first.
Three severity levels and never four: urgent, needs attention, and a plain note. Consumers do not need a four step ramp, and three levels stay visually separable where four do not.
Scoring is per device worst. A device deducts once, at its highest open finding, so two problems on one camera are one camera to fix. The score is recomputed from what is still open every time it is shown, and never stored as truth.
Verify the pack cannot be tampered with
build/verify-pack.sh packs/home-core
What the twenty rules are about
- A device your router is forwarding outside traffic to
- Controls that answered without asking who we were
- A video stream with no password on it
- Firmware behind the build the maker has published
- A model known to ship with a factory login, reported as possible and never tested
- Data going to servers outside the US and EU
- An address the internet can reach directly over IPv6, with no NAT in the way
- Wi-Fi with no password, with WEP, with the first version of WPA, or on WPA2 where the router already offers better
- WPS, remote administration, UPnP, DMZ, a firewall switched off, a guest network that is not kept apart, management frames left optional, and your provider seeing every lookup
Content is data, not code
Rules, weights, explanation copy, the hardware registry, firmware records and router adapters ship in a signed pack. The core verifies the signature with a pinned key before anything parses the bytes, and a failed verification leaves the previously verified pack in use. Rotating that key is an app release on purpose: a pack cannot introduce the key that vouches for it.
It shows the evidence
Every finding carries a real observation, a timestamp, and where the observation came from. A rule whose evidence, copy or fix came out incomplete is a pack defect: it is logged and dropped, not rendered half built. That is why there is no such thing here as a warning with nothing behind it.
It also refuses to claim more than it saw. Roost cannot prove from inside your house that a port answers from the internet, so it does not say that it does: the forwarded port finding is read from the router's own table, and the evidence line says exactly that.
Verify that a finding cannot render without its evidence
cargo test rules
pnpm --dir web test pack
It walks you through the fix
Numbered steps a non-technical person can follow, each with what you should see when that step has worked, which is the part most instructions leave out. A difficulty and a realistic time in minutes. Where Roost knows the make of your router, it opens the right page on it.
At the end it runs the real check again. Marking something as fixed goes through the same mechanism that found it, so if the exposure is still there, Roost says so, the score does not move, and no green mark appears. A finding a re-check cannot settle on its own says the next scan will cover it, rather than guessing.
Verify the honest path, including the fix that did not work
pnpm --dir web test flow
And it never does it for you
Roost is read only. It walks you through your own router's interface; it does not log in and change the setting, and it cannot block, quarantine or cut off a device. That is a deliberate limit, and it is the reason a household can be told to trust it with a router password.
Not yet
Deep links into a specific firmware's settings pages only exist for the routers whose readers exist. On everything else the steps name the setting and where routers usually keep it, including the three or four other names the same setting goes by.
Wi-Fi, and the perimeter itself
The weakest thing in most homes is the network everything else sits on. Wi-Fi encryption is read from this computer's own connection, which needs no router password and works on the provider-supplied box that no reader can log in to.
Ten settings are defined with a plain English subtitle and their own deduction: Wi-Fi security, WPS, remote administration, UPnP, firmware, the guest network and whether it is kept apart, DNS, DMZ, the firewall, and whether management frames are protected. Twelve rules turn a setting into a finding that reaches the list and the score, rather than sitting on the router screen alone.
Whether your devices can reach each other is checked as well, which almost every household allows without knowing it, and which is what turns one weak device into a problem for all of them.
A blank never reads as a pass
Every setting the pack knows about is listed, with what was actually read laid over the top and the rest marked as unread, in words: not a pass and not a failure, it means this router does not tell Roost. A missing tile would have been read as a clean result, so there are none.
Verify what is protecting the network, and what could not be read
pnpm --dir web test posture
Needs your router's cooperation
WPS and guest isolation cannot be read without signing in, so on a router with no reader they stay unread rather than being assumed. Growing that coverage is the same work as growing the reader list, and it needs the hardware in the room.
Where this computer sends data
A map you can zoom to 24 times, pan, and click to isolate one flow, drawn from real geography: Natural Earth geometry projected properly, and vendored inside the app, so it draws with the network cable pulled. Endpoints in one city collapse into one labelled node, arcs are great circles, and packets travel them at a rate derived from what was actually measured.
Destinations are placed from 68 curated address ranges that ship in the pack. Nothing is ever looked up, and an address Roost cannot place is reported as unplaced rather than quietly treated as domestic or dropped at zero, zero.
Roost does not know where your household is and will not find out. You click roughly where you live so the arcs have a starting point, and that stays in this browser profile.
What Roost cannot show you, and why
Roost cannot show what your other devices send. On Wi-Fi your router sends each device's traffic only to that device, so no program on this computer can watch the television or the doorbell, at any privilege level. Measured on a real network: 338 of 400 packets were this computer's own.
Seeing every device would mean the router reporting it, which is the same road as the reader list. So the screen changes its own headline to say it is showing where this computer phones home, and explains the rest. Half an answer, labelled, beats a borrowed one.
Verify the map only shows what was observed
pnpm --dir web test map traffic-map
And it is rated, not just drawn
A camera or a microphone sending data outside the US and EU is urgent; the same destination from a laptop is worth knowing about. Unencrypted traffic is flagged even at home. That rating is pack policy with the pack's own words as the reason, first match winning, and it is not code.
It tells you when something changed
A scanner you have to remember to open protects nobody, so Roost keeps history: an encrypted database in the operating system's application data directory, with its key in the keychain.
A device keeps the day it was first seen across runs, so new this week is real rather than a guess about this session. A finding that was fixed and comes back keeps its original fix date, gains a drift date, stays the same finding, and lands in the ledger as something that returned. The name you give a device outranks anything the network said about it, and survives the next scan.
A household does not need three years of this, and the data describes their home, so the history is deliberately short.
Proven, not asserted
A test reads the database file back off the disk and asserts that it does not begin with the bytes that mark a plain database, and that it contains neither a device name nor a hardware address in the clear. Another proves a second key cannot read it. Delete everything removes the database, its side files, and the key that could read them, and then proves the files are gone.
Verify encryption at rest yourself
cargo test store::tests::the_database_on_disk_is_not_readable_as_a_database
Not yet
Roost notices a change while it is open. Watching for one in the background needs a helper that runs when the app does not, and that helper is the same piece of work as the traffic capture. Until it exists, this is history you look at rather than an alert that finds you.
The report, and your phone
The report is one self-contained document: no stylesheet to fetch, no font to download, nothing to phone home. The network, the score, the ranked findings with their evidence and timestamps, the full inventory, the router's settings and forwarding table, where data went, and what was checked. A section with nothing behind it says so rather than looking empty.
Hardware addresses are off by default and the document says why; turning them on adds a line about thinking who you send it to. The PDF route is your own system print dialog, where Save as PDF already lives, because Roost bundles no PDF engine and the file should be made by machinery you already trust.
Verify the report gives nothing away by accident
pnpm --dir web test report
The phone is a viewer, and only a viewer
- Off by default. No listener until you ask for one, and none after you stop.
- Bound to the network you are on, and a VPN is refused outright.
- Read only: three known paths, and no verb that changes anything.
- Sealed rather than merely local: one short secret becomes two keys, responses are sealed, and every request carries a proof over its method, path and a fresh number.
- A recorded request cannot be replayed. A stranger on your network gets a refusal and a body of "no".
- It offers no way to scan, fix, re-check or connect anything, and a test asserts that no button label ever says otherwise.
Verify the phone can only look
pnpm --dir web test mobile
cargo test link
The honest ledger
Delivered, partly delivered, blocked
The product repo keeps a file of the capabilities a household needs, with a note on every one that is delivered, partly delivered or blocked. This is that list, and it is the same list the people building it work from.
Delivered
- Carry out the fix, with the household
- Tell them when it changed, while the app is open
- Look at IPv6 as well as IPv4
- Place destinations without asking anyone
- Answer "I do not recognise this device"
- Wi-Fi encryption, with no router password
- Byte counts for this computer's own traffic
Partly delivered
- See the traffic: this computer's own flows are read with no privilege at all. Per device traffic belongs to the router.
- Know more routers: the honesty layer and the verified-on labelling are in; the readers themselves want real hardware.
- Check the router itself: the settings that need no password are read; WPS and guest isolation wait on a reader.
Blocked on something software cannot decide
- Router readers need real hardware to verify against, one brand at a time.
- Installers need a signing certificate and a notarisation account, which is a purchase and an identity, not a commit.
One thing is worth stating twice because it sounds like a missing feature and is not: Roost cannot show what your other devices send. That is a property of how Wi-Fi works, not a gap in the product, and no amount of privilege changes it.