Seems very similar to how maps work on the web these days, in particular protomap files [0]. I wonder if you could view the medical images in leaflet or another frontend map library with the addition of a shim layer? Cool work!
Thanks! Indeed, digital pathology, satellite imaging and geospatial data share a lot of computational problems: efficient storage, fast spatial retrieval/indexing. I think this could be doable.
As for digital pathology, the field is very much tied to scanner-vendor proprietary formats (SVS, NDPI, MRXS, etc).
In 1970 a massive project crowdsourced thousands of photographs of everywhere in Paris (nearly every single grid square on each letter sized page, a rare few have no photos).
To see the photos, click on a map section to go to the subgrid page. Then find the square grid number that corresponds to where you want to see and click the corresponding numbered link from the list at the top.
Cool site, I especially appreciate the detailed about page [1] including the libraries used for the graphics (paperjs + GSAP) and the bloopers section [2], covering interesting glitches from development.
It's not clear from the linked page, which seems to have been last updated in 2022, aside from user comments asking for support. Thank you for the clarification!
He's also the person behind Practical Typography [0], a great reference/guide for essential typography and layout concepts and terms. It has opinionated recommendations covering nearly everything you'll need to make beautiful documents like this one.
Particularly helpful is the practical advice: how to get the desired results in Word, Pages, or with HTML/CSS; not just high-level abstract guidelines. There's everything from keyboard shortcuts for inserting different dashes (to accompany the explanation on when to use each type) [1] to guidance on page margins in print and on the web [2].
Exactly, this letter refers to the "reconciliation bill" without mentioning the better known (and more notorious) monikers "Big Beautiful Bill" or "One Big Ugly Bill".
There are so many horrific things in it, the bill must be fully opposed, not endorsed with minor changes.
Note that this letter's requests DO NOT include voting against the reconciliation bill, just modifying it to add a carve-out to fix Section 174. While I agree that Section 174 desperately needs reform and is harmful to the tech industry, the bill as a whole must be opposed, not tweaked.
There are many, many things wrong with the "Big Beautiful Bill", too many to fix through piecemeal efforts like this. It must be resolutely opposed, not endorsed with minor changes.
If I recall correctly Figma uses it to connect to the locally installed app, and Discord definitely uses it to check if its desktop app is installed by scanning ports (6463-6472).
I'm aware of two blockers for LAN intrusions from public internet domains, uBlock Origin has a filter list called "Block Outsider Intrusion into LAN" [0] under the "Privacy" filters, and there's a cool Firefox extension called Port Authority [1][2] that does pretty much the same thing yet more specifically targeted and without the exclusions allowed by the uBlock filterlist (stuff like Figma's use is allowed through, as you can see in [0]). I've contributed some to Port Authority, too :)
There are surely other ways to achieve this. If you are logged into an app and the site at tbe same time they can use the server to communicate. Discord doesn't need to know if the app is installed to work. That sounds sketchy.
It's just a way to ensure you open the desired context on a local Discord instance, not any instance that might be logged in to your account. I have a few personal computers logged in on Discord on the same account that could be active at the same time for example.
A comment I wrote in another HN thread [0] covering this issue:
Web apps talking to LAN resources is an attack vector which is surprisingly still left wide open by browsers these days. uBlock Origin has a filter list that prevents this called "Block Outsider Intrusion into LAN" under the "Privacy" filters [1], but it isn't enabled on a fresh install, it has to be opted into explicitly. It also has some built-in exemptions (visible in [1]) for domains like `figma.com` or `pcsupport.lenovo.com`.
There are some semi-legitimate uses, like Discord using it to check if the app is installed by scanning some high-number ports (6463-6472), but mainly it's used for fingerprinting by malicious actors like shown in the article.
Ebay for example uses port-scanning via a LexisNexis script for fingerprinting (they did in 2020 at least, unsure if they still do), allegedly for fraud prevention reasons [2].
I've contributed some to a cool Firefox extension called Port Authority [3][4] that's explicitly for blocking LAN intruding web requests that shows the portscan attempts it blocks. You can get practically the same results from just the uBlock Origin filter list, but I find it interesting to see blocked attempts at a more granular level too.
That said, both uBlock and Port Authority use WebExtensions' `webRequest` [5] API for filtering HTTP[S]/WS[S] requests. I'm unsure as to how the arcane webRTC tricks mentioned specifically relate to requests exposed to this API; it's possible they might circumvent the reach of available WebExtensions blocking methods, which wouldn't be good.
Yep! Unfortunately its main method (as far as I remember from when I first read the proposal at least, it may do more) is adding preflight requests and headers to opt-in, which works for most cases yet doesn't block behind-the-lines collaborating apps like mentioned in the main article. If there's a listening app (like Meta was caught doing) that's expecting the requests, this doesn't do much to protect you.
EDIT: Looks like it does mention integrating into the permissions system [0], I guess I missed that. Glad they covered that consideration, then!
0. Define 2 blocklists: one for local domains and one for local IP addresses
1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default.
2. Add 2 checks in networking stack:
2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches.
2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches.
3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for.
This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?!
And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.
I 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).
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.
IMO browsers should not just block the request but block the whole website with one of those scary giant red banners if something like this is attempted. If all websites get for trying to work around privacy protections is that their attempts might not succeed then there is little incentive not to try.
A comment I wrote in another HN thread [0] (though this one was the original):
Web apps talking to LAN resources is an attack vector which is surprisingly still left wide open by browsers these days. uBlock Origin has a filter list that prevents this called "Block Outsider Intrusion into LAN" under the "Privacy" filters [1], but it isn't enabled on a fresh install, it has to be opted into explicitly. It also has some built-in exemptions (visible in [1]) for domains like `figma.com` or `pcsupport.lenovo.com`.
There are some semi-legitimate uses, like Discord using it to check if the app is installed by scanning some high-number ports (6463-6472), but mainly it's used for fingerprinting by malicious actors like shown in the article.
Ebay for example uses port-scanning via a LexisNexis script for fingerprinting (they did in 2020 at least, unsure if they still do), allegedly for fraud prevention reasons [2].
I've contributed some to a cool Firefox extension called Port Authority [3][4] that's explicitly for blocking LAN intruding web requests that shows the portscan attempts it blocks. You can get practically the same results from just the uBlock Origin filter list, but I find it interesting to see blocked attempts at a more granular level too.
That said, both uBlock and Port Authority use WebExtensions' `webRequest` [5] API for filtering HTTP[S]/WS[S] requests. I'm unsure as to how the arcane webRTC tricks mentioned specifically relate to requests exposed to this API; it's possible they might circumvent the reach of available WebExtensions blocking methods, which wouldn't be good.
0: https://protomaps.com/
reply