eqvinox

The end result of this will be ISPs dropping all traffic to port 853.

Here's how to explain it in order to blame openssh:

openssh processes passwords and doesn't want to reveal through timing whether a user has a valid password (or exists at all). So far so good.

What they do if they hit a user with no valid password (i.e. "*") is that they look for another user with a valid password, to use the seed from. A bit weird already, but OK from a perspective of avoiding implementation specifics on seeds and hash algorithms. They know at this point that the result must be to deny access even if the hashed value matches, because that hash is for another user.

So they put the password received over ssh into crypt() with this other user's hashed value to get a seed. And then accept it if it matches, apparently?

Homework: what happens if the password actually matches another user? Can I log in as root if openssh randomly picks my user for the fake salt, and I type my own password correctly?

It's very much part of the design that roots and caches are separated. The security properties necessary between root and cache (authenticity) are fulfilled by DNSsec, not DoT/DoH (primarily privacy). And most TLDs are DNSsec signed, so this part is in fact OK. (Both give some level of tamper protection, in a different manner though.)

You're probably saying this because you run a local cache directly against the roots. If you need DoT/DoH, you shouldn't be doing that and rather forward your queries to a cache somewhere else.

(To make sure there's no misunderstanding here: DoT and DoH do absolutely nothing to guarantee the data you're getting is what the roots/TLD/owner published. It only ensures you're talking to the cache you think you're talking to. The cache can serve to you whatever it wants.)

There are of course outliers but most people I know in the field care as much about personal rights & freedom as anyone else. Maybe even a small bit more.

Even outside ideology, plain business sense makes ISPs not want to deal with censorship & co. It's work to do that, hence costs money. But there are also ISPs resisting out of ideology and civic duty.

Full ACK. As a part of this, DNSsec validation needs to be as close to the client app as possible and reasonable; definitely never off-host. (Caches can do additional validation, but that makes the error reporting complicated.)

corollary: the AD bit should never be relied on on anything actually on the network. Maybe on localhost, but even there it's questionable in UX results.

> domain-validated certificates remain insecure

...99% of the internet runs on DV certificates; that's what ACME & Let's Encrypt are at the end of the day.

(You might also note I didn't actually speak in favor of DNSsec, I'm just arguing that running unbound locally without having DNSsec validation enabled isn't particularly useful. I am, generally, in favor of rolling out DNSsec, but it certainly has its problems. It doesn't help against ISP tampering on unsecured domains, for example. DoT and DoH are better against that, if [and only if] you have a trustworthy cache to point them at.)

:-(

Coincidentally, a bunch of free wifi stuff blocks the root key queries unbound does at startup, resulting in nothing working until you get those records in there somehow (e.g. load_cache).

I absolutely agree. But it's entirely irrelevant, because there's no "must be this (hand gesture) sophisticated to buy IPO stock" rule.

It's an IPO, the P is public. The information needs to be consumable by the public. The level of knowledge that can be expected of a random IPO stock buyer isn't the same as that of a VC or private fund.

And that's exactly where the SEC comes in. The 1930s went wrong enough, no point in doing a 2030s repeat.

I guess the interesting thing would be to look at actual company assets/value rather than revenue; revenue already in itself is a derivative. I.e., contrast their revenue against expenses. Last I heard those numbers are deep red, aren't they?

It's actually standards compliant (unless they screwed something up). IEEE 802.3 clause 158: 10GBase-BRx, where x = 20 in this case, at least the ones on the Amazon link say 20km. The 1G/2G support is "bonus" beyond the spec.

You can get them with LC connectors too, which I'd in fact recommend because those are smaller, a bit more precise, and waaaaaay more common these days. https://www.fs.com/eu-en/products/36351.html (note you need a pair of "23" and "32")

FINALLY we know what happened with eMudhra's keys!

(Sorry. Really couldn't resist.)

Honestly? At some point there's a fiduciary-like obligation for it. What ParticleDB delivered is so far past good or bad, it's just straight ugly and then some. It's so poor that, if Jepsen couched it in any way, they'd be implicitly misleading their readers.

What a waste of CO₂.

I'd also add: from paid online news, I also expect a moderated forum/comment section, with a human to escalate to if automatic/AI moderation fails.

I don't think I have ever seen an LLM try to determine what a human's frame of inquiry or related experience / skill level is, though. Might be my new favorite LLM shortcoming.

There's no such thing. How a medical professional interacts with a patient is a major part of the profession. Some people are shy, some anxious, dismissive, neurotic, ashamed, obstinate, miseducated, … etc.

You need a ton of interpersonal skills in this, particularly at diagnosis time. I might even go as far as saying it matters more than medical book knowledge. If the patient is too shy to tell you about, say, black stuff in their stool, you may never get to apply that knowledge about colon cancer.

Coincidentally, a family member of mine died of basically that. When somebody asks, we half-jokingly say he died of stubbornness. It's actually the truth, kinda.

Doctors doing diagnosis are detectives putting together clues. Ideally, they have the patient's full cooperation and zero misunderstandings. Worst case, they're being unintentionally sabotaged, bridging world views, and hampered by their own prejudices.