Posted by walterbell 5 days ago
If a wifi password is required to make full use of the device, I will return it.
If some users want to sacrifice security and privacy for "convenience", that's on them. But if you want to sell me the product, at least provide the option to decline without loss of functionality. Otherwise, no sale.
As an example, I refuse to buy a doorbell camera that doesn't support RTSP.
This is a good example of conflicting security requirements.
Not wanting the video to go to the cloud is fine, but most cameras with RTSP enabled allow any other device on the network to trivially get the camera stream, and sometimes also control the camera. This is why some camera companies require you jump through hoops to unlock RTSP - I don't like it but I can see why they do it.
This is one reason I've come to believe it's necessary that every device must see a totally different network universe from every other, able only to see the local controller server. (This is how I ended up playing with on AP video relays in my profile, as an effort to see what's involved). Things like multicast discovery is cool, but an absolute privacy and security disaster area.
Not a real concern when the network is fully under my control. I can easily restrict access as I see fit.
I surrender all control when I give up my wifi password and allow similar access to somebody's network located somewhere on the internet. Further access can be (and has been) granted to others without user knowledge or consent. For example:
https://arstechnica.com/tech-policy/2022/07/amazon-finally-a...
Sure. But this doesn't have to be an either/or choice.
It's possible to make it easy for those willing to surrender all privacy and control without making it impossible for those who don't.
Example: Amcrest cameras are just fine with being restricted to the local network. If you ask nicely and order direct, they'll even give you a discount.
My vision of how this should work can be inferred from https://github.com/atomirex/umbrella Essentially in the future wherever we have WiFi APs those should also be media SFUs (and probably MQTT brokers or similar) where each client will only see the AP and things the applications running on the AP have explicitly allowed, including streams piped opaquely from anywhere else.
The idea that being connected to WiFi means ability to see other devices and the public internet needs to stop being the default.
Right now domestic IoT and Home Assistant are like Windows Mobile and Symbian prior to the iPhone: proof that something interesting and useful is possible in the domain, but requiring an enthusiast level of investment in knowledge and time to maintain and operate.
Were I a billionaire I would be attempting to launch the Android (in the original intended sense) of IoT to solve that.
One might hope this to be the case, but there are mountains of evidence to the contrary.
>I'm not saying they are too stupid to figure out how
Never fear. I'm here to say it so that you don't have to. Most are too stupid.
China(up to now, now with tariffs stuff... who knows) has been exceptional in that they produced IoT devices for many use cases at very reasonnable prices. Want a water leak detector that's zigbee connected? that's only 5 bucks. if I want to buy one from a "western" company(still produced in china) it instantly gets marketed to a premium market and costs 10x or 20x more.
They have no incentive to make their products work in pure local when companies like Tuya provide SDKs, chips, and frameworks at a low price and easy entry barrier. But of course that locks into their ecosystem.
It's possible that a company making an open toolkit with easy integration for esp32/etc could gain enough traction to get many devices to use that, but at this point it's unlikely.
As for HA... I love it and run it locally, but it's not for the faint of heart. And spending dozens of hours modifying devices and configuration to get everything running is a priviledge few have the skills, time and knowledge to do.
As always... this is a case of "the only incentive is money and hence the system will lock itself".
Wouldn't it be great if the EU could force these companies to surrender local control?
This is one of my favourite uses of OpenWRT, or any other firmware that gives you proper control over the router - for WiFi-networked IoT devices, I set up a separate wireless network with no WAN/LAN access and client isolation. I can connect to the device, but it can't connect to WAN, any other devices on the IoT network, or my LAN.
Of course this won't work for cloud-tethered devices, but many will expose their functionality directly over network.
I just guess now and make sure the company has a good returns policy
The orange flag is when setup requests my wifi password.
But the big red flag for me is when configuration fails without unfettered WAN access. In this case, the product goes back in the box. If you allow this, you allow anything. Someone else effectively owns the device.
An easy test for this --- simply unplug your network from the WAN modem and see what happens.
By that logic, you will not buy any "smart" devices
A camera doorbell, in your example, need wifi password so that it can stream video.
A smart lightbuld need wifi connection to change brightness or color.
Without wifi connection, it will lose a part of functionality
Giving something wifi password is different from giving something internet access, they are not inclusive. You just add it to your local network without giving it internet access
In your case, does your smart bulb still have same functionality if you dont add it to your zigbee network ?
"MACsec (802.1AE) and EAPOL (802.1X)", https://forum.openwrt.org/t/macsec-802-1ae-with-802-1x-eapol...
There are protocols like zwave, zigbee, and possibly others that not only not need wifi passwords, they don't even need an IP address.
There are plenty of smart devices (including lighbulbs, sensor movements, and what not)t hat use bluetooh, or protocols like Zigbee that enable all kind of functionality without wifi password.
I feel like that is something that doesn’t or at least shouldn’t require a string of IoT devices, apps, wireless communication and hubs. Why not leave all of that out and just attach an air quality sensor to the air purifier and a small LCD to adjust the settings?
The light in my hallway turns on automatically when I walk past. No cloud, no HomeAssist, no WiFi, no Zigbee, no apps, no batteries to change. Just a motion sensor hardwired to the light fixture. Hasn’t failed me once in the past ten years. Works great even if the network goes down.
homeassistant allows you to perform follow on work or even long term analysis. For example the author could use the information to decide what times of day during which seasons are best for airing out the house (more popular in Europe than North America), or if air quality dips happen to coincide with their leaky clothes dryer spewing fibers and soap particles out into the home, or when they cook on their gas range, etc.
Some people just like to explore and discover. Low threat information is nice these days.
Funny you mention that, because I'm putting in smart movement sensors to make sure the lights don't come up at night in the garage where the dog sleeps, but also so that I can force the light on for a long period, when I'm doing some work in the same area. People have different needs/expectations.
A dumb device without leds/screens/connectivity that I can control with a smart plug via HA is much easier to deal with.
Give a man a fish, and you feed him for a day.
For owners of ESP32-based IoT devices:
Teach a man to fish, and you feed him for a lifetime.
blog author: https://x.com/jmswrnr
Edit: whoever downvotes this can rot in hell :D
I have just finished doing this and writing replacement firmware for the Aqara E1 series of Zigbee switches, after getting fed up with them not supporting basic Zigbee binding functionality.
I've done exactly this on my own air filter, and it's about 200 lines of config. The hardest part is mapping binary outputs to a percentage:
switch:
- platform: gpio
pin: GPIO21
id: fan_low
interlock_wait_time: 250ms
interlock: &interlock_group [fan_low, fan_mid, fan_high, fan_turbo]
- platform: gpio
pin: GPIO25
id: fan_mid
interlock_wait_time: 250ms
interlock: *interlock_group
- platform: gpio
pin: GPIO22
id: fan_high
interlock_wait_time: 250ms
interlock: *interlock_group
- platform: gpio
pin: GPIO17
id: fan_turbo
interlock_wait_time: 250ms
interlock: *interlock_group
output:
- platform: template
id: fan_speed_output
type: float
write_action:
- lambda: |-
id(fan_low).turn_off();
id(fan_mid).turn_off();
id(fan_high).turn_off();
id(fan_turbo).turn_off();
auto light = ((AddressableLight*)id(status_light).get_output());
for (int i = 6; i <= 9; i++) {
light->get(i).set(Color::BLACK);
}
if (state < 0.24) {
} else if (state < 0.26) {
id(fan_low).turn_on();
light->get(6).set(Color(255,0,0,0));
} else if (state < 0.51) {
id(fan_mid).turn_on();
light->get(7).set(Color(255,0,0,0));
} else if (state < 0.76) {
id(fan_high).turn_on();
light->get(8).set(Color(255,0,0,0));
} else {
id(fan_turbo).turn_on();
light->get(9).set(Color(255,0,0,0));
}
light->schedule_show();
fan:
- platform: speed
name: "Filter Speed"
output: fan_speed_output
speed_count: 4
id: my_fanEvery time I was part of a team designing IoT devices, there would be a slightly more security-focused engineer who would manage to have some level of protection for the boot. I'm surprised there was no resistance here to dump and reflash the firmware. Why would they not even bother encrypting the flash? How common is that?
It would have been nice to give the product name.
Some devices are purchased because their firmware is easy to replace. Upcoming regulations on IoT cybersecurity might make it harder to sell such devices. ESP32-based devices have been successful in several niches, https://hn.algolia.com/?query=esp32
re: the notes on the use of the device keys (stored in the K/V store), assuming that they are per device would seem the most obvious vs that they are global. Global keys would be written in the main app body in my experience, not the KV store (but that doesn't mean people have not done unusual things here of course!).
I also want to share some feedback on the complexity of managing per device keys these days and the risks - there are lots of easy to use tools that per device keys like this much simpler to do in 2025 than 2015 and cloud platforms that take in CSV files and return very similar messages... Typically a security model for a device such as an air purifier can be easily defined as not having device encryption enabled if it has per-device keys on as the impact of breaching a single device remains compartmentalized to a single edge component and in this case, just a purifier (vs a car or something that explodes!). Not that I agree with this, but corporate security can! Device encryption causes lots of problems in factories that are often best 'ignored' if the product can afford it.
Per another comment, god bless ESP32 developers once the EU rule kicks in in August... !
Wonder why the company didnt just go with a standardised solution - seems more cost effective than rolling their own!
In this case, it would have been pretty hard to create a certificate if you couldn't read the firmware.
But, also pretty impressed at the same time. I think this is the first Hacker News article I've read about an ESP32 IoT device which has any encryption at all.
You really went through the whole reverse engineering process end to end, I know that must have been a ton of work to not only reverse engineer it but also to write everything up!