So instead of a trail of unsuccessful discovery broadcasts followed by one association - all with the same randomised MAC address, there is a unconnected set of transmissions - all with a different MAC address. Of course, if you are the only active client device around then none of this matters. It is trivial to stalk you regardless of MAC address.
Now you’ve nailed it! Agreed.
In reality, things are never quite as simple as that. A truly motivated stalker could use fingerprinting and/or traffic analysis to assist with the stalking even if you use only randomised MAC addresses. So I think best practice is to disable any kind of active discovery.
Well said. Neighborhood traffic analysis for the purpose of identification is trivial, and ironically even moreso if you’re using a VPN or Tor. It may never again be possible to hide one’s identity against an AI-enabled, locally present adversary with such capability. Obfuscation may work for a while but it’s nonperformant and also likely doomed in the next few years. And analog fingerprinting is probably easier still, although it would require ASICs. None of this makes me feel secure, but at least we can protect ourselves against, say, cartel levels of sophistication, wherein they own the towers but don’t have the smarts for any of these enhanced identification methods.
I believe that having a hidden SSID is considered not best practice - because the SSID will ultimately be visible anyway.
I think you mean that, even if the client never enables wifi outside the WAP’s radius, the SSID will eventually become known because it’s embedded into the association process (“Hey @hotel_wifi, let’s connect…”) which will be observed at some point?
If they have to fix bugs in the VPN client implementation to go in the router then that would likely benefit the VPN client that you could run in the client device and likewise if there are existing bugs that don’t get fixed then they will be in the router just as they are in the client device.
I hadn’t considered this but at least in the case of the notoriously racey firewall killswitches, this would indeed apply. I’m just stunned that, quite obviously, nobody at some of the biggest VPNs on the planet has actually taken half a day to sit down with a packet analyzer and do the work to see if anything leaks during handshaking. And ditto with DNS. That would be an implicit requirement in Purism’s case. I don’t think anyone would complain if doing proper leakage analysis adds $10 to the pricetag.
If I were that concerned about WiFi leakage, I wouldn’t use WiFi on the LAN side at all. That is, I rock up in the hotel room with my pocket-sized router. The router’s WAN side connects to the hotel WiFi,
Sorry, that’s actually what I meant. So the Ethernet WAN plugs into the Purism repeater (which gets USB power, and only power, from the Purism router). (And the repeater itself can be configured via Ethernet. Wifi configuration is a can of worms because you need to alternate between config mode (new SSID/MAC for setup and bonding purposes after reset pressed) and dead mode (no activity at all, other than waiting for a second reset press during transport between locations).) Then the repeater converts Ethernet to wifi, and talks with the hotel’s wifi. Therefore the user could plug their laptop into the LAN, and thus indirectly access the wifi portal and ultimately the internet. (Again there’s the separate question of how to interact with the portal without leaking OS fingerprints. Worst case, a bootable USB with a different OS would be helpful in this regard.) But for going from a standard phone, one would need a WAP on the router. But that’s fine because it would have a new SSID and MAC for the new hotel room.
I’m feeling that flexibility of hardware configuration, compactness and sales volume might be in conflict.
Whatever it takes to make this viable, even if that means a slightly larger footprint. But compactness where possible, like none of the usual superfluous internal air space, or antennas that stick out and you can’t unscrew.
It would great if the router itself could handle the [portal] login - rather than proxying it from a connected client.
That would be a very strong value add but I think it’s really hard. You have to likely use AI to understand where to put the username and password, even if I provide those to you via some standard UI window. Maybe you could have AI as the “usually works” default option with direct user access as an opt-in fallback.
Done!