An important security measure for who, though? The servers at the bank should "never trust the client" in case the attestation is bypassed or compromised, which is always a risk at scale.

If it's an important safety measure _for me_, shouldn't I get to decide whether I need it based on context?

I think it's fair for banks to apply different risk scores based on the signals they have available (including attestation state), but I also don't want the financial system, government & big tech platforms to have a hard veto on what devices I compute with.

▲

miki123211 an hour ago | parent [-]

It's an anti-brute-force mechanism. It's not for you, it's for all the other accounts that an unattested phone (or a bot posing as an unattested phone that just stole somebody's credentials via some 0-day data exfiltration exploit) may be trying to access.

Sure, banks could probably build a mechanism that lets some users opt out of this, just as they could add a Klingon localization to their apps. There just isn't enough demand.

▲

xyzzy123 25 minutes ago | parent [-]

If you work on mobile apps you will notice that full attestation is too slow to put in the login path. [This might be better than it used to be, now in 2026].

I don't think a good security engineer would rely on atty as "front line" anti brute force control since bypasses are not that rare. But yeah you might incorporate it into the flow. Just like captchas, rate limiting, fingerprints etc and all the other controls you need for web, anyway.

I know I'm quibbling. My concern is that future where banks can "trust the client" is a future of total big tech capture of computing platforms, and I know banks and government don't really care, but I do.

	▲	digiown 3 minutes ago \| parent [-]
		> total big tech capture of computing platforms Correct. And the end of ownership, privacy, and truth too. If something can betray you on someone else's orders, it's not yours in the first place. You'll own nothing and if you aren't happy, good luck living in the woods.