If a person decides to give up control of their device to another person or organization (like the device manufacturer) fine, but that should be a voluntary decision on the part of the user, not something forced.
There is a wide gap between being unable to decide for oneself in the general case, like a child, and being unable to decide for oneself due to lack of expert knowledge. Sometimes, less is more. Apple built its brand on this insight.
As long as the dialog for unlocking your phone would clearly state the risks and what it does, unlike those toolbars upon installation, I think it would totally be OK.
Imagine if you couldnt install Linux on any PC because Dell didnt give you the keys to prevent you from hurting yourself. Or Apple didnt allow sudo in macOS. Seems kinda absurd right? Yet this is the standard for phones.
Also Id like to point out that Android allows installation of external APKs (after activating) and it didnt lead to a super increase in malware, as user still prefer the Play Store, and APK are usually left for the more technically inclined user for niche purposes or often times Region lock circumventing.
Are you sure about that? I pulled an old, cheap Android phone out of storage box to do some debugging. I needed a quick file manager app, installed one of the top results on Google Play that was baked with some malware that may have bricked the device (didn't bother to try to fix it, it's in the bootloader). Granted this was an old version of Android, but that's still a bit egregious. I can't recall anything like that happening on iOS.
https://blog.zimperium.com/new-advanced-android-malware-posi...
-> "Upon installation (from a third party store, not Google Play Store), the device gets registered with the Firebase Command and Control (C&C) with details such as the presence or absence of WhatsApp, battery percentage, storage stats, the token received from the Firebase messaging service, and the type of internet connection. "
It isn't hard to find similar reports, there are enough of them.
I want people to have more control over devices but there are some non-trivial threats which millions of people face which are currently defanged by things like the OS not allowing malware installs, or hiding the use of various sensors or data access, etc.
Sure, do everything you can to educate the user on what they're doing and make things as hard as possible for scammers, but ultimately it must be their choice who controls their device, not yours.
For example, if you buy a car there are safety features you cannot turn off without major modifications. Dangerous tools often have safety guards built-in to the design — for example, my blender doesn't say it's my choice whether to keep the spinning blade covered. My bank doesn't say it's my choice whether or not to identify myself when making a withdrawal.
For most people, iOS limiting the damage when they get compromised is a huge plus. Removing that entirely in the absolute position is bringing people back a couple of decades ago only now the malware will have access to their most private moments and data 24x7 rather than just their Geocities browsing history.
Now, consider what that means for something like unlocking the bootloader. Allowing that means undetectable malware, potentially irrecoverable. There's not really a good way around that and even if you try to inform people at the time they enable it that doesn't help if it's done when the device is out of their control (abusive partner, boss, police, etc.), and every on-screen indicator can be faked by the malware vendor. That leaves options like a physical switch in a prominent location which most people aren't going to want to pay for or see, and are more likely to be used by accident than intentionally.
A phone is not, usually, a dangerous tool. Unless you can make it explode :)
> For most people, iOS limiting the damage when they get compromised is a huge plus.
Then just dont unlock. The unlock would need to be done from inside the OS, by the user, not by external actor.
> Now, consider what that means for something like unlocking the bootloader. Allowing that means undetectable malware, potentially irrecoverable. There's not really a good way around that and even if you try to inform people at the time they enable it that doesn't help if it's done when the device is out of their control (abusive partner, boss, police, etc.)
If you have an abusive partner, boss, etc. you're already at risk because they will keep looking at your phone anyway and you're in no position to refuse. A way better solution is to have a burner phone they don't know about.
Agreed with the police point, but I think after getting your phone from police you could just clean install iOS again to make sure nothing unwanted is there.
P.S. On 2nd hand market, you could just as easily reinstall stock iOS once you buy a new phone to prevent buying 2nd hand unlocked iPhone with malware.
What if _you_ didn’t? I outlined scenarios which are real risks for millions of people and a fair fraction of those either involve no or limited user consent. Maybe it’d be possible to have a secure factory reset – this is harder than it might seem with firmware in so many places – but that only helps if you even know that you need to. Anything which allows undetectable rootkits means that a large number of people will never even realize that because phones are general purpose devices and most people are not security experts. Worse, how many of them are actively being betrayed by trusted experts - abusive partners, unethical technicians, etc. - who will say it’s fine?
To use a direct analogy with Apple's restrictions on users, you're free to modify and flash your car's ECU firmware. In fact, it's quite common.
Really? How have you defined common? Where is that data from? I can't imagine anything more than a tiny fraction of car owners are doing this. Most people are not hacking their cars, building Raspberry Pi controllers for their toilets, or have any desire whatsoever to side load an app on their iPhone. The HN community is not representative of the overall population.
But no one says the car manufacturers are required to make a car where you can flash the ECU. There’s just no reason for them to block it. If someone came up with a way to steal your car by tricking your into running an app that flashed your ECU then you can bet Ford would disable it pretty quickly.
Sure there is… if they are providing warranty on the vehicle then they should definitely block ECU mods, as a customer could flash original firmware back after causing damage.
And I imagine you can easily make an engine over-rev or overheat with a modded ECU, perhaps to the point of causing a fire or other catastrophe.
The reality is it isn’t 1981 and computers aren’t toys or cloistered academic devices anymore. Mass market platforms need to be more secure than 90s era tech allowed.
Exactly but what you’re missing is that with iOS this decision is made when you buy the phone.
Eventually also google, Amazon, anyone under the sun will do the same, just in case some aspect of your privacy is not captured.
Technical solutions (like preventing side-loading) cannot possibly eliminate the thing driving the behavior; profit motive for stealthily gathering data to build "better" user profiles to lease to advertisers.
A much better solution would be to create better permissions models (capability-based) for mobile devices.
As an example, one could build a granular permissions model which forced apps to be composed of multiple modules. Each module would have their own sets of mutually exclusive permissions.
An app that allowed the user to apply filters to photos/videos could be composed of two modules:
One which had read and create permissions for files the photo library along with read-only access to an app-local storage directory
A module which had the network communications permissions (exclusively by OS APIs that performed all the crypto[1]) and write-only access to the app-local storage directory (for downloading new filters)
By forcing apps to be broken up into separate modules and ensuring that all network communication is done from a carefully constrained sandbox (which can only read/transmit a tiny subset of data generated/available to the app), users could see exactly what the app transmitted without having to install their own self-signed root certificate (and maybe also jailbreak their devices if the app that they're interested in is using certificate pinning or ignoring the OS certificates).
The best way to technically combat a lot of this sort of data-slurping nonsense would be to force apps to have near[1] total transparency for all network communication for any user that wanted to see.
[1] The OS crypto API would have to provide a few authentication routines which blanked passwords, secret keys, etc. after use to prevent the unintentional leaking of secrets. Those APIs would obviously have to be designed to be resistant to malicious use by Facebook, etc.