PUEO ROOST

No. The files are read in the browser and the rows are built here. Nothing in this page sends them on, and the parsing does not need a server to happen.

The surveillance log and the ESB sniffer log, in either CSV or NDJSON, the wardrive WiGLE CSV, and the jam detector. Files are recognised by their contents rather than their names, because the names carry a millis stamp and not a type.

Packet captures go to Wireshark and .sub files go to a Flipper. Both already have better tools than this could be, and doing them badly here would be worse than pointing at them.

Because that file holds credentials somebody typed into a captive portal. It is named in the file list and never parsed or displayed. Treat it as the evidence it is: it belongs to a person rather than to a device.

Because they are inferred rather than recorded. The surveillance, ESB and jam logs stamp each row with milliseconds since the device booted, which says nothing about when that was.

The wardriver is the exception: WiGLE will not accept a row without a time, so its rows carry one, and its filename carries the millis at which it opened. That pair anchors the rest of the boot. A ~ means the time was worked out from that anchor, not read off the card.

How wrong the match could be, not how interesting it is. Strong belongs to one vendor's product and is not plausibly anything else. Likely fits and could be something unrelated. Weak is corroboration only.

Two differently labelled signatures on one address promote Likely to Strong. They never promote Weak, because two hints agreeing are still two hints.

Because the address prefix identifies whoever bought the block, which is often a contract manufacturer rather than the brand on the box. Those rows are graded Weak for exactly that reason, and a Weak row on its own means close to nothing. It is worth something when a second, differently labelled signature agrees with it.

Either nothing in the list matches it, or its address is randomised. An address with the locally administered bit set carries no vendor, so no prefix is matched against one. Reporting a vendor for a randomised address is wrong in the direction that puts a name on an innocent device.

Tiles from OpenStreetMap, while they are the service in the links picker, which they are unless you change it. That is the one thing in this page that reaches out on its own, and it is worth being exact about what it discloses: not a single point but the area you are looking at and the zoom you are reading it at.

Switch the picker to Google or to no links, or mask positions, and nothing is fetched: the points are drawn on their own with a scale bar as the only reference for distance. A wide drive also falls back to that on its own, because the tile count is capped at a number a public service would call ordinary.

Only the wardriver records a position, and only with a GPS fitted, so a card without one has an empty map either way.

They are a snapshot, baked into this file, and the date is in the footer. Because they travel with the page rather than with the capture, an old log gets read against the newer list: a row that was an unexplained address when it was recorded can be a named vendor now.

To the signature list itself, at magikh0e/surveillance-signatures. A wrong row is worth more to fix than a missing one, because a wrong row names somebody. Evidence beats a vendor name: a capture, a datasheet, a registry entry.

They are read into memory, counted, drawn on the map, and written into the CSV if you press Export. Nothing else is done with them, and nothing is kept.

Nothing is written to local storage, session storage, a database or a cookie, so closing the tab is the end of it, and the page never asks where you are: the only positions here are the ones already in your own file.

Two things do send them outward, and both are visible in the filter row. Drawing the map on OpenStreetMap tiles tells their servers which area you are reading. Clicking a position tells that service the coordinate.

There is one way out and you have to take it yourself. Each position is a link, to OpenStreetMap unless you change the picker to Google Maps or turn links off. A link transmits nothing by existing; clicking one tells that service the coordinate, which is the step that is yours. Both carry rel=noreferrer so they are not also told which page sent you, and mask positions removes the text and the link together.

How many entries are in it, under which portal, and over how long. Nothing else. The file is millis,remote_ip,ssid,username,password; the last two name a person and the IP is per-device, so those three columns are not read out of a row and not stored. Nothing from them is shown unless you open the file deliberately.

The portal name is the one value printed, because that is the operator's own choice rather than anybody's data. The point is to tell you how much is in the file before you decide what to do with it, without putting any of it on your screen.

Yes, from the Files tab. It sends the file as it came off the card rather than the rows this page understood, so nothing is dropped on the way, and nothing goes anywhere until you press the button.

It needs the API name and token from your WiGLE account page. They are held for as long as the tab is open and stored nowhere; the token field is cleared once an upload succeeds, because the commonest way a token leaks is sitting in a form somebody walked away from.

No. These are identifiers that hardware broadcasts without being asked, so a match is evidence about what something is and not about how it is behaving. Almost none of the list has been confirmed against the hardware it names. Treat the rows as leads rather than findings.