[lwswl]

Honestly, this is bad news, because it means Apple is no longer capable of offering both security and all features, but now needs to spit them into groups, presumably because they need to keep up with (the clearly less secure) Android...

[capableweb]

Security has never been "Secure or not" proposition, it's always a balance between convenience and safety against threats, threats that change depending on who you are, and who is targeting you.

Some features are (understandably) almost impossible to make very safe. Take PDF viewing for example, the entire thing is so huge, that it's bound to be holes in any implementation, just like what the NSO proved some time ago with the iMessage exploit.

I take this effort as something similar to the "Hardened Linux" effort. Just that it exists doesn't mean that Linux is "unsecure", it just means that if you really need to, there is more steps you can take to make it even more secure. Just like what Apple is doing here.

[vorpalhex]

If I could upvote you twice, I would.

Security is always a tradeoff and there is no single answer. A feature for one person is another person's hell.

An acquiantance just lost all their data because they had enabled "format on too many missed passcodes" and their kid was playing with their phone.. caused quite a few tears. On the other hand, that feature is invaluable to international travelers.

[lekevicius]

What a strange implementation of "format on too many missed passcodes". Apple (on iOS and watchOS) implements this, but after some amount of failures, phone gets into progressively longer lockdowns. So maybe after 3 failed attempts you have to wait 2 minutes, after 4th 5 minutes, and before the final (formatting) attempt you have to wait something like 12 hours. This prevents "kid playing with the phone" problem.

[lekevicius]

I see this as securing against "unknown unknowns". No software can ever be "100% bug free". If you can identify areas that are more likely to contain yet-undiscovered vulnerabilities and turn them off in advance, the device becomes more secure.

[alwillis]

Honestly, this is bad news, because it means Apple is no longer capable of offering both security and all features…

Absolutely not true.

There’s a difference between being secure and having all of the features and being secure against a state-level attacker. The vast majority of users are quite secure while enjoying all of the features of their iPhones.

For those who are being targeted, potentially in a life or death situation, being able to send attachments in iMessage is trivial by comparison. Only a tiny percentage of iPhone users should ever have to enable this; it won’t impact the user experience of over 95% of iPhone users at all.

[npteljes]

Security and convenience _can_ coexist, but you can't transition into a more secure world without breaking convenient, insecure stuff that already exists and users expect it to just work. Later they can ramp this up.

[olliej]

No, this is a completely reasonable response.

Security by reducing attack surface is a standard, and sensible response.

What you are asking for is that Apple (or any company) be able to produce absolutely 100% bug free code, no matter the complexity or requirements. This feature is an acknowledgement that what you're asking for is an unreasonable demand for any company.

So Apple has looked at the attack surface present by default, and then provided an option to that trades off removing presumably low use features in exchange for removing large attack surface. That is a trade off: for example any modern phone would be vastly more secure if all it could do is make phone calls, and everything - the browser, apps, etc - were disabled. But that end of the spectrum results in an impractically restricted device, in reality there's a middle ground, but for high profile targets the trade off is closer to "just a phone" than it is for normal users.

An example is the RW^X region required to support JITting JS - the OS simply supporting such memory region at all was a huge addition of attack surface to the platform - prior to that every single executable page was protected by code signing, afterwards there was a region that by definition the OS could not verify, and it has been used by every attack since then. But disabling that simply disables the JIT, the JS interpreter runs, so the impact is only that some web content runs slower, but the functionality itself is still there.

Similar for messages: receiving JPEGs is super common, receiving OpenEXR or whatever probably isn't, so removing everything other than JPEG by default again removes attack surface without realistically impacting the usability of messages.