the previous owner's Apple ID (usually an e-mail address) and "infinite access token" if "Back to My Mac" had been enabled,
IMHO this is really the only concerning part because it sounds like something that can be remotely exploited; knowing the wireless network name and key is only worth anything if you know where that network is, and can actually go there and do something.
a "factory-default" reset just moves the configuration file to a new location on the device, and the old file and up to two additional previous configurations remain accessible on the device.
When doing a factory reset, repeat the process at least three additional times to cycle the data out of ACPData.bin.3.
That sounds like a "last known good configuration(s)" feature to handle the inevitable "I thought I'd reset it because it wasn't working, and now nothing works anymore!" but perhaps the feature was never fully implemented due to other factors.
How crazy, I quite literally just performed this update. (As in: to test the network post update I went to HN, where I saw this post)
Before updating, I questioned whether I should even bother applying the update, but figured better safe than sorry in case it contained some important security patches. Glad I did!
> During our investigation, our team uncovered a workaround that allows users to fully erase the device by repeating the factory default reset process four times.
That sounds like an interesting behavior to debug.
FTA, it sounds like the firmware’s original behavior was to save the three most recent configurations as backups, so it seems straightforward that four resets would have the effect of actually wiping a current config.
Why did it take ten months to apply a (what I presume is reasonably simple) change to the firmware reset functionality? All they needed to do was wipe the config backup files when a user factory resets their device and unset a bunch of variables.
A company with as much resources as Apple should not be given this much time before publication. A Project Zero-like 90 days grace period should be fine, especially as you need either physical or SSH access to such a device.
I know Apple tries to make people who report bugs stick to their procedures and agenda but taking over 300 days to roll out a patch for a product that was not seeing any active development regardless? That's quite a lot of patience to keep.
I don't disagree, but keep in mind that the entire AirPort product line was publicly discontinued three months before the author reported the problem. I wonder how many other consumer companies would've bothered with a patch at all?
I wonder how many other consumer companies would've bothered with a patch at all?
Microsoft would have.
For example:
Microsoft is planning to end support for Windows 10 Mobile devices in December. While Microsoft revealed back in 2017 that the company was no longer developing new features or hardware for Windows 10 Mobile, security and software updates have continued. These security updates will now cease on December 10th 2019...
Microsoft definitely would have, but they have so many enterprise customers for those products that it’s not really a choice; they always plan for LTS.
I was thinking more along the lines of e.g. Sony. There are tons of consumer devices that no longer get updates after they’ve been withdrawn from the market.
The Wireless team has been reorganized, but they have still been pushing out updates for AirPort routers. It seems like they delayed the release of the fix in this case based on the language used in the responses Apple gave.
IMHO this is really the only concerning part because it sounds like something that can be remotely exploited; knowing the wireless network name and key is only worth anything if you know where that network is, and can actually go there and do something.
a "factory-default" reset just moves the configuration file to a new location on the device, and the old file and up to two additional previous configurations remain accessible on the device.
When doing a factory reset, repeat the process at least three additional times to cycle the data out of ACPData.bin.3.
That sounds like a "last known good configuration(s)" feature to handle the inevitable "I thought I'd reset it because it wasn't working, and now nothing works anymore!" but perhaps the feature was never fully implemented due to other factors.