alt Hacker NewsI agree, yet at least you can kind of see where they're coming from.
I guess a better example would be the automatic hardware detection Lenovo Support offers [0] by pinging a local app (with some clear confirmation dialogs first). Asus seems to do the same thing.
uBlock Origin has a fair few explicit exceptions made [1] for cases like those (and other reasons) in their filter list to avoid breakages (notably Intel domains, the official Judiciary of Germany [2] (???), `figma.com`, `foldingathome.org`, etc).
0: https://pcsupport.lenovo.com/
1: https://github.com/uBlockOrigin/uAssets/blob/master/filters/...
2: https://github.com/uBlockOrigin/uAssets/issues/23388 and https://www.bundesjustizamt.de/EN/Home/Home_node.html (they're trying to talk to a local identity verification app seems like, yet I find it quite funny)
> the official Judiciary of Germany [2] (???)
That's the e-ID function of our personal ID cards (notably, NOT the passports). The user flow is:
1. a client (e.g. the Deutsche Rentenversicherung, Deutschland-ID, Bayern-ID, municipal authorities and a few private sector services as well) wishes to get cryptographically authenticated data about a person (name and address).
2. the web service redirects to Keycloak or another IDP solution
3. the IDP solution calls the localhost port with some details on what exactly is requested, what public key of the service is used, and a matching certificate signed by the Ministry of Interior.
4. The locally installed application ("AusweisApp") now opens and displays these details to the user. When the user wishes to proceed, the user clicks on a "proceed" button, and is then prompted to either insert the ID card into a NFC reader attached to the computer or a smartphone in the same network as the computer that also has the AusweisApp attached.
5. The ID card's chip verifies the certificate as well and asks for a PIN from the user
6. the user enters the PIN
7. the ID card chip now returns the data stored on it
8. the AusweisApp submits an encrypted payload back to the calling IDP
9. the IDP decrypts this data using its private key and redirects back to the actual application.
There is a bunch of cryptography additionally layered in the process that establishes a secure tunnel, but it's too complex to explain here.
In the end, it's a highly secure solution that makes sure that only with the right configuration and conditions being met the ID card actually responds with sensitive information - unlike, say, the Croatian ID card that will go as far as to deliver the picture on the card in digital form to anyone tapping your ID card on their phone. And that's also why it's impossible to implement in any other way - maaaaybe WebUSB but you'd need to ship an entire PC/SC stack and I'm not sure if WebUSB allows cleaving an USB device that already has a driver attached.
In addition, the ID card and the passport also contains an ICAO compliant method of obtaining the data in the MRZ, but I haven't read through the specs of that enough to actually implement this.