I've worked with a number of captive portal systems and they all basically work the same way. The AP/controller intercepts http requests and redirects to the captive portal page with identifying information about the device (ip,mac,ssid,ap_mac,etc.). The captive portal http server shows the user a splash page to accept terms or enter a username/password or a credit card. Once the captive portal server decides the user should be allowed onto the network it needs to communicate that back to the wireless hardware which is done with the user's mac address.
Based on the requests it looks like they have some ads/trackers on the splash page that are getting requests with a referer set to the original splash page url (which includes the client mac address). A no-referrer meta tag or an intermediate redirect would prevent this from happening.
Aside from the data they're explicitly sending in those requests, they're running the response as JS, thereby exposing a bunch of data about your machine & browser, and the response itself is setting a long-term 3rd party cookie too, so that ads on every other site you ever visit can tie all this (and the fact you've used the wifi in this airport) to a long-term profile.
In Milan airport you can make a reasonable bet that most people are EU citizens, so sharing any of their identifiable user data at all for marketing purposes without consent is a huge and expensive no no.
It's not a good look. Referrer aside, I suspect there's no legal option other than dropping this ad script from their wifi login page entirely.
source: https://twitter.com/pimterry/status/1192038174408753152?s=20
iPhone also still sends the device name to the DHCP server when requesting an IP, so if you haven't changed it, it is broadcasting "<Your first name>'s iPhone" to the network.
Awareness of this is probably going up. Comcast is actually running TV ads that point it out [1].
My iphone has no idea what my first (or last) name is, but I still find it irksome that I cannot change my SSID nor can I hide it.
There is no reason I should be advertising the existence of my phone to everyone in (radio) earshot ...
This is not true. While it's intended for MAC addresses to be unique, there are plenty of instances where manufacturers re-use MACs when they run out instead of registering more.
Additionally, there is no issue with multiple devices having the same MAC address as long as they're never on the same Layer 2 domain.
So I'm suggesting that if we know what they are using those for, there could be something fun (like a CCC talk) to be gained from tainting their data in a creative, easy way. Like a few hundred dollars worth of junk devices in a suitcase sending a bunch of carefully crafted MACs :-)
Of course, the location tracking based on your device's network discovery packets is a whole bigger issue.
# echo "lladdr random" >> /etc/hostname.athn0 alias random-mac='openssl rand -hex 6 | sed '\''s/\(..\)/\1:/g; s/.$//'\'' | xargs sudo ifconfig en0 ether'You can scan for the networks in the area, select the one you want, run the name through, say sha256, select the first 8 characters and reset the mac address to that.
I guess you could get around it by hashing the ssid + a personal salt.
Also extends time limites wifi.
Or use my gypsy code
import random
import os
mac=''
os.system('/etc/init.d/networking stop')
os.system('ifconfig wlan1 down')
os.system('ifconfig eth1 down')
os.system('ifconfig wlp8s0 down')
os.system('ifconfig wlp7s0 down')
for i in range(0,3):
__r=random.randint(16, 256)
__mac=mac+":"+str(hex(r))[2:]
mac="00:07:E9"+mac
print mac
os.system('/etc/init.d/networking stop')
os.system('ifconfig wlan1 hw ether '+mac)
os.system('ifconfig wlp8s0 hw ether '+mac)
os.system('ifconfig wlp7s0 hw ether '+mac)
os.system('ifconfig eth1 hw ether '+mac)
os.system('ifconfig wlan1 up')
os.system('ifconfig eth1 up')
os.system('ifconfig wlp8s0 up')
os.system('ifconfig wlp7s0 up')
os.system('/etc/init.d/networking start')
os.system('ifconfig')
print "echo 'MAC changed..."
print "new random MAC "+mac
Edit: typo
A less intense version is to use a PiHole or otherwise block bad domains at the DNS level via a regular ad blocker.
> 403 Forbidden: The server understood the request, but is refusing to fulfill it.
I can't imagine much has changed since then, just add the logic to change the mac address between entering the SSID and actually connecting.
I would assume this is a rare occurrence and if not, it should still be okay to sometimes run into address collisions for advertising purposes.
Thanks for the info.
I'm suggesting that if we discover/think that these advertisers/trackers are using it for anything interesting, there could be some fun to be had at their expense by picking up a suitcase full of junk wifi devices, configuring them to deliberately spoof their own MAC, and visiting that airport. I think you'd only need to spend hundreds on junk devices to taint their system with tens of millions of addresses.
If there's any observable result, I think it'd be fun to do and write it up/present it at a Chaos Computing Congress (or similar) event.