This isn't unusual for a cloud environment where services are distributed across multiple servers for performance and resilience. For read/write data the propagation window necessarily has to be short, but for read-only or read-mostly data like authentication tokens the architecture usually favors speed of authentication and resistance to infrastructure failures over fast propagation of changes. Eg., using a pull-based "changes since the last time I checked" process instead of setting up everything for a real-time event-driven process.

The main thing everyone needs to remember about cloud systems is that they are operating in a distributed environment and changes do not propagate instantly to the entire system. The question is whether the propagation delay is acceptably small or not.

Also, do not depend on "we can revoke the credentials" as your primary defense against compromise. That won't help you against use of the credentials in the span between when they're compromised and when you revoke them, if that's acceptable for you then extending that span by a bit isn't an existential crisis. Design your authentication so credentials can't be compromised in the first place, and are as difficult as possible to use from any system other than the one they were issued to if they are compromised. Hardware tokens (Yubikey etc.) have been a thing for a decade now, it boggles me that they aren't the minimum standard yet.

The smart homeowners will add solar/battery to their properties. I'd bet, though, that we'll see a sudden surge of voters pressuring their legislatures to force power companies to give residential service priority over data centers.

The most concerning part should be that the utility isn't auditing it's service. The most basic check is to compare water pumped or otherwise brought into the system against water usage billed to customers. Those two numbers should be equal, any discrepancy indicates leaks or other unaccounted-for draws. Any discrepancy should also be relatively stable, with any large variations correlated to known main breaks. You especially audit things immediately after a major change like bringing smart meters on-line to catch problems like this.

The sticky note under the keyboard or in a desk drawer is actually pretty secure. Most attacks are remote, they've no way to read that note. The social-engineering attacks don't target people who'd go to your desk either, they either target you directly (you already know your password) or support people who don't need to know your password to give them access.

I have to ask, are these platforms even trying to secure their systems anymore? Because I keep seeing of more and more of these breaches, involving more and more platforms, and the attacks are less and less sophisticated. I hear companies talk and talk about security, yet their day-to-day practices require their employees and contractors to violate practically every good security practice and treat the red flags of an attack as normal company practice instead.

Occam's Razor no longer applies, because at this level malice and incompetence are indistinguishable.

This isn't really a new result, nor tied to genAI. Machine-learning models have a long track record of being able to identify medical problems better than humans based on records. Not really a surprise, the problem is essentially one of pattern matching and machine learning is _really_ good at extracting patterns from large volumes of data and then matching new data against those patterns. I wouldn't apply genAI to the problem, though, the established ML systems do a better job using fewer resources.

Not really. All the examples you give are cases where, if everyone follows the rules, you know what you're going to get before you pay for it. In gambling, if everyone follows the rules you do not know what the outcome will be. Which is the case with futures trading, you don't know what the price/value of the commodity will be when the contract comes due.

Probably. But then slot machines and roulette don't look like gambling from the casino's POV either.

The problem the states are going to have is that futures trading, what the CFTC regulates, is gambling. You're betting on what the price of the commodity will do in the future. The moment the CFTC expanded to allowing intangible commodities, the outcome was a foregone conclusion.

Thinking further, it seems like it'd be impossible to separate things because commodities future trading is in fact a kind of gambling. When you buy a futures contract, you're betting that the price of the commodity will go above the contract price. The seller is betting it won't. The only difference is what you get if you win the bet. dollars or eg. corn. Once you allow intangibles in, even that distinction disappears. The dissent has a point, but I think the majority is correct as to the law and if people don't like it then the law needs to be changed to restrict what can be traded on a commodities market.

You know, looking at the definition, I could probably make the argument that a pull on a slot machine is a "swap" per the definitions as long as the casino operator jumped through the hoops to get declared a DCM.

Maybe the legal experts could sit down and work out how to modify licenses (including the GPL/LGPL) to be for non-commercial use only? As long as an entity wasn't making money using FOSS, it could use it just like now. Individuals and non-commercial projects wouldn't be affected. But if you're a business making money using FOSS? Not without paying for it you're not. Yes, this would go against the free-software principles. But principles don't pay the bills every month, and none of these changes would prevent anyone from staying with the existing licenses if they wanted to.

The first thing I think of as a problem would be a company setting up a separate entity that wouldn't make money, just make services available to the company using FOSS to get around the fees. The trick to preventing this would be to phrase the terms so that that entity truly had to pay it's own bills without having the company using it's services pay anything either directly or indirectly. Not even by doing things like providing hosting "free". I'd have to sit down with a bunch of rules lawyers and game out all the ways to funnel money into that entity and how to block them, but what's life without a little challenge?

This is uselessly metaphysical.

That's something I've said for a long time. And unlike permanent DST, going to permanent standard time doesn't require Congressional approval. Any state can do it any time by just passing a law.

Is MS doing the blocking themselves, or is it an RBL that's doing it? And if an RBL, which one? The MS mail admins can answer those questions easily, and then affected senders can direct their attention to the appropriate target.