Nicely done, assuming it works (without unintended consequences). I'm an AAPL stockholder, as well as an occasional user. I'm not particularly for or against Apple, other than their stock price. But this seems a fairly elegant solution for the problem.
Yes, this is what some of us suggested earlier - disable the fingerprint access if it fails the security checks, but the phone should be left operational otherwise.
edit/add: I'm also glad to see that Apple is resolving this, rather than a bunch of lawyers make $$$$ while the affected parties get a $5 discount coupon.
further edit/add: I don't think this fix is deserving of the adjective 'elegant'. I'd say it was the obvious fix, and how it should have been from the start. If you read between the lines from Apple, it appears that they now admit the error53 was an unintended result of their internal test/verification code, and that it should have acted as described - disable the fingerprint access, but continue to work normally otherwise.
Minor point, but - I'll also say that this definition of 'bricked' does not match the one I'm used to hearing. When we spoke of a 'bricked' device, it was a goner. Not something that could be revived from software. Depending on how big a deal security was on the device, you might not even to be able to revive it with a hardware swap out of a component - the secure boot code would see a mismatch with other components on the board, and abort. Only if you replaced
all involved components (CPU, RAM, ROM, key I/O), and then started it in the mode that allowed it to learn all its related keys (or maybe these were one-time-programmed - I'm fuzzy on the details now, and this was a while ago), could you revive that board. But it was easier to scrap it and start with a new one at that point. It wouldn't retain any of its previous data, so really not much point in it.
I wonder if MP still feels this action from Apple is a security risk (post #40 & #43)?
-ERD50