Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: