You could even make this an installation-time option. If you want to enable the switch afterwards, you have to do a factory reset. Then, the attackers convincing the victims would get nothing.

Or make sideloading available only after 24 hours since enabling it. I would enable it on my new devices and wait 24 hours before installing F-Droid and other apps. Not a problem. Scammers might wait one day too but it decreases the chances of success because friends and family members can interfere.

But I'm afraid that this is security theater and the true goal is to protect revenues by making it hard or impossible to install apps that impact Alfabet bottom line (eg third party YouTube clients.)

> But I'm afraid that this is security theater and the true goal is to protect revenues by making it hard or impossible to install apps that impact Alfabet bottom line (eg third party YouTube clients.)

It's not just them. Every other SaaS, from banks to media providers to E2EE[0] chat clients to random apps whose makers feel insecure, or are obsessed with security [theater] best practices, just salivate at the thought of being able to check if you're a deviant running with root or debugging privileges, all because ${complex web of excuses that often sound plausible if you don't look too closely}. There's a huge demand for device attestation, remote or otherwise.

--

[0] - End-to-end Enshittified.

In the case of most of those business it's only because they must mark checkboxes on a regulation compliance sheet and/or deflect blame on someone else. The problem is that this is a never ending spiral of regulation after regulation and new ways to deflect blame so after device attestation will fail to solve all of their problems they'll end up pushing something else.

And now if I want to send a .apk to someone, they have to wipe their entire phone to install it? No thanks.

That's... brilliant. Enough work to not be able to talk it though over the phone to someone not technical. A sane default for people who don't know about security. And a simple enough procedure for the technically minded and brave.

It solves the 'smartest bear / dumbest human' overlap design concern in this situation.

Think about it the way you think about reading the fine print on agreements you sign. These can also have bad consequences.

But I guess not reading the TOS is another wide problem, also fueled by companies like Google.

It's either that or as suggested, hard require developer validation for specific API permissions.

It is unreasonable to require a payment for people to use their own phone the way they want

They are already buying a locked down phone most of the time. And they already want this! (Unfortunately the bootloaders are locked, as far as I know.)

Developers want developer phones, non-developers want safe phones that are resistant to their and their shitty bank's goddamn fucking stupidity. (Because banks UX is so so so so bad that most of the time the phishing attack seems like just a normal part of the bank's UX.)

But it's hard to separate people on a webshop, if a shop runs out of non-developer phones they'll happily sell the developer phones to non-developers.