Based on the screenshots it looks like the mac address is leaking out because its in the referer. I would guess this isn't intentional and shouldn't be hard to fix.
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.
While the mac address is a particularly egregious note, really they shouldn't be sending any data to ad firms whatsoever without consent, and fixing the referrer alone won't help much.
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.
Consent is not needed for quite a bit of electronic marketing. It is for setting cookies, which is probably going on here to facilitate the marketing, so your point stands, but it's a breach of the ePrivacy Directive not GDPR so fines are lower. No excuse though.
For the marketing itself consent isn't needed, but for collecting/processing personal data for marketing I'm pretty confident it is. Why wouldn't that fall under GDPR?
Perhaps they are not storing the personally identifiable data (unclear whether the MAC addresses are logged on-site), but are merely passing it on to advertisers for their own use. Neat loophole if that is the case.
Not a loophole, clearly in violation. The collection itself is already problematic, passing it on makes it a lot worse. They will have to paint this as an oversight and fix it pdq or they might get themselves in real trouble.
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.