There is a lot of boilerplate or I can ask for ideas, but outside of boilerplate the review step make generation seemingly worse.

But pro-AI posts never seem to pin themselves down on whether code checked in will be read and understood by a human. Perhaps a lot of engineers work in “vibe-codeable” domains, but a huge amount of domains deal with money, health, financial reporting, etc. Then there are domains those domains use as infrastructure (OS, cloud, databases, networking, etc.)

Even where it is non-critical, such as a social media site, whether that site runs and serves ads (and bills for them correctly) is critical for that company.

I have had to actually verify my “investment profile” with a major broker in order to unfreeze some trades, in a high friction process. To the extent that a sideloaded app that looks exactly like the bank app has a low friction install, then people can get fooled and irrevocably lose savings.

If the lock-down is opt-in, almost nobody will opt in to it. If the lockdown is opt-out, then whether scams still happen depends on how much friction there is in opting out.

Freedom to install other unsigned sandboxed apps has a solution: Banks could use passkeys and other non-phishable methods. Sideloaded apps in Android can’t get to the bank app’s passkey.

Passkeys or hardware tokens get worries about the enshittification of the theoretical recovery process. Which, if that’s the case, I guess we should hope for/pay a better world, at least with banks and brokers. For them specifically, for account recovery allow either showing up in person or using ID checks.

Both for personal accounts and business accounts (i.e. with Business Email Compromise), I believe the onus should be on the bank to use non-phishable methods to show the human-readable payee from their app for irrevocable transfers.

Monopolies, in these cases natural monopolies, can in fact exist. Look at the Micro supply and demand curves. As a general rule over those 100 years, there has not been rationing of electricity. There are natural blackouts and today an unplanned surge in demand (as happens in every industry such as chips after Covid), but generally the price regulation did not cause some kind of gas lines.

It depends on the level of market failure, but there are not a ton of hospitals to choose from regardless.

For securities, if I own stock outright, the company has to indemnify if they do a transfer for somebody else or if I lack legal capacity. So transfer agents require Medallion Signature Guarantees from a bank or broker. MSGs thereby require a lengthy banking relationship and probably showing up in person.

For broker to broker transfers, there is ACATS. The receiving broker is in fact liable in a strict, no-fault way.

As far as I know, these liabilities are never waived. Basically for the sizable transfers, there is relatively little faith in the user’s computers (including phones). To the extent there is faith, it has total liability on some capitalized party for fraud.

These defaults are probably unknown for most people, even those with large amounts of securities. The system is expected to work since it has been set up this way.

Clearly a large number of programmers have a bent to go the complete opposite direction from MSGs, where everything is private keys or caveat emptor no matter the technical sophistication of the customer. I, well, disagree with that sentiment. The regime where it’s possible for no capitalized entity to be liable for wrongful transfers (defined as when the customer believes they are transferring to a different human-readable payee than actually receiving funds) should not be the default.

The money mule themselves is almost certainly insolvent to pay the damages. Currencies can also change by the money mule (either to a different fiat currency or crypto), putting the ultimate link completely out of reach of the originating country.

If intermediary banks are deputized and become liable in a no-fault sense, then legitimate transfers out become very difficult. How does a bank prove a negative for where the funds come from? De-banking has already been a problem for a process-based AML regime.

Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.

Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.

As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.

But for regular people, that is not really the world they want. If the bank app wrongly shows they’re paying a legitimate payee, such as the bank, themselves or the tax authority, people politically want the bank to reimburse.

Then the question becomes not if the user trusts the phone’s software, but if the bank trusts the software on the user’s phone. Should the bank not be able to trust the environment that can approve transfers, then the bank would be in the right to no longer offer such transfers.

Even if all sandboxing is done right, programs will be depended on to store data correctly and to show correct outputs.

But the real money was investment that didn’t see a return for the investor. The investments needed to have higher final consumption (such as through better productivity or through displacing other costs) to pay back the investment.

https://www.bea.gov/sites/default/files/2026-01/gdp3q25-upda...

Given how much of the spending is hard goods and simply not AI-able (rent, most of housing new construction, most of other goods, most health care, much of other services), the replacement theory would require a massive displacement.

So there are mechanisms to put encrypted things in workplace emails and then have some mechanism for receiver in a different organization to unencrypt. I have seen a mechanism that comes down to magic links, which I found ironic (though yes, intercepting is less of a threat than sending the data unencrypted).

I feel like supporting an option to not send an email unless STARTTLS happens is the way to go. There’s probably a lot of practical problems for, say, online Outlook or Gmail supporting that option when sending an email. But I feel like that’s the easiest solution.

I just have a hardware key on my key chain and one on a pretty fireproof safe (which I got for other reasons). But I still added a phone recovery just in case.

As I understand it, the recovery process will always wait multiple days while sending many emails to me that it's been initiated.