I am not going to argue with you over the meaning of the term "back door." Disabling the limited number of tries, and disabling the time delay between tries will allow the phone to be "unlocked" through the "brute force" method, and a D@mn I do not give what people want to call it.
Let's see. To stop a loop from counting to 10? How many instruction changes would that require? How about "1."
To eliminate a time delay between tries? How many instruction changes would that require. Again i'll say "1."
Easy peasy.
Ah, first I dunno exactly what it takes to make any so called simple change. It all depends where in the system the change is made and what address space it shares with other routines, other threads, other processes, other kernels, yadayada, yes? And that might not still account for what could happen with interrupts... and yes, timer interrupts in particular...
I am a bit rusty but the timer that the user experiences could theoretically be implemented in several different ways depending on such things as the level and data space in which it (the timer code) operates. There could be unintended consequences. We prefer to think that there will not be any such consequences, but if we are wrong, then the consequences can come back and bite us in the butt. That is what system testing and reliability testing are all about. And even they don’t catch all the tiny but ultimately significant things that can bring down a system in a bad way at the wrong time and/or place. When was the last time you heard of a complex software project being delivered on time and on or under budget (and being 100% bug free)?
Beyond that I share concerns of many about bringing into life a software method of defeating a software mechanism whose sole stated, marketed, delivered and supported intention is to resist being defeated. That totally voids all the design, marketing, sales, and can open up a nightmare for support once the horse has left the barn. This simple code modification will already likely be the McGuffin of the next Mission Impossible sequel movie plot. It will be more valuable than plutonium and potentially just as dangerous (in the wrong hands).
I think we all need to take a deep breath, pause and step back a while to ponder whenever the government invokes some obscure law and uses it to demand unconditional compliance in a new venue. I’m probably not going to have time to read a 355 page Apple response tome filing. But by all accounts that I have seen, the government request seems overly broad. It should be more narrowly constrained at the very least to protect proprietary value, if granted at all. The government does not seem to feel obligated to balance Apple’s interests with its own at all. Should that not concern everyone? It is saying the equivalent of “you deal with the unintended consequences” to Apple. Well, Apple has lots of engineers and lots of lawyers and there seem as if there can be many unintended consequences. Why not hear Apple out? Why not reason with them? The government already admits it is an exceptional circumstance. Why such an openended order?
And is it true that the order was not signed by anyone? Maybe the actual order is a seperate document that is actually signed by the magistrate judge. It would then have a date of signing, signature, and date of implementation (yes?). Anyone see such a beast yet? (Just wondering.)