> > Just because that version worked a decade ago, it doesn’t mean it’s compatible with the world today.
> That's why I said you have to include this in your test procedures.
You can’t test the world. Even if your servers can correctly respond to requests from old software, it doesn’t mean that the network between you will too.
Networking surely does introduce complications especially when TLS is now basically considered required and cert lifetimes are being limited for 'security' reasons. However most consumer devices have functionality, often their primary/most important function, to which network connectivity isn't even needed. For instance, a speaker producing sounds.
In the factory reset state, things should have a USB flash drive firmware install route which could be used to bring back working root certs, etc.
Of course again this depends on whether the mfg is worried about DRM bypass hacks that are found later on in the factory firmware.
I'd support legislation to issue stiff fines for devices that can't be factory reset at any time, with the only exception being for directly-consumer-benefitting anti-theft (so, iCloud lock is okay).
But can’t you? Sure, factory firmware from many years ago might have issues, but should still work well enough to allow you to fully offline upgrade to a newer working version.
I think all the OP was saying, is: Suppose you’re releasing firmware version N for some widget you make. Now, for all versions V in (0..N-1), verify that applying N to V works correctly.
Reverting to factory state is the last resort. You don't have users do it unless there is no other good state to return to on the device.
> Just because that version worked a decade ago, it doesn’t mean it’s compatible with the world today.
That's why I said you have to include this in your test procedures.
When you're planning for the long term you can accommodate for these things on your servers.