mwwaters (u/mwwaters)

mwwaters commented on Open Letter to Google on Mandatory Developer Registration for App Distribution keepandroidopen.org/open-... · Posted by u/kaplun

Hizonner · 19 days ago

If the actual bank app does that, or is even easy to fool into doing that, then the bank should be responsible. That's the world "regular people" want and it's the world as it should be.

If random malware the user chose to install does that, then that is not the bank's fault. The bank is no more involved than anybody else. And no, I don't think "regular people" want to make that the bank's fault.

mwwaters · 19 days ago

The legal infrastructure for banking and securities ownership has long had defaults for liability assignment.

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.

mwwaters commented on Open Letter to Google on Mandatory Developer Registration for App Distribution keepandroidopen.org/open-... · Posted by u/kaplun

tadfisher · 19 days ago

Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app.

The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association.

mwwaters · 19 days ago

If the side loaded app does not have permission to use the passkeys and cannot somehow get the user to approve passkey access of the new app, that would be a good alternative to still allow custom apps.

mwwaters commented on Open Letter to Google on Mandatory Developer Registration for App Distribution keepandroidopen.org/open-... · Posted by u/kaplun

jasonjayr · 19 days ago

Why do banks go through all the know-your-customer (KYC) process if not to identify the beneficial owner of every account? If they receive a transfer via fraud, then they either get it clawed back, have to pay it back, and/or get identified to law enforcement. If the last bank in the chain doesn't want to play by the rules, then other banks shouldn't transfer into them, or that bank itself should be held liable.

This is more or less how people expect things to work today ....

mwwaters · 19 days ago

In the case of some knowing or blindfully unknowing money mule in the chain or at the end of the chain, the intermediary or final banks may not be at fault. The bank could have followed KYC procedures in that somebody with that name actually existed who controlled the account.

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.

mwwaters commented on Open Letter to Google on Mandatory Developer Registration for App Distribution keepandroidopen.org/open-... · Posted by u/kaplun

JoshTriplett · 19 days ago

If you can "coach someone to ignore standard security warnings", you can coach them to give you the two-factor authentication codes, or any number of other approaches to phishing.

mwwaters · 19 days ago

The phisher’s app or login would be from a completely new device though.

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.

mwwaters commented on Open Letter to Google on Mandatory Developer Registration for App Distribution keepandroidopen.org/open-... · Posted by u/kaplun

bigstrat2003 · 19 days ago

> I agree that mandatory developer registration feels too heavy handed, but I think the community needs a better response to this problem than "nuh uh, everything's fine as it is."

Why would the community give a different response? Everything is fine as it is. Life is not safe, nor can it be made safe without taking away freedom. That is a fundamental truth of the world. At some point you need to treat people as adults, which includes letting them make very bad decisions if they insist on doing so.

Someone being gullible and willing to do things that a scammer tells them to do over the phone is not an "attack vector". It is people making a bad decision with their freedom. And that is not sufficient reason to disallow installing applications on the devices they own, any more than it would be acceptable for a bank to tell an alcoholic "we aren't going to let you withdraw your money because we know you're just spending it at the liquor store".

mwwaters · 19 days ago

There is some world where somebody scammed through sideloading loses their life savings, and every country is politically fine with the customer, not the bank, taking the losses.

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.

mwwaters commented on Claude Sonnet 4.6 anthropic.com/news/claude... · Posted by u/adocomplete

nprz · a month ago

You go to chatGPT and say "produce a detailed prompt that will create a functioning todo app" and then put that output into Claude Code and you now have a TODO app.

mwwaters · a month ago

Maybe I’m biased working in insurance software, but I don’t get the feeling much programming happens where the code can be completely stochastically generated, never have its code reviewed, and that will be okay with users/customers/governments/etc.

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

mwwaters commented on AI is destroying open source, and it's not even good yet jeffgeerling.com/blog/202... · Posted by u/VorpalWay

throwaway150 · a month ago

If a PR claims to solve a problem that I don't need, then I can skip its review because I'll never merge it.

I don't think every PR needs reviewing. Some PRs we can ignore just by taking a quick look at what the PR claims to do. This only requires a quick glance, not a PR review.

mwwaters · a month ago

I took this thread as asking whether PRs that are pulled in should be reviewed.

mwwaters commented on The AI boom is causing shortages everywhere else washingtonpost.com/techno... · Posted by u/1vuio0pswjnm7

coffeemug · a month ago

Azure revenue is growing at 39% year over year. If Microsoft can sustain this growth, in four years Azure will be ~3.73x its current size. This is of course very difficult, but you really don’t need a deus ex machina to hit 4x growth under your assumptions.

mwwaters · a month ago

The issue in the late-90s was all the investment created a lot of real revenue for telecoms and other companies. Even though there were a lot of shenanigans with revenue, a lot of real money was spent on fiber and tech generally.

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.

mwwaters commented on The AI boom is causing shortages everywhere else washingtonpost.com/techno... · Posted by u/1vuio0pswjnm7

geysersam · a month ago

Doesn't have to go up. It's also fine if they replace other parts of the economy.

mwwaters · a month ago

In the expenditures for the economy making up GDP, not a lot of it screams “AI-able.” Page 9 here breaks down GDP on expenditure basis.

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.

mwwaters commented on Poor Johnny still won't encrypt bfswa.substack.com/p/poor... · Posted by u/zdw

mmh0000 · 3 months ago

Nearly all email is encrypted in transit. All major MTA systems send encrypted and accept encrypted as the default.

This article is about encrypting the body of the email which is easy* but no widely implemented standard exists.

* Stupid easy for two nerds to email securely.

* Stupid hard to work with multiple people and non-nerds.

mwwaters · 3 months ago

It seems like the bigger day to day issue is the possibility of downgrades from STARTTLS or a server that doesn’t support TLS. Encryption in the GPG isn’t necessary or even would be unwanted (for a company to have records of all the emails).

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.