5 ms·

Have you ever shipped large complicated software? Even simple changes take a lot of time. For example the recent error 53 bug, in theory all they had to do was

by rblatz 11y ago

Have you ever shipped large complicated software? Even simple changes take a lot of time. For example the recent error 53 bug, in theory all they had to do was roll back a commit. But it still took weeks to get it out.

empressplay 11y ago
For publicly-shipped software sure, but we're not talking about that. We're talking about what is effectively a test build on a device that would be in Apple's possession. Different kettle of fish, isn't it? Edit: Another developer here thinks there's probably a developer soft-switch to disable the 10-strikes feature anyway; if that's true then it's even more trivial?
- zaroth 11y ago
  Because if Apple somehow is compelled to create the functionality, but then fucks it up and the device gets wiped, that'll go down just wonderfully. So yeah, they'll just load up a quick build off a development machine and start entering PINs and hope it works! The creation of this backdoor would likely rank as one of the highest pressure coding events in the security engineering groups lives. Yeah, they'll just whip that up in no time. Anyone who codes these secure systems would reasonably estimate the perfectly safe removal of all these security features combined with adding an automated PIN entry system, and then lets not forget the creation of a secure environment to isolate this code from any possible misuse... somewhere on the order of man-years to develop, test, document, and deploy. Much can be done in parallel, so it's on the order of a team of 6 - 10 engineers working for at least two to three months straight.
  - empressplay 11y ago
    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.

by rblatz 11y ago

empressplay 11y ago

For publicly-shipped software sure, but we're not talking about that. We're talking about what is effectively a test build on a device that would be in Apple's possession. Different kettle of fish, isn't it? Edit: Another developer here thinks there's probably a developer soft-switch to disable the 10-strikes feature anyway; if that's true then it's even more trivial?

zaroth 11y ago
Because if Apple somehow is compelled to create the functionality, but then fucks it up and the device gets wiped, that'll go down just wonderfully. So yeah, they'll just load up a quick build off a development machine and start entering PINs and hope it works! The creation of this backdoor would likely rank as one of the highest pressure coding events in the security engineering groups lives. Yeah, they'll just whip that up in no time. Anyone who codes these secure systems would reasonably estimate the perfectly safe removal of all these security features combined with adding an automated PIN entry system, and then lets not forget the creation of a secure environment to isolate this code from any possible misuse... somewhere on the order of man-years to develop, test, document, and deploy. Much can be done in parallel, so it's on the order of a team of 6 - 10 engineers working for at least two to three months straight.
- empressplay 11y ago
  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.