Oh, and a "train" is a bit like 100 cars back to back.

Using a proper password hashing algorithm mostly addresses this concern... and standard cryptographic hashes like MD-5, SHA-1, SHA-256, etc. are not appropriate. They're designed to be as time and space-efficient as possible while still achieving their security goals. Password hashing functions (more precisely, password-based key derivation functions) are designed specifically to be time and space-hungry, efficient enough that you can execute them in half-second or so for user authentication, but slow enough that brute forcing even moderately-good passwords is intractible.

The best widely-available algorithm is Argon2id. The modern algorithms don't focus so much on requiring lots of CPU cycles because GPUs. Instead, they focus on requiring significant amounts of RAM, in ways that provably cannot be reduced. The most-recommended Argon2id configuration requires 2GB RAM. This makes it feasible for most servers to handle fairly easily, as long as they don't have to verify too many passwords in parallel, but it means that GPUs don't help the attacker, and it's also slow enough that while you can get some traction by using a large botnet, it's really not very much. If a PC requires 500ms per attempt, and you have a million-machine botnet, you can still only try 2M passwords per second. If user passwords have, say, 30 bits of entropy, your massive botnet can find one every five minutes on average. If they have 40 bits, your botnet can find a password every ~3 days, on average. That's not nothing, but if you have control of a million machines, you can definitely find better uses for them.

Of course, even better is to use passkeys or similar, but as a practical matter you probably have to have a password to fall back on.

"this belief is utterly false. To quote the U.S. Supreme Court opinion in the recent Hobby Lobby case: 'Modern corporate law does not require for-profit corporations to pursue profit at the expense of everything else, and many do not.'"

https://www.nytimes.com/roomfo...

"We ... show that [the Shareholder Primacy Norm] is not a legal requirement, at least under the guise of shareholder value maximization. This is in contrast to the common assertion that managers are legally constrained from addressing corporate social responsibility issues if doing so would be inconsistent with the economic interests of shareholders."

https://papers.ssrn.com/sol3/p...

So glad I switched from Fitbit to Garmin. Google has done everything possible to lose me as a customer.

Cite? I'm not a CPA but AFAIK, being a PDT has no direct tax implications, it just invokes brokerage/margin rules.

As I understand it (and I skimmed the law), 475(f) elections are entirely optional. The tricky thing is that you have to make the decision of whether you're going to elect to mark to market by April 15 (e.g. you have to decide by April 15, 2026 if you'll mark to market on December 31, 2026), and you generally cannot change that decision. So if you think it's going to be a bad year, it's a good idea to elect, because it removes the cap on loss deductions. If you expect to make a lot of wash sales and don't want to bother tracking them, that's another reason to elect.

But as far as I can tell, it's purely voluntary. Can you point to evidence to the contrary? Ideally in the law, but a reputable investor information site would be fine. I checked several (e.g. https://www.optionstaxguy.com/...) and they all describe it as a choice. One that is binding once made, but still a choice.

It's also possible to pair it with a large residential roof solar installation. I installed solar recently (just in time to grab the 30% credit) and my system routinely generates 3X what my home uses in the course of a day (I typically use about 40 kWh per day, and often generate 130+kWh per day). I've been thinking I'd really like to find something to suck up that extra power, because the monthly net billing plan I have means that once I've zeroed out my bill for the month, I get no benefit from additional production.

As deployment of renewables continue, this "problem" of what do do with excess capacity will increase and spread.

However, if power for the mini-datacenter is only intermittently available, the cost of the hardware effectively increases on a per-token (or per FLOP or however you want to measure the system's work) basis... and hardware cost is already going to be a tough problem for this kind of deployment. Even if it could count on 100% utilization, it will struggle to compete with large datacenters for exactly the reason we build large datacenters: Economies of scale. Enclosures (buildings), cooling, maintenance... all of the overheads fall with scale.

Intermittent utilization just makes that problem worse.

On balance, I'm skeptical that this makes sense, unless the cost of the hardware falls significantly. It seems like that's a baseline requirement for a lot of the alternative datacenter ideas, though: orbital datacenters, floating datacenters, etc.

Bartz v Anthropic is not a binding precedent. It could have been binding in the 9th circuit, but they settled before the appellate court could consider it. And, of course, it's always possible that the appellate could have reversed Alsup.

I think this question is still very much in undecided. It's trending against Meta's interests, but AFAIK isn't there yet.

Put the tinfoil hat down and step away...

There's really no irony here. TPMs serve a different purpose, that of ensuring that the software you're running isn't maliciously modified.

It's really no different from keeping the password database encryption key in RAM, or the capability which grants access to the database encryption key (however many layers of that you want to go down) which is what you have to do if you want to be able to use the passwords on-demand without an authentication step.

If Chrome has access to them without user authentication, then so does any attacker who can dump Chrome's RAM.

If you have a process that provides a service that hands out passwords, it's irrelevant whether the passwords are plaintext or ciphertext. An attacker who compromises a rendering process can only query -- but can probably query a lot. An attacker to breaches the process separation, well...

Note that this is separate from whether the on-disk database needs to be encrypted. There are additional threat vectors there.

Nah. You just try all the bytes. It's not that many.

If the browser can decrypt it without you entering a password or doing a biometric authentication to a secure enclave, then so can an attacker who controls the browser. Encrypting the database achieves something useful against an attacker who can read the browser's files, but not against an attacker who can dump the browser's RAM.