Feature Request: Randomize address when switching networks

[ajkblue]

It would be a useful privacy feature (maybe as an option in the menu bar) to randomize the MAC address between network changes, e.g. for in the times when I switch between "Café Wifi" and "My Home Wifi". I think something like this, if implemented, would work best if changed between switching networks, when there is no other connection available so it doesn't mess with the current network (as macOS's wifi seems to struggle enough to reconnect when manually changed while connected).

I've noticed that I don't turn my Mac off very often, as most of the time it just sleeps, and the only time that LinkLiar automatically changes the address is upon boot. Too many times I've gone for weeks and weeks on end before realizing that my device and where I've been has been completely trackable among the many networks I switch between because I forget to change my MAC address beforehand. Could something like this be implemented?

[halo]

I like the idea and would find such a feature useful.

would work best if changed between switching networks, when there is no other connection available

Interesting! So you're saying when you open your laptop and there is no network to connect to, LinkLiar should take the chance and randomize the MAC?

[ajkblue]

Yes, that was what I am thinking. Although, now that I've thought about it more maybe it'd be better if it randomized the address upon disconnect from WiFi or right before connecting to a network (maybe while it's searching?) as I would want it to change when moving between networks since I don't often use my Mac when there are no available WiFi connections.

Or, maybe LinkLiar can keep track of the current WiFi SSID and randomize the address if that changes, again not while it's currently connected but sometime before. I don't know which one these methods would be best though.

But basically, I think that at some point between changing WiFi networks the address should be changed, not just when there isn't one available.

[halo]

Hm. The problem I see is that when you open the lid of your macbook and there is a known network, the wifi will connect to it within less than a second or so. I believe that this is not enough time to change the MAC. It would disrupt the connection. I don't think there is such a thing as "searching". Because the airport will almost immediately pick up a known network and begin a handshake.

But then again, I might be wrong :)

[ajkblue]

Could any type of randomization occur once a MacBook has been put to sleep? For example: After using my Mac at home, I close the lid to put it to sleep (LinkLiar randomizes my MAC address) and then when I open it back up at my local Starbucks I have a completely different address. Would something like that be possible?

If that doesn't work, re there other ways you're thinking of accomplishing this to ensure MAC address are changed between WiFi hotspots, or do you think one of the previously mentioned methods would work effectively?

[halo]

So, this is working rather well in my prototype. On boot (before login) and every time you close your macbook lid (sleep) or logout, interfaces are re-randomized if they are configured to be kept randomized.

It is not possible to change the MAC just when the macbook wakes up, because the randomization takes place too late. The interface will loose its connection, which is established first thing of all on wake.

Would that be good enough? I still like the idea of re-randomizing the Wi-Fi when it is not connected to any hotspot. But then again, closing your lid and opening again is the most likely scenario for when you switch hotspots, right?

[ajkblue]

I think that will work really well! Randomizing the address upon boot and sleep (closing and opening the lid) fits the typical use-case how people move between networks perfectly. If this something that's coming out in beta to test, I'd be willing to submit bug reports and try it out. I'm excited to see this in action!

[halo]

I knew I could count on you :)
Be my guest: https://github.com/halo/LinkLiar/releases/tag/2.0.0

[ajkblue]

I seemed to have hit a number of crashes in LinkLiar, most of them seem related to the linkdaemon. From /System/Library/Logs/DiagnosticReports I got these crash reports (there are 12):
linkdaemon_crashes.zip
and from ~/Library/Logs/DiagnosticReports I got this LinkLiar process crash.
LinkLiar_2017-07-07-232552.crash.zip
I am not sure what exactly caused these, as I just barely noticed that LinkLiar wasn't even running this morning. Let me know if there's more info that I can give you!

[halo]

Thank you for trying it out. The daemon crash seems to stem from some logging related code which I temporarily disabled now (which is good, because the daemon obviously got properly installed and run). The GUI crash is a mystery to me yet.

I will create an exhaustive debugging guide, but for now you might try the following.

Make sure to get the new executable I just uploaded at the same place.

To see all debugging logs you can always run this command in a Terminal:

/usr/bin/log stream --style json --predicate 'subsystem == "io.github.halo.LinkLiar"' --level debug

You get a slightly more readable output with this command:

# Assuming your LinkLiar app is located in /Applications
/Applications/LinkLiar.app/Contents/Resources/logs

Those commands only make sense if you're already logged in. If you want logs even on boot, simply create this empty file:

touch "/Library/Application Support/LinkLiar/linkliar.log"

as long as it exists, all LinkLiar components (GUI, helper and daemon) write to that file.

Please keep an eye on these locations/commands:

# The config file, should exist and contain JSON
/Library/Application Support/LinkLiar/config.json

# The daemon executable, should be writable/executable only by root
/Library/Application Support/LinkDaemon/linkdaemon

# Command to reveal PID of helper and daemon component
# So you can see whether they're running
launchctl print system | grep halo

While in the LinkLiar GUI menu, press the option key for the internal developer menu. It should look like this:

You're free to poke around with those and watch the logs for unusual behavior.

Now, sometimes the logs may say things such as "could not create directory" or "could not deactivate daemon" but these are just because instead of checking whether the directory exists, I simply create it every time and instead of querying the daemon first, I always try to unload it etc. That's stuff I will optimize later, for now I keep it as robust as possible.

Let me know if you find out anything. I'm a little perplexed that it crashes for you while it works well for me, but then again, that's what beta tests are good for :)

Oh, and you have Sierra, right? Because it definitely will not work on El Capitan and below.

I'll keep digging on my end.

[ajkblue]

Yes, I am running Sierra 10.12.5. And what I sent you was the only crash I've had with it, and it hasn't crashed since. I've been running logging for 2 days now and I haven't seen any problems with it, and the randomization occurs successfully whenever it goes to sleep and reconnects to Wi-Fi when I wake my Mac like nothing ever happened. So besides that crash from a few days ago, everything seem to be going great!

I'll be sure to let you know if anything goes wrong again and I'll keep logging enabled for now, but everything seems to be working 100% on my side.

[halo]

Thank you very much for your help. I'm looking forward to releasing more docs and tests and a little more polished 2.0.1, but for now, I released the version you tried, 2.0.0, as a regular release.

Again, thank you. After all, you made me do this ;)