v0.72
Update if you are on v0.67–v0.71
Those builds report an unrelated consumer device as a "Likely" ALPR camera.
This release removes the cause.
What happened
The Wi-Fi OUI prefix f8:a2:d6 was withdrawn upstream — "low confidence; hit on a
Sony Media Player" — and FlipDeFlock dropped it in v0.44. A later commit
(93beede) reflowed the two OUI tables and silently put it back. It shipped in
v0.67, v0.68, v0.69, v0.70 and v0.71.
It was not inert while it was there. A device scores Likely on a Flock OUI plus
a wildcard probe request, and every Wi-Fi client sends wildcard probes while looking
for networks — so anything on that prefix was flagged as a likely surveillance camera
for behaving completely normally. A false positive is worse than a missed detection,
and that is doubly true for a tool people use to decide whether they are being watched.
Why nothing caught it
The CI parity gate compared the Flipper's OUI table against the ESP32 companion's and
nothing else. That commit changed both files identically, so the gate passed at
32-vs-32 for five releases while both files' own comments still said 31. Content
parity cannot see a mistake made the same way in both copies.
The gate now also fails on:
- a count comment that disagrees with its own array, and
- any upstream-retracted prefix reappearing —
f8:a2:d6,6c:cd:d6,94:2a:6f,
f4:e2:c6,cc:cc:cc,00:0c:e7— each stored with its retraction reason so it
cannot be "rediscovered" from the older flat OUI list.
The host tests assert the same denylist through the matcher and pin the table size.
Both guards were verified against the failing case: the regression was re-seeded in a
throwaway copy and each guard was confirmed to fail on its own, including with the
count comments edited to hide the first one.
Also fixed
docs/signatures.example.json shipped "ssid_confirmed": ["flock-"], and the docs
tell you to copy that template and edit it. User SSID patterns match as unanchored
substrings, so that value marks Flock-Guest, Flock-Freight-WiFi and similar
benign networks CONFIRMED — the exact over-claim the built-in Flock- rule was
anchored to prevent in v0.47, reached through a supported path instead. Both example
values are inert placeholders now, and docs/signatures.md explains that
ssid_confirmed is the one key where a user file can manufacture a false CONFIRMED.
Changed, with no effect on scoring
docs/signatures.md gains a provenance table for the built-in OUI list. It describes
itself as prefixes observed in fielded deployments, which is true of most but not
all of it: four are contract-manufacturer prefixes (Liteon/USI) that also ship
unrelated consumer hardware, four are inherited from a superseded flat list with no
status in the curated source, and three are rated weak upstream. An OUI-only match
still caps at Possible regardless — this only stops the table's claim reading as
stronger than the evidence behind it.
Signature sources were re-checked against upstream: no new Flock or SoundThinking
prefixes exist that this app lacks. BLE tells are unchanged and current — XUNTONG
company id 0x09C8, Raven GATT 0x3100–0x3500, Penguin- / FS Ext naming.
Verification
Host tests (4,177 checks), the OUI parity gate, ufbt, and both Arduino sketches all
build green, and the fix was confirmed present in the shipped binaries themselves.
Not validated on hardware. As with everything since v0.20, this is verified by
tests and compilers, not against a radio. Nothing here should be read as field-proven.
What's Changed
Full Changelog: v0.71...v0.72
