2 ms·

1) Obviously they'd test it on other devices first. Also I would expect the government to waive Apple's liability should things "fuck up". But somehow, I think

1) Obviously they'd test it on other devices first. Also I would expect the government to waive Apple's liability should things "fuck up". But somehow, I think you underestimate Apple's competency. 2) I agree the automated PIN entry system makes things more difficult and if Apple pointed out that it would be far faster in terms of combined "hacking" + development time to just have people do the PIN entry the FBI would probably back down on that request. 3) Oh, you're absolutely right, it would take a great deal of additional effort to secure that code in the leaky sieve that's Apple's internal server infrastructure. I wouldn't want it to end up in the wild like the iOS, OSX and all the pro-app source code did (what, what?)

zaroth 11y ago
You may recall the PIN counter code was buggy the first time they wrote it. It took a patch release to ensure the counter would be incremented even if power was cut immediately after the invalid result was returned. This is part of what leads me to believe the security system which ensures the counter is incremented is non-trivial and therefore its removal may also be non-trivial due to cross-dependencies. You really think Tim and Dan are just going to let an engineer whip up a build with these features and sign it willy nilly with their production code-signing key, deploy it to the subject phone, and just start punching out PINs? If Apple hasn't already spent several man-years of engineering time on just investigation and tech support for this particular case I would be shocked. You claimed creating this build should be easier than a public release. From my perspective it's an order-of-magnitude harder, because it's a new process which must be developed and scrutinized from top to bottom and not a well-oiled machine. I've worked inside Apple, and this is not a negative reflection on the competency of their developers in any way. For Pete's sake, this backdoor isn't getting developed as a late-night hackathon! Of course we're just throwing speculative arguments past each other so it's not so productive. I think I know what I'm talking about, and so do you, but it doesn't really matter much either way :-/
- empressplay 11y ago
  I suspect that like most things the reality is somewhere in the middle.
- pps43 11y ago
  Changing "if (attempts > max_attempts)" to "if (false)" does not seem to be a big change. Same thing with increasing timeouts.

zaroth 11y ago

You may recall the PIN counter code was buggy the first time they wrote it. It took a patch release to ensure the counter would be incremented even if power was cut immediately after the invalid result was returned. This is part of what leads me to believe the security system which ensures the counter is incremented is non-trivial and therefore its removal may also be non-trivial due to cross-dependencies. You really think Tim and Dan are just going to let an engineer whip up a build with these features and sign it willy nilly with their production code-signing key, deploy it to the subject phone, and just start punching out PINs? If Apple hasn't already spent several man-years of engineering time on just investigation and tech support for this particular case I would be shocked. You claimed creating this build should be easier than a public release. From my perspective it's an order-of-magnitude harder, because it's a new process which must be developed and scrutinized from top to bottom and not a well-oiled machine. I've worked inside Apple, and this is not a negative reflection on the competency of their developers in any way. For Pete's sake, this backdoor isn't getting developed as a late-night hackathon! Of course we're just throwing speculative arguments past each other so it's not so productive. I think I know what I'm talking about, and so do you, but it doesn't really matter much either way :-/

empressplay 11y ago
I suspect that like most things the reality is somewhere in the middle.
pps43 11y ago
Changing "if (attempts > max_attempts)" to "if (false)" does not seem to be a big change. Same thing with increasing timeouts.