HN user
As far as I'm aware, the monitor does not transmit a URL. Windows is looking at the hardware's vendor and device IDs and using those to look up and download the "drivers" that LG has stated are for that device.
Can you please share the chat log for this? I would absolutely love to see this.
DiscMaster[0] is useful for this!
It seems to agree with you. There's nothing I could find named imposta.exe or aryala.exe, but I did find installa.exe.
This is a dang shame, honestly. The Google Earth Pro desktop app is a good one and I still use it all the time.
Of note: Google Earth on web[0] and mobile are unaffected. According to the announcement, the Google Earth Pro desktop app will continue working after the June 25, 2027 cutoff date, but new downloads will not be offered.
Can you link the specific post you're referring to? It's not "above" at this point in time.
How does this compare with the F-Droid version of OsmAnd?
[Edit: To answer my own question a little bit, I found a post from September 2025 that compares OsmAnd and Organic Maps (which this project forked from): https://blog.firedrake.org/archive/2025/09/OSMAnd_vs_Organic... .
I can't find anything more recent or for CoMaps specifically, other than auto-created "alternatives" pages. I would absolutely love to hear from anybody who has tried both!]
I don't have any specifics, but based on experience, it feels like software giants like to patent what a lot of people would consider obvious wins (such as interruptible animations) if no other company happens to be doing it, and it felt like this would be something where that could be the case.
That said, I can't seem to find any evidence of this particular thing being patented to support my case, so it's probable that I'm wrong.
I assumed that issues like "tap eight times for a no-op" not working was because of software patents not allowing the developer to do the obvious thing. Is that not the case?
I get around this by pairing JavaScript allowlisting with custom CSS and userscripts. I shouldn't have to, though.
This would result in an airplane level of whirring while it used maybe a few GB of memory and hard drive storage to boot up Windows 95.
In those days, RAM was measured in megabytes, not gigabytes. My first Windows 95 PC had a grand total of 16 MB of RAM and a 1.6 GB hard drive.
It ran pretty well from what I recall.
To be fair, .md is the ccTLD for Moldova, first set up in 1994[0], ten years before Markdown was even a thing. The ccTLDs use the ISO 3166-1 alpha-2 country codes, defined in 1974 (according to Wikipedia)[1].
Moldova has every right to the ccTLD. It's just that I find that Markdown files can sometimes get auto-linked to the corresponding (and frequently non-existent) domain, which could catch me out if I'm unaware... and I don't even know of any sites using that ccTLD, hence why I block it.
Nothing personal, Moldova.
(.zip and .mov were terrible ideas, though.)
Obligatory reminder that what the US government considers to be extremist activities includes the obvious crime of being interested in privacy and anonymity[0].
(Hence all the age verification laws cropping up everywhere, most likely. Their primary goal isn't actually about protecting children.)
[0] https://www.linuxjournal.com/content/nsa-linux-journal-extre...
There are three TLDs I block on my computer completely, and all of them are file extensions - .zip, .md, and .mov.
(Yes, the domain "readme.md" exists. Fortunately, whoever owns it is not using their power for evil and does not have any webserver there... but I'm not risking it.)
Similarly, Windows XP's release is closer to the release of the IBM 5150 (the first-ever IBM PC) than it is to today.
I haven't actually investigated that (and I'm not able to do so right now), so I couldn't tell you for sure.
If that's the case, then yes, the forms method would be 'better'.
If it was one of the requests that would trigger a preflight normally, then yes, it would trigger a preflight. But the code as shown doesn't do that because "multipart/form-data" is one of the allowed MIME types that can bypass these preflights.
I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data
It does, though. See my reply at https://news.ycombinator.com/item?id=48618539 .
...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format...
The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript:
var xhr = new XMLHttpRequest();
var url = "http://localhost:12345/endpoint";
xhr.open("POST", url, true);
xhr.setRequestHeader('Content-Type', 'multipart/form-data');
xhr.send('{"hello":"world"}');
[Edited to illustrate my point better.]
Regarding the first part, it's easier than you might think to have a false sense of security.
I've seen a web application that did, in fact, check the Content-Type header to make sure that "application/json" was there - but it didn't check that the header value started with that. That meant that setting the header to "multipart/form-data; boundary=application/json" was enough to bypass a CORS preflight!
That's not quite correct. POST requests with certain Content-Type headers, such as text/plain or multipart/form-data, will still be allowed without any kind of preflight. If the web application doesn't check the Content-Type header strictly, then you've got a problem.
If your web application specifically parses data based on the Content-Type that it advertises itself to be, then yes, the webapp would hit a parse error. But there are many applications that don't do that.
An attacker might use JavaScript to set a "multipart/form-data" Content-Type (thereby bypassing the otherwise required OPTIONS preflight), but send JSON in the request body. Unless your web application specifically parses the body based on the Content-Type (web servers don't do this for you), then you wouldn't detect that.
My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed.
For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed and wouldn't be stopped by CORS at all, even to third-party hosts.
(And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.)
That video was super interesting, thank you!
That makes sense. I feel a little silly that that's not something I considered despite the article saying exactly that. I think I got caught up in the details.
Oh right. I feel silly for forgetting about that even though it's mentioned in the article. Thank you!
That was incredibly well-explained. Kudos.
I do have a question that the article doesn't seem to attempt to answer, though. The article says (paraphrased in my new understanding) that any spectra which makes the cones in your eyes react the same way will result in seeing the same colour. Do we know of any examples of this?
(Colour-blindness seems like an obvious example; I'm curious though if there are any examples of two common scenarios where it can be demonstrated that there are different spectra in each, and yet most people will see them as the same colour.)
I misspoke when I said Android 7+, my apologies; I was thinking of my Pixel 7, which runs Android 13.
...I feel a bit silly. When I said "Android 7+", I was thinking of my Pixel 7, which runs Android 13, so "Android 13+" is what I actually meant to say. Oops.
While the OOBE of the stock image doesn't force an Internet connection, the ability to unlock the bootloader does - whether you can do it or not depends on the phone manufacturer's desire, and Android for some reason uses an Internet connection to check that.
My understanding is that it is impossible to unlock the bootloader on a new recent (Android 7+ at least; possiblt earlier) Android phone until it has connected to the Internet. After that, the ability to unlock the bootloader is permanent.
The occassional "Drive has not been checked in <n> days, forcing check" message on bootup got annoying sometimes, yeah. It could easily take tens of minutes to finish, exactly when I wanted to use the computer!
(At least this is what my memory is telling me. I could be mistaken, but that's what I remember.)