Flashpaper is great if you have a trusted server and a trusted operator running it. Seriously, don't use a random flashpaper server on the internet if you want to keep your secrets secret.
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.
Ugh, I honestly couldn't tell if this article was a joke or not (it seems to not be). The more you read the more absurd it becomes.
I've not heard of JPEG XL before now. Why would you name it that? XL certainly doesn't make me think "wow that sounds like way better compression".
JPEG Blockchain: come on! Are you really so worried about being relevant that you have to talk about blockchains in your press release?
JPEG AI: I could image that this is real, but I'm fairly skeptical of anything that is taking about machine learning and blockchains in the same context.
Its so unnecessary too. A 3x quality improvement is massive. Why not just let that speak for itself? This press release makes me hope just a little bit that JPEG XL loses out to WebP or HEIF.
As an operator, having fewer dependencies I have to deploy and worry about is a boon to my productivity.
If you were building a kafka like system in house for private use only, then yes I agree with your sentiment. If you are building something to be used by hundreds or thousands of organizations then the cost benefit tradeoffs shift to where it probably makes sense to pull the consensus logic into the primary application itself.
As an operator, shouldn't you worry if something battle-tested, that implements extremely critical functions that are tricky to implement correctly, is replaced with something that is unproven?
As someone who enjoys sleeping at night, I wouldn't poke something like that with a stick before it has matured for a few years, and before many brave (?) operators have smoothed out most rough edges by landing on them repeatedly with their faces.
Yeah, don't deploy it when its in beta or its first few releases. At some point it will be stable and safe at which point everyone from then on will benefit.
That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.
If you're just going to copy another language there really isn't much of a point in making a new language. Go is not java, or c# or rust.
Part of the explicit goal stated by the go team is that generics must still feel like go. If you slapped java generics onto go it would not feel like go.
