It is the same draft. Revision 25. Encrypted Client Hello and Encrypted SNI is one and the same and this is and was always deployable by everyone; this is not "for large providers" - it is for All providers. They simply had to revise the spec to protect more than the SNI.

See https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fdatatracker.ietf.org%2Fd...

nobody has bothered to so much as renew for 6 years.

Apparently you are a bit clueless. Because you see there is an IESG action already on draft-ietf-tls-esni which approves it to proposed standard, effective July 9, 2025. In other words the standards process has already finalized on the TLS-ESNI draft (TLS1.3 Encrypted Helo) and it is simply waiting in the RFC editor's queue for final publication.

Not that it has to have the status before the feature is available.

it also ensures black-box IoT devices can't have their ad-queries blocked by pesky customer's pi-hole DNS devices.

You can always serve DNS server IP addresses to your LAN for DNS servers that support only legacy Port 53 DNS over TCP/UDP. Then firewall off "public DNS server IP addresses" as an extra precaution.

In short the only way your Pi-Hole can't be made to block the DNS queries is the case where a blackbox overrides your network configurations and tunnels its DNS traffic through the vendor's server, Proxy, or VPN, etc, instead of sending it over TCP/IP, and that's something they always could have done.

There is no such thing as encrypted SNI.

Sure there absolutely is such a thing as SNI encryption

October 22, 2018
Encrypted Server Name Indication for TLS 1.3
draft-ietf-tls-esni-02
Abstract
      This document defines a simple mechanism for encrypting the Server
      Name Indication for TLS 1.3.

The end-to-end integrity of the DNS query is still not guaranteed unless DNSSEC is used

The number of parties who could tamper with the response is reduced from potentially any passive observer who happens to be able to tap into the link anywhere along the whole path - reduced to that one server operator.

the Host header for SNI is still plaintext.

With HTTP/3 and TLS 1.3 with the ESNI option this is no longer the case.
And roughly 50% of HTTP traffic on the internet is HTTP/3 now which uses QUIC over UDP, and the QUIC transport encrypts essentially all the metadata for the specific purpose of preventing such privacy leakages.

In short: That particular issue will become less and less over time. Especially once websites and web browsers start turning off support for HTTP/1.1 and older TLS versions without the encrypted SNI.

I almost always enable DNSSEC on my DCs

Windows' DNS server program supports DNSSEC.

The problem is the Windows OS such as Windows 10 or Windows 11 itself does not come with a full DNSSEC-validating recursive resolver. It only comes with a dumb stub resolver which requires other DNS servers to function.

If Windows 11 came with a built-in recursive resolver It would implement DNSSEC AND it would be able to resolve domain names with no need to configure any kind of DNS server -- In fact, no local DNS server would be used at all.

Presumably the only reason it has not happened yet is It's deemed more important to have the possibility of Administrator controls from the local network rather than to provide a secure resolver system.

Most people are not worried about their DNS traffic being examined.

DNSSEC does not protect against your traffic being examined in any way wahtsoever.

DNSSEC provides digitally signing of DNS zone data so that the DNS resolver can verify the record in the response has not been altered.

the problems with DNS traffic being altered or redirected has yet to be a widespread

In fact it is a widespread problem. One of the major ways malware would be spread was by malicious actors pointing users' routers at malicious DNS servers.

Unfortunately DNSSEC would not help with this issue either; because Microsoft does not ship Windows with a built-in DNSSEC-validating recursive DNS resolver. Probably because it would conflict with the idea of having "fake" internal domain names which Active Directory is dependent on, since a recursive DNS resolver component has to start straight at the official source of truth (The internet's root nameservers).

The problem is that this was likely due to one person being an idiot.

Then you have to ask.. Why does Chlorox have a system in place that allows a single Tier-1 helpdesk monkey being a dipshit?

A proper Helpdesk IT system requires the caller to answer security prompts to prove themself and does not give even a malicious Operator the power to reset a credential before the Helpdesk management system is satisfied correct data has been typed into Authentication prompts displayed on the console. For example, the caller would be required to answer some security questions before reset can proceed. Even if the Helpdesk operator is an Idiot: they are still required to input the user's answers with no access to see any sensitive User account information about the employee, until that caller has fully authenticated, and a SMS Text message is immediately sent to the actual Employee's phone as soon as any helpdesk operator authenticates to view their account or tries initiating the Password reset applet.

Companies don't want any costs in their profits. They can't do it straight away so they "put up" with some costs until they have a replacement.

AI Inference is not free definitely has a cost, and the AI services companies are not selling their product for free. In fact the price of these AI services come out as astronomical ever-increasing subscription fees.

No matter how much you train the AIs they do not think like humans do, and will be extremely error prone constantly coming up with delusions; at best you end up with a tool that may be useful for helping to inform humans.

What if you train your replacement on a lot of incorrect info? Perhaps deliberately in order to make the replacement weak?

For some reason I think the graduates interested in going into "teaching AIs" might not be most experienced brightest individuals in their field.

Generally new graduates are not your "experts" or seniors in a field, but the lowest of the low in knowledge and experience. Perhaps the reason they would be willing to take an hourly rate in the first place. And $160/hour with no guarantee on the number of hours before they are done with you is potentially a very low rate to directly create a knowledge product with all your knowledge and no further share in its profits.

The breach is Clorox's fault.

A company's service desk IS an internal IT/Security function. Just because you found a contractor to fill in for the work does not mean your company is no longer responsible for determining what your procedures are and making sure your contractors abide by them and enforce them.

There are also ways of conducting drills and verifying that your contractors' agents follow the rules and don't do dumb shit. If security rules are not in place for how to verify personnel for password resets, and under what conditions resets can be completed, then Clorox would be responsible for not making certain that they are in place.

Definitely not communism. The correct term is "corruption". And it is much, much worse.
I think bailing out the big banks may count as anti-communism. A communist could say these big banks are a part of the means of production. They can be bailed out, but kick out private investors who "own" them, and re-assign control of the banks as for the benefit of the people. Private individuals are not able to own the banks and all the profits derived from them.

It's the PIN that puts you on the hook since a thief would not know that.

Unless the thief used a skimmer when they copied your card. Or compromised a banking system and stole the card and PIN. Or stole the card and the piece of paper from the bank providing your PIN. Or the thief stole the card and drugged the customer in order to get the PIN and make them lose their short term memory of events.

It also mentions rolling over BNPL debt into credit card debt

This is like using one credit card to pay the bill from another.

Imagine for a second that was unrestricted. You could delay Credit card A's payment due this month indefinitely by paying it down to zero using Credit card B. Then, the following month after Credit card B's statement closes pay it down to zero using credit card A before card B's deadline.

You have in this case: 1. Not paid any interest, since you paid both balances down to zero within the grace period. And 2. Extended your deadline out 60 days by just one cycle. 3. Magnified the amount of debt you own.

Eventually you are going to find the money and pay it down, but most likely people who would do this would keep the game going as long as possible until they blow up. Card company A and B have no incentive to allow this, because you'll largely avoid interest payments at all, AND for all they know the final debt will be with card companies H, I, and J. There's a high chance debt will be defaulted, or at the very least they won't get interest or enough interest to offset their risk.

Or more likely, trying to source smaller memory chips would cost more

I'm rather thinking they would have more then C64 functionality in mind for the board, otherwise they could have just implemented an ASIC. Also; the original Commodore 64 did not have WiFi, or a LAN port, or USB ports, but this board has all those things.

The whole point of a FPGA chip is that it is programmable. And presumably hackers will want to do cool things with it if possible. Also there should be some memory overhead for loading a Commodore 64 core onto the FPGA at power on, and executing whatever other software and firmware they had in mind to help manage the C64. I imagine at power on the firmware chips, or whatever they actually have will need to read the core they have programmed for the FPGA from some location such as the flash chips or external storage and place the whole implementation of the Commodore 64 into some RAM area first If they want to provide the ability to load different programs supplied by the user onto the FPGA to open the possibility to recreate other kinds of hardware.