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.

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.

Er, I meant if they have enough control to dump RAM. Thinko because what I was thinking is that if they can dump RAM they can dump your password database, too (unless user authentication is in the loop and that authentication relies on secrets not in the device).

I'd love to trash Edge, but it's hard to argue against Microsoft's analysis here. It's hard to come up with a practical threat model which Edge would fail but Chrome or Firefox or any other browser with a built-in password manager would meet, unless the browser required authentication for every password retrieval.

If an attacker has enough control of your machine to dump the password database, they have enough control to get it to retrieve the plaintext passwords unless every retrieval requires user authentication in the loop -- which would be pretty annoying, which is why they don't do that.

For that matter, an attacker with that much control over your system can even get your passkeys, unless those are stored in some OS-managed secure enclave and they require user authentication in the loop (e.g. a biometric which is matched in the secure enclave, and ideally with a secure path from scanner to enclave).

Still, if it were me writing the code, I'd do it Chrome's way, just because leaving secrets sitting around in plaintext in RAM makes me uncomfortable.

Property taxes are not levied by the federal government for reasons that are partly constitutional and partly practical.

In order to levy a property tax without a constitutional amendment, the federal government would have to apportion the taxes to the states. In fact, Congress did this several times in the 18th and 19th centuries. The way it worked is that Congress determined a revenue target, apportioned that target among the states proportional to population, then required the states to collect money and hand it over.

Congress could do that again, and could subject different kinds of property to the tax... but it would get very ugly, because the tax would have to be apportioned among the states purely on a population basis. A 2021 analysis of Warren's 2% proposal found that different states would have to apply wildly disparate state wealth taxes to pay their apportioned amount. West Virginia would have to institute a wealth tax 20X higher than DC.

This is why Congress has not instituted apportioned property taxes since the Civil War, because they were pretty unfair. The 16th amendment provided a much cleaner, fairer way to directly tax the population... but only on income.

And as for the Article III point... Moore v United States (2024) pretty strongly indicates that at least the current SCOTUS is very hostile to wealth taxes, and not just the conservatives.