3 ms·
A mechanism requiring disclosure of how long security updates are available seems like a great step. Another great step would be a guarantee of making the firm
by JoshTriplett 3y ago
A mechanism requiring disclosure of how long security updates are available seems like a great step.
Another great step would be a guarantee of making the firmware Open Source after no more than a certain amount of time, and having that guarantee known at compile time. Effectively, that means the device will always be supportable.
- worthless-trash 3y ago> A mechanism requiring disclosure of how long security updates are available seems like a great step. So, as I work in this space, there needs to be realistic guidelines on this, does a security flaw need to have a CVE ? Do they need to fix every CVE ? What is the timeframe requirement ? This kind of thing keeps me up at night.
- SimingtonFCC 3y agoAnother great step would be a guarantee of making the firmware Open Source after no more than a certain amount of time, and having that guarantee known at compile time. Effectively, that means the device will always be supportable. It's not inconceivable that this could be a requirement for getting a label (or some tier of label.) It depends how the advocacy comes out on the record.
- kijin 3y agoThe requirement can be easily bypassed by going bankrupt before the required time is up. You will soon hear advice like "if you want to get in to the IoT space, create a new C Corp for each iteration of your product..." Whatever you require them to disclose after X years, it must be escrowed with a trusted third party in advance.
- JoshTriplett 3y agoAgreed: any kind of future disclosure requirement should be backed up by a source code escrow requirement.