2 Commits

Include renames

Author	SHA1	Message	Date
mrambossekandClaude Fable 5	c19f382640	privacy: scrub identifiers inside raw shell output ... Running the Shizuku tier for the first time uploaded every MAC address on the local network to the server at the balanced level - fourteen of them, router and all. The probes embed raw command output verbatim (ip neigh, ip route), which is good evidence and also a complete household device inventory, and the anonymizer could not see it: classification is by field name and whole-value shape, and ip_neigh is one long string that is itself neither a MAC nor an address. measurement-schema.md flagged raw dumps as hard to anonymize and proposed dropping them from exports. Scrubbing is better: identifiers inside unclassified strings are replaced in place with the same pseudonyms used elsewhere, so a MAC appearing in both a parsed field and a raw dump still reads as one device, and the dump stays readable - neighbour-table shape, host count, RFC1918 addresses and vendor prefixes all survive. Dropping it would have protected the same data by destroying the reason for collecting it. One pass, not three: sequential passes re-process their own output. Once a MAC became 78:9a:18:xx:yy:zz the IPv6 pattern matched it - six hex groups separated by colons is an address - and destroyed the vendor prefix the MAC rule had just preserved. Ordered alternation resolves each position once, MAC first. RealDocumentTest runs the anonymizer over a captured run when ECHOLOT_REAL_RUN points at one and fails on any surviving MAC; it self-skips otherwise so no one's network lands in the repo. Against the document that leaked: 14 in, 0 out. Also: the Settings preview button did nothing, reading UiState.history which is empty until the History screen has been opened - same root cause as the "0 run(s)" count. It reads the archive now, and says when there is nothing to show. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 16:12:13 +02:00
mrambossekandClaude Fable 5	ce1aaa332a	server: send granted traffic from the address the session actually used ... fmr binds two IPv4 addresses. connFor picked whichever socket of the right family came first in the bind list, so a downtrain for a session established on .150 went out from .151 — and every packet was dropped by the client's NAT, which has no mapping for that pair. tcpdump on the server showed all 50 leaving; the client saw none. Read as "100% downstream loss", which is the worst kind of wrong: a confident measurement of something that never happened. Sessions now record which of our own bound addresses received their traffic, and granted sends (and delayed echo) go back out through that socket. The fallback to a family match is kept for the case where nothing has been received yet, and the test pins both paths — a single-homed lab can never reproduce this. Also: the client-side halves of the same work — anonymizer (core-privacy), local run archive with retention (core-archive), upload client, and the app's settings and history screens. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 10:45:43 +02:00