They speak of "QR-style" barcodes, but it's very unclear to me whether GS1 is actively pushing QR or DataMatrix as the preferred 2D barcode style. In medical devices and pharmaceuticals, both the 1D and 2D DataMatrix GS1 barcodes have been used extensively for quite some time so I would personally think DataMatrix is the way to go. I'm just a casual observer though. Is there anybody here that has more inside knowledge on what the game plan is?
I like the invalid. TLD. Naming things is hard and that's a good one to use when you need to provide a FQDN that serves no actual purpose. Case in point: Amazon CloudFront always requires you to provide an origin, even if you're not sending any traffic to it. So using something like "origin.invalid" makes it just a tad more self-explanatory.
Me too. I just gave up and bought an ASUS H5600QM with a 5900HX (and 3840x2400 OLED, 32G socketed RAM, 2 NVMe sockets, and 3 physical touchpad buttons). If you act fast, you can still buy the version with Windows 10 and a GTX 3070 at $1999, instead of Windows 11 and a GTX 3060 for $254 more.
Build quality is excellent, but the first one died after 2 days: charge light wouldn't even go on. Waiting for #2. Wish me luck!
Wouldn't a company such as WhatsApp (Facebook) drop the Belgian user base in a heartbeat if they would actually be confronted with a law like this? My guess is they would much rather lose a few million users than having to deal with the bad publicity and the intrusive technical challenges that come with a requirement such as this.
I totally agree that it's probably worthwhile to implement some country specific logic for a user base of that size and ad revenue per user. But specifically with regards to this, I really can't imagine they would agree to do this. Suppose they do, it's probably not a bad guess that they would lose more users globally due to the bad publicity it would generate than they would lose by cutting off Belgium.
On the technical front, your examples are good and valid, but they seem like features that are pretty straight forward to feature flag per country. Something like disabling end-to-end encryption looks a lot more intrusive to me (without being a subject matter, feel free to correct me). Whatever WhatsApp built, they built it to enable end-to-end encryption on a global scale, to enable anyone from around the globe to send an encrypted message around the globe. Poking a hole in that seems non-trivial.
As a Belgian I guesstimate that WhatsApp has more than 80% of IM market share here.
> it's probably not a bad guess that they would lose more users globally due to the bad publicity it would generate than they would lose by cutting off Belgium.
But this is what all the tech companies do in China.
I don't think its hard to "defend" complying with the Belgian government that faces a terrorist network and drug cartel problem bigger than any other 1st world country (in relative terms).
> Poking a hole in that seems non-trivial.
They operated without E2E for many years though. I doubt that non-encrypted chat is even revoked.
And even if they pulled, there's many alternatives available. It's not like Belgium is worried about Meta's revenue.
Meta doesn't operate in China though, for not wanting to comply with their requirements of state-controlled censorship. I could see them applying similar reasoning here on principle (my god, I just used 'Meta' and 'principle' in the same sentence, I must be high). Another tech company might jump in that hole of course.
With regards to E2E, I wonder how it would work when you want to chat with someone outside Belgium though. If I'm the person outside Belgium, I wouldn't want E2E to be disabled just like that. And if WhatsApp can only be used between Belgians, that's quite a hinderance.
Belgium doesn't care about Meta revenue and rightly so, but if a law would be the reason that Meta pulls the plug on Belgium, that seems like a cause for a possible serious political backlash.
I wouldn't give FB/Meta _too_ much credit. I'm pretty sure they would comply with China's regulations if they were able to. It seems much more likely that FB cannot effectively moderate the amount of content people post and cannot comply.
For your second point, to me that's the same kind of feature work GP was talking about: Just add a little UI that says "Hey, you're speaking with someone in a country that doesn't support encryption. Your messages are unencrypted".
Also agreeing with GP, screw Meta! As a Belgian I could care less about one company when it comes to the rights and laws of my country. They can definitely make suggestions like everyone else, but they also need to follow each country's laws like everyone else.
Just picked up a mint condition E7470 (i5) with 16GB RAM, 256GB SSD and a new battery for €230. Decent Linux-friendly machine that should last quite a few more years normally. Dell Latitude machines are always worthwhile to consider, both new and second hand.
AFAIK, nobody has suggested removal of OCSP from end-entity certificates. This article you linked (and the comment you wrote) is purely about removal from intermediate CA certificates.
The majority of OCSP traffic will probably be for end-entity certificates; most OCSP validation (in browsers and cryptographic libraries) is end-entity validation, not leaf-and-chain.
Removal of intermediate CA's OCSP is probably not really relevant to their overall OCSP performance numbers (and if it was, it was likely cached already).
There's an argument for not doing OCSP on end-entity certificates if you can approach the lifetime for the certificates that you'd realistically need for OCSP responses anyway.
Suppose you promise to issue OCSP revocations within 48 hours if it's urgent, and your OCSP responses are valid for 48 hours. That means after a problem happens OCSP revocation takes up to 96 hours to be effective.
If you only issue certificates with lifetimes of 96 hours then OCSP didn't add anything valuable - the certificates expire before they can effectively be revoked anyway.
Let's Encrypt is much closer to this idea (90 days) than many issuers were when it started (offering typically 1-3 years) but not quite close enough to argue revocation isn't valuable. However, the automation Let's Encrypt strongly encourages makes shortening lifetimes practical. Many of us have Let's Encrypt certs automated enough that if they renewed every 48 hours instead of every 60 days we'd barely care.
The solution to excessive OCSP traffic and privacy risk is supposed to be OCSP stapling instead, but TLS servers that can't get stapling right are still ridiculously popular so that hasn't gone so well.
I bookmarked this once when stumbling across it: https://librehealth.io/. It's an open source Electronic Health Record keeping system, so sounds like it might suit your needs.
I also read this book a few weeks ago after having stumbled upon it in a HN reading list somewhere. Though enjoyable, I have to agree wholeheartedly with your statement about it being pretty repetitive. It started off really good but I was happy when I finished reading it.
I've always enjoyed reading Bryan Cantrill's stuff and watching his talks. That goes for this first episode of their new podcast as well. Interesting tidbits of computing history.
