There is an even stronger version of your argument, one that works without shifting to the same old "you don't need the expensive stuff, just get your life together" advice that already has kind of a bad rep for not fixing depression. You can accept that you cannot inject much more of necessary discipline and motivation into people after they leave school.. and still argue against many types of surgery in mostly the same way: by strictly comparing them to other costly endeavors that could bring about those probably-helpful life changes. Many more people could work towards that "real solution" by benefiting from some other spending.. which merely happens to be cheaper than surgery, while still not being entirely up to them.

Example: My town installed an outdoor "grown-up playground" in the nearby park. Probably cost a little over two complicated surgeries. Already saved 10 people from neglecting upper body workout. Just 10 people having a really low-barrier-of-entry gym available to them whenever walking their dog. I suspect its already been cost-effective. Plus, it is reusable and low-maintenance. Try to beat that in the operating room!

The thing is, the fitness level OP is talkign about is not going to be compatible with the grown up playground sort of activities. You need to get jacked basically. You need to be lifting to failure 3x5ish hitting all muscle groups 2x a week with compound lifts. You should be struggling to go up stairs after working legs.

Working out is good, yes, but you need to actually work the body and make it suffer so that it may actually be damaged enough for high rates of muscle growth. So many people do not do enough because they don't like to push themselves, they take it easy and they end up wasting their time in the gym. Even more true as you get older and natural testosterone levels start declining and limiting your muscle growth.

This is why people end up taking spin classes when they can just do it at home on their own stationary bike. For some people, they need a jockey who will kick their ass along with the peer pressure of a room full of people dumping out sweat.

Huh? Knowing that the ceiling of diminishing returns is that high should make us even more optimistic about low-effort progress in the right direction. The 80/20 of weightlifting starts with no longer shifting your spine in a funny way for every slight inconvenience. That is a small distance from the feeble median status quo, and still very far away from jacked. To achieve meaningful reduction in injury risk and some forms of chronic pain, we do not need to focus as much on people going from already generally fit towards trying things that are naturally extremely difficult for them (or for their postmenopausal hormonal state). There is more net benefit per exertion at the very beginning of a resistance training voyage. Which could very well never reach the intensity of enjoying a proper "no please, no stairs!" moment that indicates maximum strength improvement per unit of time, and still have been best-in-class per unit of currency spent on nudging people into it.

Careful, there is two different things going on here:

a) whether you use the maybe-entropy provided by the CPU (and/or the bootloader)

b) whether you credit that maybe-entropy towards your tracking of whether the pool should be considered sufficiently seeded

random.trust_cpu/random.trust_bootloader configures b).

nordrand has been removed from the kernel as it had become overloaded by meaning both a) and b)

Under most circumstances, a) is harmless. You mostly want that off when the CPU exhibits some performance hiccups when asked.

Under some circumstances, b) is outright dangerous. Some applications can work without seeded pool at some slightly reduced performance, but could be made to fail miserably if they had been made to believe that the pool was seeded yet it was not. This happens with hash tables when you skip some of the accounting because it seems no longer relevant. It really would not be relevant, once even a determined attacker should be unable to reliably trigger the worst-case-performance.

Note that this issue doesn't make rdrand useless for entropy. It's still as useful as always if passing through any whitening or mixing algorithm.

- Find some new way for Cloudflare to acquire paying customers. If their business did not depend on the status quo, they would be exceptionally well positioned to roll out the technical & organizational frameworks that that make massive botnets a thing of the past.

Not while the new dukes of the internet wielding massive armies of hijacked smart TVs have a better time browsing the web than I have; as a mere peasant with just a few IP addresses. There would be no reason to sign up and pay up for bulk access, unless open access is shut down.

Speculation, no insider info: Its one more thing that needs to be sent out to all their proxies, and could be a reason for meaningfully different metrics whenever the (non-time-critical) regular updates fail. The more configuration/state each proxy receives and processes, the more difficult it will be to determine what is wrong when one exhibits abnormal behavior. At least one of the serious outages was even directly attributed to having accidentally exceeded some hard limit (very hard actually, a rust panic) in how much data could be distributed through one particular such channel, see https://blog.cloudflare.com/18-november-2025-outage/

That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitimate.example" mailbox. The sender would not be able to prevent this.. unless its regulatory oversight body is very patient about repeatedly delaying legitimate requests for seemingly-minuscule formal defects. (Mentioning just for context. Probably not the mechanism at play here, Revolut would have tried to shift blame in the press release if it was.)

I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this.

It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.

Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).

Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust.

You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website.

In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking.

There is no excuse to be using non-e2ee email for this in 2026. None.

What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference.

Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no?

I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.

The document exchange site isn't hosted by each individual company, that would obviously be ridiculous. There's only one and it's hosted by the government. I already said that in my previous comment but you chose to attack a straw man instead.

Is it uncommon/impossible to ask for the federally-brokered in-person procedure in the US?

(The way I know it: Local court or police officer shows up at our office later that day and hands over a printout matching the request that we had been unable to confirm, on request of federal authority, in turn on request of the authority demanding we hand over some customers data. Those two requests utilizing government agency-internal auth mechanisms we do not need to know or care about.)

You'd still want to verify that with the court or authority? I've been served before and sometimes it's just a person in street clothes who hands you an envelope. And even if it's a court bailiff or officer or something like that, would you be able to distinguish a real uniform, ID and badge from a fake one?

The uniformed woman with the pistol is whatever the stitching on the chest pocket say she is. Is that not true just the same even in places where other people may routinely open-carry?

> Those two requests utilizing government agency-internal auth mechanisms we do not need to know or care about.

Most likely:

> and the whole thing was PDFs from .gov-ish email addresses

But I guess this moves the liability for answering fake requests to the local branch.

If it does not happen quickly, then the result might end up similar to data privacy topics.

If you can afford to keep fines in litigation/appeals/formal-defect limbo for a sufficient number of years, you can grow out of even once-threatening fines and delay compliance until the law that you finally bow down to is so old that its signs of old age will in the meantime become popular arguments for undermining or retracting it.

I guess when discussing the reasons for the law failing to bring about the intended changes, we only need to agree on that the law did not intend to make this distinction (though it definitely could have made them, even before LLM this was a deliberate choice) - not whether doing so would have been advisable.