Please, no. Often when writing code I need the API reference and only the API reference. I know what I want to do and how to do it, I just need a quick check of the exact order of arguments or exact symbol names. I don't need to try to sift that out of commentary. Likewise when I'm learning how to use the library I'm more interested in the overall view. I don't need to know the exact names of the options for a call, only what the options are for. I expect the code in the user's guide to be accurate, but I don't want the same things out of it that I want out of the API reference.

Except for the bit where it does that caching for a loop where each lookup only occurs once. Because everybody caches lookups, so that must be the right thing to do (it's the most likely thing to happen) in a case where the cache is never used. Riiiiight...

Something critical to note: intent is the most important thing to document when it comes to software. You can see what it does by reading the code, that's straightforward. What I need to know most, both when writing software and maintaining it later, is why it's doing that. What's it supposed to be doing? Why is it doing it in that way? What were the alternatives and why weren't they chosen? How is it supposed to be used by code that calls it? An LLM can't generate any of that just from the code.

This is why traditionally software libraries have had two separate pieces of documentation: an API reference that details every call and it's arguments and results, and a user's guide that lays out how and why to use the library.

This has been typical behavior for large companies when dealing with vulnerability reports for decades. Report one, they treat you as the problem. They'll try to ignore it, consider it "not exploitable", delay and deflect as long as they can get away with it, anything but address the vulnerability. And they'll never tell anyone the vulnerability exists. This only changes when they have no choice but to admit to the problem and fix it, usually when the vulnerability is being publicly exploited. They push "responsible disclosure" because it includes the reporter not making the vulnerability public until the company has a fix, which allows them to stall disclosure as long as they want.

It used to be enough to just include a reasonable deadline when reporting it, after which the reporter would make it public if the company hadn't taken some action on it. Then companies started threatening and then taking legal action against the reporter as soon as they reported the problem, playing the deadline up as "blackmail".

So, what do you do when faced with this? The only reasonable response is to skip the company entirely and make the details public immediately. You're going to be facing retaliation from the company either way, this way the public isn't vulnerable for an extended time. And yes you include details on how to exploit the vulnerability, ideally via working code, so researchers other than the company can confirm it's a real vulnerability that's actually exploitable without having to take your word for it. No, that doesn't give the bad guys anything because remember the working assumption for vulnerabilities: if a good guy has found it, the bad guys already know about it and are using it. Remember that when the company whines.

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.