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.
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.
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.
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.
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.
> Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.
I think this comes straight from the original go team. Rob Pike had a talk[1] that is partly about why go doesn't keep adding features and why it doesn't have certain features that other languages have. I think people who like go have bought into the idea that the go team has made good trade-offs to make go code easier to read and maintain at the expense of expressibility.
I'm not saying that isn't true for some things. I don't think its true here given that this is a nice narrowly scoped library that does a single thing and has well defined semantics.
Adding a cgo dependency is generally something that isn't done lightly by teams. Having a port to go instead of a wrapper around go would be much more likely to see widespread adoption.