edelbitter

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.

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!

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.

- 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/

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.

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).

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?

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.)

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.)

.. 9 out of 10 unhappy customers are currently unable to cause any blame, because they cannot even reach customer service because they are getting the "bot" treatment.

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.

Sending money to the intermediary is still essentially free. The likely incorrect assumption here is rather: that it would do any good in this case. Because that only works when the intermediary has agreed to do anything other than facilitate wire transfers (with the beneficiary account number and cost schedule specified!). They would say so in the instructions (e.g. a note on how the SEPA reference field should be filled), if that were the case.

SCT is not contingent on EU or Euro participation - SEPA membership is distinct from those. That is how Iceland, Norway and Switzerland can reap the benefits (the latter not even EEA member, though effective treaties are now somewhat similar). As long as an US bank has a correspondent branch/account/partnership/whatever inside SEPA, they can make it almost free to receive money via SEPA, and then possibly still save on currency conversion and transaction cost as they clear in bulk across the pond.

RBOS is short for Royal Bank of Scotland. When accepting SEPA credit transfer (though they are not legally mandated to offer the instant execution variant), I don't think there is even a mechanism to sneak in extra fees, beyond what the sending institute already billed (typically: 0.00€).

>apples is as they are always in the supermarket

You're missing out! Try a few of the apple varieties that are not available year-rounds, that are not optimized for insecticide compatibility and tons per square kilometer (well, more likely bathtubs per football fields or something). Yes, even and especially the small & ugly ones that never ever have that flawless smooth skin that makes you wonder which ones are plastic props and which ones are fresh fruits. After dumbing down the basic supermarket apples to just a few that look presentable and can be made to work in a wide range of climates, it has lost the refined tastes of most of the other varieties they out-priced.

But.. Internet mail is not a lossy system. Quite the opposite!

Unless providers do insane things (e.g. accept then discard), it is much safer than snail mail, where messages may not arrive and not cause the sender to be notified of non-delivery either. With email, the sender gets explicit per-recipient-and-message feedback on what the recipient provider has accepted responsibility (to not lose them) for.

Even worse with initcpio and linux kernel decompression choices: You can mix them, and it works.. sometimes.

I might have believe this story, if not at the same time Intel had made an expensive bet on producing not-quite-gaming cards, later looked at the same trillion dollar question.. and then almost decided that this did not bring enough luck to keep spending.

That question does not require any greater explanation than "there was little else to be done, besides waiting for the storm to subside".

I was thinking timezone update - because of course an internet-connected freezer needs updated zone info so one can configure defrost schedules without the benefit of UTC.

Then again, many reasonable people would avoid, rather than specifically seek to buy raw honey from India (or the vicinity).

(Obviously a take that does not get very far in lower level programming, but from the comfort of some abstractions away:) I like to think of buffer overruns, command injections and path traversal as all the same category of bug: type confusion. Nothing special. An no excuse to risk any of them, if the logic implementing them is expected to be called just O(1) times anyway.

Not like Berlin could have paid anyway.

https://www.youtube.com/watch?v=fqb6qYBdvX8

This is less of a virt/x86 bug and more of a "don't call system() on arbitrary user input" bug.

.. incidentally, OpenBSD also provides one of the clearest examples of how the excuse "calling system() is fine in my case, its totally not arbitrary user input" is deluded just the same, see CVE-2020-8794.

But what would the equivalent "do the expensive preparation 1 time, then re-use copy-on-write memory N times" pattern look like, after reconsidering my life?

Why US financial sanctions against an EU-based non-profit? Making it harder to accept money from the US does not seem like quite the right tool. Are they known to be primarily sponsored by US individuals, or depending on other service providers with US presence?

You never know in Germany. Jail time might still be looming.. after some 3-5 years of delay because the telefax machine at the public prosecutors office is currently broken (and not even for DNS reasons!)

Going batshit with browser APIs is also a formidable GDPR defense. e.g. try browsing the privacy-related forms for Google (https://myaccount.google.com) on Firefox :D (entire browser freezes up every other second for me, because of some extremely important work Google needs to run on my CPU to let me scroll down on a static site containing roughly 30 words)