3 ms·

This is also a key point to fighting ewaste and making devices last longer. I have appliances from the 70s including a rotary telephone, that I still use regula

This is also a key point to fighting ewaste and making devices last longer. I have appliances from the 70s including a rotary telephone, that I still use regularly. If you combined mandatory OSS support with repair cafes, you would have a model for sustainable reuse and better security. You may even start a commercial aftermarket in reflashing older devices!

phero_cnstrcts 3y ago
At rotary phones still compatible with todays standards? If that’s the case I might get one too.
- dpifke 3y ago
  It's been years since I've seen a landline, but as of a ~decade ago you could still dial "rotary" by tapping the receiver hook with the correct spacing. (1 click to dial a "1," 2 clicks to dial a "2," etc. with a pause between digits.)
- entropyie 3y ago
  In my case I use a small gadget to convert the pulses to DTMF tones, which feed into a voip connection. The point is that the device itself still works, unlike much iot crap which can't be made to work once the server goes down.
treyd 3y ago
Yeah if companies that make IoT hardware complain about the costs to keep old devices updated then they should be required to make them more user-modifiable and release source code / signing keys when they're abandoned by their manufacturer so that they can be picked up by the communities and development can be continued (also requires some policing to determine when hardware is functionally abandoned, as releasing a minor update once a year that doesn't fix real bugs should still be considered abandoned). Repair cafes would be fantastic for helping support small businesses keeping people's old hardware running. Of course, manufacturers don't want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.
- 1000100_1000101 3y ago
  Releasing Signing keys seems a potentially dangerous one. Someone could produce malicious firmware, sign it, and convince your device to auto-update with it. I think (and I'm a security know-nothing, so could very well be off in the weeds), the firmware should accept updates signed with two keys. The manufacturer key, which can allow automatic updates, and a post-service key that cannot be automatic. Either a user has to initiate the firmware update manually, or consent via some other means. This post-service firmware may very well enable a third key for automatic updates of its own, so there's just a manual step on the transition from manufacturer to some community project you support, not each revision afterwards.
  - treyd 3y ago
    Presumably they'd remove the auto-update functionality before releasing signing keys and require that it be physically loaded by a user at that point.
    - 1000100_1000101 3y ago
      That's assuming they make a final firmware update. Having the 2nd manual key available from day 1 ensures the device is unlockable with just a release of the key. Having a 2nd key or a signed unlock firmware update I guess are two ways to achieve the same goal, but the 2nd key would be better. The 2nd key likely stay in place forever, in each update, while the unlock firmware would likely end up remaining as the original firmware, because why would most vendors build two firmwares for each release. It would sit forgotten on a drive somewhere. The use of original unlock firmware could mean making a device vulnerable between loading the unlock firmware and the community firmware, so the 2nd key is preferred. It's always ready. Ideally, the key would also be pre-registered somewhere to ensure they can't skip out on releasing it, but I'm not sure how you do that without it potentially leaking before the device reaches end of support. I guess a code sitting in a lawyer's vault somewhere. Again, nobody is paying the lawyer to refresh his vault's firmware image after each patch, so 2nd key wins over unlock firmware again. Why a lawyer's vault? I know lots of people would love to take ownership of the device immediately, but from the device creator's perspective, they tend not to like that... especially if a device is a source of subscription revenue. So I'm not sure how you'd get vendor buy in to early release unless it becomes mandatory... which I can't see.

phero_cnstrcts 3y ago

At rotary phones still compatible with todays standards? If that’s the case I might get one too.

dpifke 3y ago
It's been years since I've seen a landline, but as of a ~decade ago you could still dial "rotary" by tapping the receiver hook with the correct spacing. (1 click to dial a "1," 2 clicks to dial a "2," etc. with a pause between digits.)
entropyie 3y ago
In my case I use a small gadget to convert the pulses to DTMF tones, which feed into a voip connection. The point is that the device itself still works, unlike much iot crap which can't be made to work once the server goes down.

treyd 3y ago

Yeah if companies that make IoT hardware complain about the costs to keep old devices updated then they should be required to make them more user-modifiable and release source code / signing keys when they're abandoned by their manufacturer so that they can be picked up by the communities and development can be continued (also requires some policing to determine when hardware is functionally abandoned, as releasing a minor update once a year that doesn't fix real bugs should still be considered abandoned). Repair cafes would be fantastic for helping support small businesses keeping people's old hardware running. Of course, manufacturers don't want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.

1000100_1000101 3y ago
Releasing Signing keys seems a potentially dangerous one. Someone could produce malicious firmware, sign it, and convince your device to auto-update with it. I think (and I'm a security know-nothing, so could very well be off in the weeds), the firmware should accept updates signed with two keys. The manufacturer key, which can allow automatic updates, and a post-service key that cannot be automatic. Either a user has to initiate the firmware update manually, or consent via some other means. This post-service firmware may very well enable a third key for automatic updates of its own, so there's just a manual step on the transition from manufacturer to some community project you support, not each revision afterwards.
- treyd 3y ago
  Presumably they'd remove the auto-update functionality before releasing signing keys and require that it be physically loaded by a user at that point.
  - 1000100_1000101 3y ago
    That's assuming they make a final firmware update. Having the 2nd manual key available from day 1 ensures the device is unlockable with just a release of the key. Having a 2nd key or a signed unlock firmware update I guess are two ways to achieve the same goal, but the 2nd key would be better. The 2nd key likely stay in place forever, in each update, while the unlock firmware would likely end up remaining as the original firmware, because why would most vendors build two firmwares for each release. It would sit forgotten on a drive somewhere. The use of original unlock firmware could mean making a device vulnerable between loading the unlock firmware and the community firmware, so the 2nd key is preferred. It's always ready. Ideally, the key would also be pre-registered somewhere to ensure they can't skip out on releasing it, but I'm not sure how you do that without it potentially leaking before the device reaches end of support. I guess a code sitting in a lawyer's vault somewhere. Again, nobody is paying the lawyer to refresh his vault's firmware image after each patch, so 2nd key wins over unlock firmware again. Why a lawyer's vault? I know lots of people would love to take ownership of the device immediately, but from the device creator's perspective, they tend not to like that... especially if a device is a source of subscription revenue. So I'm not sure how you'd get vendor buy in to early release unless it becomes mandatory... which I can't see.