[Magisk] pndwal:
Guess you only mean "to manage for modders"?... Well that's just progress... Same happened to cars!...

FWIW, the AVB attestation is only necessary because Google allows modding in the first place... Also, I think software on Windows machines can check if Secure Boot is enforced or not just as you can check in System Summary... 😛

Google has created for most users a system that will run with 'Verified' Boot, ie in Green state... They could easily have locked down all consumer devices so that after initial loading and e-fuses are set, bootloader cannot be unlocked (of course some OEM's do prevent 'OEM unlocking'). In this case an attestation to AVB would be superfluous as no OS could run in Orange (Unverified, UNLOCKED) or Yellow (SelfSigned, LOCKED with custom keys, ie user-settable root of trust is used) AVB VerifiedBootState, but in order to facilitate a means to "ensure all executed code comes from a trusted source" in the totally mod-able and root-able OS that Android is, a verification for boot state beginning with a Root of trust (the cryptographic key used to sign the copy of Android stored on the device with the private part of the root of trust is known only to the device manufacturer) derived from a hardware keystore is now used to attest to Green (Verified, LOCKED and user-settable root of trust is not used) boot state... In other words Verified Boot only ever existed if boot state is green and CTS/VTS compliance is met... This allows Android to be used by a few other users (modders 😛) without 'Verified' Boot (green state)... Of course these users would (normally) lose the benefits of Verified Boot and some software/apps refuse to run...

On the other hand, it seems that other systems simply enforce one-state security standard like Secure Boot order to run software and all OS components as well as some hardware...

While I have only read a little about the enforcement of Secure Boot on Windows machines, the concept actually seems similar to AVB even if PC's are behind mobile OS's... You must disable Secure Boot in order to run Linux or even non compliant hardware... Thankfully, as with Android/Google allowing running without AVB (Green state), Windows/Microsoft allow running without Secure Boot... Of course you'll also lose the benefits of Secure Boot and some software/apps already refuse to run on such systems... I'm guessing that banks won't allow their apps to run on non-SB machines in future although I don't know if any have started blocking such use already...

I do know that for biometric scanner support on current machines, TPM 2.0 hardware support is mandatory... I guess this means Secure Boot, which requires TPM 2.0, must also be enabled... So it seems that for bank apps on PCs to utilise biometric identification (and probably also NFC/contactless payments), Secure Boot enabled machines will already be required.

FWIW, Secure Boot debuted in Win8 and while Windows 11+ seems to mandate it generally, it will still run without it per:

https://learn.microsoft.com/en-us/w...desktop/disabling-secure-boot?view=windows-11

and from link above this official method to disable it is given: Disable Secure Boot...

Well I guess they just spend the dough and follow the advice their researchers give em cos they're ignorant then...

One of the first articles I came accoss (this time) with a quick search was from a fintech solution provider (apparently just in Australia alone there are over 800 fintech companies in State and Territory capitals and the fintech industry in Australia has grown from a $250 million industry in 2015 to a $45 billion industry in 2023) and said:

https://geniusee.com/single-blog/how-to-improve-the-mobile-banking-app-security

That article goes on to discuss issues with Banking Trojans, Fake Banking Apps, Man-In-The-Middle (MiTM) Attacks, Clickjacking and more methods cybercriminals attempt to use in cyberattacks on banks/customers... it further states:

(Bolding mine) and:

I indicated in my post above why limitations in sandbox implementations etc are also a good argument for including guarantees of system integrity (such as Android Verified Boot and Secure Boot) even for browser based banking...

Further, banks are actually very concerned about security protocols for browser based services, recommending a short list of browsers, eg some recommend a built-in VPN shield as well as HTTPS protocols and features that block tracking and fingerprinting like Opera and Avast... Others prevent apps running on older browsers that don't at least feature Extended Validation SSL compatibility and newer security protocols...

Some banks with leading security protocols are now even producing their own security enhanced browsers especially built for use with banking services, eg German Sparkasse Bank's S-Protect, a so-called 'hardened banking' browser with improved prevention of Trojans and other malicious programs spying or manipulating banking sessions. It is built for Sparkasse by Coronic GmbH who have also built “protect browsers” for other clients...

Although you keep comparing the two approaches, browser based services are a different breed and may run on machines that don't need to consider the use of biometric ID scanners, contactless payments with their mobile wallets and host card emulation (HCE) etc that are always processed in TEE or equivalent using cryptographic keys/certificates/tokens... These value added conveniences really make enforcement of secure (unmodded, read un-tampered) runtime environments imperative for both banks and the OEMs adding NFC and biometric tech etc on mobile devices, and they do of course protect other sensitive functions as a bonus...

With the above in mind it stands to reason that the security that you decry has come to mobile OSs first, but biometric scanners, NFC and more are increasingly coming to PC tech too... Enforcement of secure runtime environments is coming to the PC too, at least if they are fully bank-capable, simply cos it's a no-brainer for the industry...

------​

Anyway, I'm sure you've also read of or even commissioned your own studies that indicate that the security measures banks implement and enforce are simply "much cheaper and less unpopular for banks to implement than any kind of meaningful security that actually *could* be effective against a significant amount of fraud", and that there really is no security value in them, but unfortunately I've only ever sighted compelling studies and papers that support a contrary position... I guess you might be about to cite these studies however... PW