5 ms·
Well, no, I think it's still very relevant. To use the classic XKCD comic, the crux of the case is that FBI is the one arguing the first panel (i.e., some bogu
by csydas 11y ago
Well, no, I think it's still very relevant.
To use the classic XKCD comic, the crux of the case is that FBI is the one arguing the first panel (i.e., some bogus magical encryption we can never break), and because of that claim, they need to be able to compel Apple to compromise the security features using the old wrench trick.
The reality of there being practical alternatives for the FBI to pursue should give pause as to whether they can compel Apple to compromise the security features, and arguably the method described/discussed is indeed very practical.
All in all, it's less about the FBI's ability to do any of this and instead more about "should be the allowed to force a company to do something like this?". By demonstrating the claim that it's impossible to proceed without Apple's help is not true, I would think it should give pause to any court as to how to rule, since the implication of the ruling is pretty big.
- timr 11y agoThe point is that the definition of "practical" is debatable -- any reasonable person can see that there are more risks associated with mucking around with the circuit board than having Apple install a custom software build, which carries no technical risk at all. It doesn't matter that you can come up with some theoretically plausible attack that works in this one case. If it's harder or riskier or slower or less effective than Apple complying with the warrant, then the question stands.
- semiel 11y agoIt actually seems clearly the opposite to me. This approach uses standard tools and methodologies for which there are already experts. Asking Apple to write new firmware has the potential of software bugs and similar unexpected issues.
- deleted 11y ago[deleted]
- ins0 11y agoI agree with you. Writing a custom firmware on the device is on the same risk level as desoldering the chip. In both cases it would be a smart option to test this approaches on a different device first.
- deleted 11y ago[deleted]
- dlp211 11y agoThe difference is that one of those options is nearly completely reproducible, the other requires humans to deconstruct a device which introduces more chances for things to go wrong.
- bryanrasmussen 11y agoyeah, so if Apple writes a new firmware upgrade (in a couple years from now) and the device has something in it's configuration that in conjunction with a new bug in the firmware ends up bricking the device... I wonder what then.