The problem in this case is that you get the malware installed through a no-click required iMessage and not a "supply chain" attack on the image your phone is running on. How would that help?
The problem in this case is that you get the malware installed through a no-click required iMessage and not a "supply chain" attack on the image your phone is running on. How would that help?
Utilizing different software implementations limits the scope of this type of attack. The current trend to increasing centralization and forced-update monoculture is a huge gift to malware authors: they only have to write one version of their malware to affect everyone.
[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....
In practice we may find a monoculture within a hidden layer of the stack than we're optimizing for, such as an OS kernel method, TLS library or chipset which coincidentally has captured the entire market. When a clever enough exploit on a common resource is found, then the problem transforms to one of coordinating patching for the same, wherein a broad ecosystem of higher level components (like Android or PCs) becomes nearly impossible to thoroughly cover. As such malware authors may potentially still get away with writing a single version of their software so long as they target low-level enough. With sufficient fragmentation they don't even need to invent their own exploits, just use publicly known CVEs that they can brute-force against older devices.
(Not saying you're wrong, your recommendation may still be better in the long-run. We're after all weighing the risk level of black swan events, such as a zero-day on a low level of the stack, or a high level of the stack on a high-volume vendor)
But we were talking about the general case of monoculture, not closed source monoculture. Even for closed source software, where more eyes are prevented from looking "by definition", having a monoculture can in theory allow more code audits to be done, because of economy of scale.
> large number of people using the software doesn't imply there is also a large amount of people reviewing it.
Right, but roughly speaking, the number of reviewers should monotonically increase given an increase in users. Whether that produces better security overall is anyone's guess. My point was just that there was a counteracting force to consider.
The argument is that removing freedoms from owners in the name of security is a false dichotomy because bad actors will still gain the ability to execute arbitrary code whilst owners of devices won't be able to do so.
Also, if I could provide the software I want to run, I'd probably not have iMessage.
Which is all to say, ideally a journalist would have N phones, one per source. But that's impractical.