This seems silly, you can easily flip this on its head and say "Well the iPhone is closed, so there's no way to verify it has any security". You can't separate the ethics of security advertising from the ethics of everything else about how the device works.
However, in the context of ethical security conversations, the two are anything but orthogonal. The security expectations of someone buying an open phone, and the security expectations of someone buying "private" access into a proprietary platform, will be different. Sure, my baseband could be compromised, but if I'm more worried about leaking information to ad networks, what I really need is a firewall and hosts file, not an isolated baseband unit. If we're talking about an ethical security conversation, maybe we should mention the fact that this is the security Apple has to control what code runs on your phone, not the security a user has to control the flow of their data. Though, presumably you can have both goals, Apple shows interest only in the former.
My point being the two phones are extremely different products, especially regarding ethics, so the straightforward comparison and verdict struck me as extremely narrow-minded about how people use their phones.
I bring it up because the project makes a very big deal out of how much security their ethical approach adds. From what I can tell, their approach nets them materially less security than either flagship phone.
Most users care much more about the decisions that Apple and Google make with their data than they are about $random_blackhat.
Even more, a lot of the security features you mentioned are very difficult for an open source phone to achieve because the hardware ecosystem is so endemically closed source and proprietary. We can fix that by pushing hard for open source hardware that starts to make inroads and break those barriers down.
When Apple decides to take away an app I paid for, I have no security to block them. When Apple decides to quit posting security updates, I'm out of luck. When Google reaches in and takes my location data without permission, I can't stop them.
With open software, there's no guarantee I'm more secure. But when some security issue does come to my attention, I'm more likely to have some say in how I respond. Somebody claims to have a more secure or privacy-respecting driver? Strongly recommended by experts I trust? I'll look into it. With Apple, I can't. There is no such alternative.
The ssl lib has known vulnerabilities? Wait for Apple? Or install some shim until there's a fix? Oh wait, on Apple devices, you don't have an option.
Apple is not only closed. It's walled. As the owner I am kept on the wrong side of the wall. And there are parties on the other side of the wall that I don't want to be on that side.
This is a security model that is hard to lose to. If Purism let's me control the wall, I'd say that's a welcome change.
> When Apple decides to take away an app I paid for, I have no security to block them. When Apple decides to quit posting security updates, I'm out of luck. When Google reaches in and takes my location data without permission, I can't stop them.
This is not security. This is some weird definition of security you're using here.
> With open software, there's no guarantee I'm more secure. But when some security issue does come to my attention, I'm more likely to have some say in how I respond. Somebody claims to have a more secure or privacy-respecting driver? Strongly recommended by experts I trust? I'll look into it. With Apple, I can't. There is no such alternative.
Software security doesn't much matter with phones when the hardware security is crippled or non-existent.
Software security means fuck-all if you can pull from the phone's memory via a cable, via the modem, or via JTAG. The iPhone is the most secured hardware of any phone on the market and by quite a long shot.
Reading through the comments here is frustrating because tptacek seems to be talking about hardware and all of the responders are talking about software. It's not like your personal computer where you "need to get physical access in a powered on state". Getting access to an adversary's phone is _beyond trivial_.
I'm just trying to draw emphasis to your point being sound and not for HN personality-cult reasons.
To understand means to see beyond security design to see security principles. If one company magically decides to move your data to a government controlled cloud without any public discussion around why or if they even agree with it, the design is not going to matter. When the next internal decision occurs negatively affecting security in some undiscussed opaque way, you won't be able to point to security audits to explain the folly of human traits.
For instance in this case it seems like the iPhone has (considerably) more hardened hardware for many scenarios where you lose control of your phone. That’s not the only sense of security people care about. From the perspective of securing the phone from doing unwanted things without your permission, you have to trust Apple entirely to make the right decision. If you don’t trust Apple to make these decisions, the phone does not reflect a secure interaction.
If the software I use to verify the closed source software is closed, then I will need another piece of software to verify that the verify-ing software is what it says it is and so on until we reach a piece of software that I can verify with my own eyes (or a friend has verified with their eyes).
We all eventually have to place our trust somewhere but we shouldn't have to agree with where you decided to trust.
For fun I just compared objdump's entry point function assembly of a downloaded Pokemon Go IPA to the Hopper representation, and, no surprise, they are identical.
Quite the opposite it’s axiomatic in the industry that you need capabilities to verify closed source.
No one knows what nasties are hidden in these blobs that run on EVERY phone out there. I’d actually go as far as saying cell phone processing modules are completely insecure. Unlikely to receive updates. Poorly documented. Security standards are likely to be weakly implemented with gaping holes.
As for proof, I’d point at the lack of source code as a starting point. Open source doesn’t guarantee security but it at least lets interested parties try to the degree they want or need to.
Much better proof would be frequent exploits through the vectors you consider examples glaring insecurity.
I’m sure various agencies are quite frustrated by their inability to use the cellular modem as an entry point into Apple’s phones. That by itself is another pointer.
I didn’t claim to have proof other than that.
Why is a trillion-dollar company which designs their own silicon only two steps ahead of some hackers? Instead of $200 billion in the bank, unspent, shouldn't those devices be reviewed and redesigned until impregnable?
Computing devices are usually insecure due to limits on experience, time and cost. None of those applies to Apple in any meaningful manner.
Personally I'll just stick with cheap Android phones running custom ROMs and treat them as insecure, disposable terminals.
Also, it's not some hackers. There's quite a big community out there looking for bugs and every time, such 'hacking' requires unlocked phone.
The problem is the Mythical Man-Month. Apple's devices are built on a mountain of ancient C code. XNU is a bizarre Mach/BSD hybrid, built for the sake of expedience. (This is not to bash Apple; most other devices aren't much better.)
Apple has been working to improve the situation, but there's a limit as to how rapidly all those millions of lines of code can be changed.