3 ms·

I build stuff like that - my approach is to limit capabilities to the absolute minimum, and anything that is not needed for function but necessary for debug/dia

by Kliment 11y ago

I build stuff like that - my approach is to limit capabilities to the absolute minimum, and anything that is not needed for function but necessary for debug/diagnostics stays on the device rather than going across the network. This limits the devices a fair bit - firmware update across the network with no local interaction is not allowed, nor is accessing the local data store. Want to email me and talk about this?

collyw 11y ago
Which is exactly what a physical switch would do. No wireless internet, no GUI, just a switch.
- Kliment 11y ago
  Absolutely - and for a light switch it's appropriate. As an example of a thing that needs internet to function, consider a heater controller that has a high power and low power mode depending on momentary cost of electricity - it fetches price data across the network, and it's important to log things like temperature at various points of the device for diagnostics. Now, it's very tempting to send the diagnostic data across the network, but this leaks usage information. It's also tempting to allow things like remote configuration, firmware updates and reading device memory for debug, but that can leak network access credentials or make the device a beachhead for access to the internal network. This is why any feature like that is to be avoided and, if present, needs to be activated from the device itself, not remotely. If you NEED remote control, see if you can limit its scope of functionality to the bare minimum, and consider who needs access to it - in the case of the heater controller, the provider of the pricing data doesn't need to know or control the state of the device, so there's no need to allow that on that connection. Where possible, make the device a CLIENT rather than a SERVER - have the device itself initiate connections, to an address that is entered by local interaction, rather than accept connections from anywhere. If you MUST break those rules and accept connections from anywhere, that's when you really need to spend a fuckton of effort securing every aspect of your device, client applications, and protocol.

by Kliment 11y ago

collyw 11y ago

Which is exactly what a physical switch would do. No wireless internet, no GUI, just a switch.

Kliment 11y ago
Absolutely - and for a light switch it's appropriate. As an example of a thing that needs internet to function, consider a heater controller that has a high power and low power mode depending on momentary cost of electricity - it fetches price data across the network, and it's important to log things like temperature at various points of the device for diagnostics. Now, it's very tempting to send the diagnostic data across the network, but this leaks usage information. It's also tempting to allow things like remote configuration, firmware updates and reading device memory for debug, but that can leak network access credentials or make the device a beachhead for access to the internal network. This is why any feature like that is to be avoided and, if present, needs to be activated from the device itself, not remotely. If you NEED remote control, see if you can limit its scope of functionality to the bare minimum, and consider who needs access to it - in the case of the heater controller, the provider of the pricing data doesn't need to know or control the state of the device, so there's no need to allow that on that connection. Where possible, make the device a CLIENT rather than a SERVER - have the device itself initiate connections, to an address that is entered by local interaction, rather than accept connections from anywhere. If you MUST break those rules and accept connections from anywhere, that's when you really need to spend a fuckton of effort securing every aspect of your device, client applications, and protocol.