mwwaters

A sufficiently sandboxed, low-stakes thing that self-verifies by its visual output can be easily created by AI.

For security or applying business logic (and how it interfaces with programming or database logic), you get less and less assurance by just looking at it.

It would need to be through TLDs all reporting new DANE records, or DANE itself would need to change.

The threat model here is the TLD was somehow unknowingly hacked and the bad DNS records are somehow not noticed. Or worse, the body governing TLD is in on it. In these cases, only the users of the websites are in a position to report on the bad certs. Each website could try to monitor the DNS records similar to CT logs, though for targeted attacks that may not work.

Again, I don’t get this argument. A compromised TLD absolutely kills any validation (other than EV) already. An A/AAAA can be posted for page validation or TXT for DNS validation.

As far as I know, no TLD operator has gotten the death penalty. It is technically possible for root to change the IP addresses, but it would be bound up in whatever the governance is of the domains.

But the downside isn’t something new that would just apply to a DANE world. That downside still exists in the CA world. The CA is just an additional point of failure, along with the TLD.

What is added by the CA world is CT.

I meant that for a compromised TLD key, the DS record at root lasts for a day. So I didn’t follow how the compromise in a theoretical DANE-only world would be inherently long-lasting.

You said “no recourse,” which I took to mean no recourse even if known. I don’t follow that. The key/DS record at root can be changed. There may not be a “TLD death penalty,” but the key could be changed.

Now without CT it may be tougher to know about the compromise. For websites that don’t have the luxury of certificate pinning, a compromise of TLD kills the whole thing, at least for a time.

Low TTLs aren’t incompatible with the ideal of using DNSSEC though? From what I can tell DS records typically have TTL of 1 day in the root domain.

What is a difference, versus DANE, is that TLS uses CT. Compromised TLDs happened recently but was found out through CT. A compromised TLD still kills the whole system for a time regardless.

I think DNSSEC still has some use in enforcing email TLS and for CAs.

I liked the idea conceptually of CAA record only allowing DNS validation. Then use DNSSEC.

I say “conceptually” since I know: 1. Actual attacks found with CT have used compromised TLDs, which kills the whole thing anyway, and 2. I haven’t really seen where the hosting company’s infrastructure (BGP ads and internal routing) is what’s compromised. Well certainly in the latter case they can probably also get in to the hosting machines directly.

Which userspace API was changed?

Internal Kernel API changes all the time which can break proprietary drivers. But userspace API has a far higher guarantee.

I know this is true. But I don’t think “Some parts of important codebases are black boxes. Therefore it’s fine if all of that code base becomes a far bigger black box” sounds like a good argument.

Also, there was probably some human at some point that had some understanding of what they were trying to do and why. The black boxes generally get programmed around after they long left but at the time they had bugs ironed out over decades. (Yes I know sometimes true slop is done over a short period of time and the programmer leaves. But I’ve generally seen the black box built over decades instead).

The Windows 11 ISO on a two year old Lenovo laptop did not have the Ethernet or WiFi driver. “Have Disk” also did not work for whatever reason when I downloaded the driver to a USB drive. I had to open up a command prompt within the Windows installer and run the GUI driver installer.

In Linux, I now have a custom Arch install which Gemini did help with a lot. It helped unblock significantly where I wanted to get fundamental understanding. A Debian installer will just work though (ironically, some years ago, I had issues with Ubuntu working out of the box but not Debian).

The passkey method uses Bluetooth to ensure proximity.

The far bigger benefit is phishing resistance (with hardware-contained keys themselves being phishing-proof on a non-compromised system).

It moves to the account recovery flows, but that can be much more difficult to phish.

The first FRED link shows how noisy that subgroup is. It’s bounced around with 83-84% during that time. It was 83.8% in March and 83.5% through much of 2024.

OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs.

OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).

When I really dove into it, I understood mostly why all the complexity was all there if I cared about data at the identity provider.

When it’s only used for SSO, it’s extreme overkill.

That is for whatever it considers reverse-engineering the model to try to create a competing one.

The “enough of us” is at least a majority of voters agreeing. I’m not sure what the alternative to that is.

For doing some reporting stuff internally, there isn’t a certification. But there are definitely humans who have to certify financial statements and communications for financial offerings.

SLAAC and link-local is very different from DHCP/NAT/etc. in IPv4 world. Link-local addresses are pretty arcane in IPv4 while they are a central idea in IPv6.

That’s fine. As pointed out elsewhere, DHCP was relatively new when IPv6 was introduced. But it is a learning curve well past just knowing the difference between NAT and stateful firewall.

Yeah, that’s the issue.

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

There’s certainly a lot of uncertainty.

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.

The scams are more sophisticated than getting gift cards to pay the IRS. A number saying that it’s from the bank will say they need to verify some account information.

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.

I’ve heard the actual OEM cost is offset by the manufacturer getting paid for all the bloatware included.

Electricity price regulation, at least for transmission, has been a thing for states for 100+ years and federally since the 1930s. Pipelines and railroads also have price regulation of some sort.

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.

Electric utilities face price caps and there are not electricity shortages.

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

Medicare has overhead, but you’re not saying whether it is more than commercial insurance. The admin expense/profit portion of commercial insurers also don’t take into account provider admin costs (not to mention the huge amount of time patients can deal with denials, appeals, etc.)

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.

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.

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.

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.

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.