Comment by preg_match

Fortunately, it's not a linear scale. All sorts of technical and political options exist which don't fall cleanly into the anarchy or baby-proofing spectrum. Random incomplete examples, in no particular order and off the top of my head:

GGP's idea of making it more commonplace to have a "Johnny" helping people with their tech needs to prevent accidents could work socially, if there are ways for communities to create more people willing to do that.

Worldwide legal penalties for spamming/scamming could grow more teeth, increasing the likelihood of bad outcomes for people that make malware or questionable apps.

Software distribution systems could standardize on better systems of provenance and ownership handoff to further technically harden against "good extension sold out to an evil maintainer" or "github credential leak let a bad guy publish an artifact"-type attacks.

Cooldown periods for users trying to grant questionable access patterns could be imposed, though that might feel too baby-proof for some.

On-device permission boundaries could be modeled in an "XOR" way: apps distributed from Apple's walled garden could be disallowed from approving data sharing with apps users install from other repositories. That's Apple's prerogative (they own the distribution and vouch for at least some of the quality of the app store apps), but doesn't prevent users from installing parallel ecosystems if they want.

Something that's very paternalistic, but doesn't involve baby-proofing what's possible, is the idea of credentialing users. You need a driver's license to operate a car. In the US, you need a (much easier to get) food handling license to commercially process food. The latter's a short briefing and test of comparable effort to those mandatory corporate anti-phishing trainings that already-technical people hate. Perhaps some users could benefit from that as a prerequisite to installing non-trusted software.

For vetted walled gardens like the App Store, further improving the granularity of and required justifications for permission requests as providers have been doing might help. "This poker app wants to access all of your saved contacts and photos" becomes "this poker app wants you to select a single profile photo and up to 5 contacts a day to add as opponents, after which access is revoked" or whatnot. This only works if App Store reviewers get serious about rejecting apps for overbroad permissions requests and explain their rationale to app developers, which would require Apple and friends to spend a lot of money to enable. Fortunately, they have insane margins. Less fortunately, their shareholders wouldn't go for this unless forced by regulation or similar.

Anything that helps with threat attribution. If Grandma can install an app from a random URL, and then gets hacked 6 months later, it'd be great if something got in her face that loudly indicated that the decision to install the untrusted app was the root cause of her compromise and some "do you want to disable the ability to do this in the future/require a phonecall to $provider to turn it back on?"-type hint.

For apps that spend money, further integrating pattern-aware anti-fraud and spend caps with payment APIs so that e.g. a microtransaction app that got hacked can't suddenly spend $100 where the user typically spent $5/month. Banks are already starting to get proactive/argumentative about unexpected transaction patterns a la "sir, are you sure you want to send $5000 in your first overseas money wire? Can you tell us more about that transaction? Are you aware of this common fraud?"

...and so on.

The comparison to banks is actually pretty interesting.

Unlike app developers, banks are by default directly liable for fraud that happens on their system. In many cases, even when someone gets their bank to send money to a scammer, they can still get that money back. Since the bank doesn't want to risk regulatory reprisal, they have a lower threshold for spending money to make customers whole. Exceptions and subtleties abound here, but the underlying incentive structure is very different: the broker of the sensitive resource (money, for banks) is often held responsible for mis-use of that resource. How would we do that for e.g. apps that store your password in plaintext and then get hacked?

Relatedly, banks have thus started adopting the practice of blocking and calling/talking to customers about suspicious transactions. You can still authorize it if you really push, but you have to talk to someone with expertise about fraud risk, and have to spend some time doing it (which helps a lot with the "urgency" dimension of scams). Most permission approval prompts on phones/computers have no such human intervention or time-delay option, even if you might want them to.

> The only way to 100% prevent scams is to remove the potential entirely. There are scams, infinite actually, right now, on iPhones. Do you support that? Surely not, so we should lock iPhones down more no?

Nobody here has the goal of preventing 100% of scams. The ideal amount of fraud on these platforms is not zero (https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...). Rather, fraud is still extremely common and difficult to disincentivize. We want to reduce that as much as possible while not imposing overly-onerous restrictions. The discussion is about what counts as "as much as possible" or "overly-onerous", not whether we should ban phones or banks.

> I can't install open-source software I've audited myself on my iPhone

I hope you understand you're in a very tiny minority of people who can do that, using a device designed for people who cannot do that, and whose behavior if permitted to do what you're after has a proven history of causing significant damage to individuals (who lose their savings) and shared resources (sites DDoSed by end-user-device malware, hospitals that can't provide care because someone let ransomware onto a computer, and so on).