Many of these WiFi-LED lamps contain esp8266 devices, which have a lot of open source alternative firmware available, like esphome[0] or tasmota[1]. You can reflash them by opening them & connecting a cheap (1$) usb-to-tty adapter.
If that isn't an option (for reasons like not wanting to permanently damage them or being afraid of electrical shocks) a lot of them come with tuya firmware, which you can (still) often exploit and convert with TUYA-CONVERT [2].
I found the Tasmota Device Templates Repository[3] to be a really valuable resource, although I've been using zigbee devices for lightbulbs.
I think I'm missing a few major points. I wonder if someone here might be able to clarify.
1. The real meat of this "pwning" was (it seems) a google search to identify the WEB API endpoint. Then it turns out that sending POST requests to this endpoint can turn the light on/off, change its temperature, and change its brightness.
2. In order to turn a light on/off using the "found" api, it is first necessary to connect to the lamp's network. So if I were doing this on my own linux machine, which cannot as far as I can tell connect to multiple wireless networks at the same time, my script to change the settings on the light would include disconnecting from my true wifi network, connecting to the lamp's network, sending the signal to the lamp, disconnecting from the lamp, and then reconnecting to my own network. Is that right? Is this what the bash scripts and apps mentioned in the post are doing?
3. If I lived in the apartment above the OP's (say), and I were malicious, I could even now also access the lamps' networks and, say, set their values to be whatever I wanted. And there is simply no way of stopping this (S in IoT, after all).
This is pretty much how I read it, but I thought maybe it's worse: I would bet that when you connect to the lamp's network and set it up to connect to your network as you should the lamp's internal WiFi ceases to broadcast, and you'd need the reset switch to enable setup again.
What this guy seems to have found out is possibly (and how, I don't know--the article is horribly lacking in detail) that the lamp accepts API calls /when it is in hotspot mode for setup/ as well as in HAZ_EXT_CONNECSHUN=1 mode
So what I think is that /anyone/ close to the lamp can send the API calls and affect it. Because the lamp is in perpetual setup mode with its unsecured hotspot active...
"A browser hitting that returned a page to connect the lamp to local WiFi. That is a no-go, so maybe there is a web API…" he said
the dumbass
e: Sorry, I misread your post on the lamp network part. I'll leave this here but now you know I spotted it. My apologies.
Yeah this is so far from pwning that it’s hilarious to be presented as such. This is literally authorized access. He built an integration for his smart bulbs the same way Google Home or HomeKit would access it but with some weird Wi-Fi paranoia that actually made him less secure.
The security model of pretty much all smart lighting "if you can reach me on the network you're trusted" just like the security of light switches "if you can reach the switch you can flip it."
One way to solve 3 and maybe 2 would be adding to the ecuation an ESP32/8266 and use it as an access point for the lamps. Then you might create any physical controls for the lamps or with some network magic add it to your infrastructure through a segmented network. I'm not sure if this can be done with an ESP alone (hence "network magic") or you could just use a second ESP connected to your private network and passthrough your commands via a serial port to the Lamp's ESP AP.
ESP32's are fairly cheap, easy to use and can even be programmed through micropython.
One thing I haven't seen mention much with these "smart" devices is how inconvenient lack of physical buttons is. Instead of just reaching over and adjust the volume/brightness whatever, I now have to unlock the phone, find the app and do some gestures to achieve same results, all of which now requires some mental bandwidth for these banal tasks.
That's just bad smart home planning. Any smart home device should work on top of existing physical control. Don't buy smart bulbs that require you to use your phone or voice to control them. Instead, buy smart switches that work just like normal wall switches but also give you smart home/automation possibilities (and work perfectly fine for guests or if the whole smart home system is down).
Don't buy some garage opener that requires internet access to control your garage, hook a smart relay into the existing garage opener.
Make sure there's a physical remote for your TV or sound system in addition to phone control. You can buy third party remotes just for this purpose.
Etc., etc., etc.
Pretty much any smart home project can be done in a way that keeps all physical control in place. Yes, it costs a little more and requires a little more work, but it's the only reasonable solution.
When your hands are occupied by cooking or some such, it's nice to bark orders at a voice assistant for timers, lighting adjustments, adding to the shopping list, etc.
I have a few 'smart' things in my house. One is my living room mood lights, but that's a combination of a simple RF plug relay switch on the one hand, and an ikea (also RF?) spot system, no internet required.
The other thing is my thermostat, where it's mainly convenience to control it remotely via my phone. I'm not comfortable with it, it has a dongle directly in my router giving the company behind it access to it and its data. I mean the charts are convenient, but I think the whole thing could be made offline as well. Anyway, that one has a simple screen (LED light matrix?) and touch buttons so anyone can adjust the temperature until the next time block, making just the unit without the app as useful as the old dial thermostat it replaced.
Final 'smart' thing I have is my wifi router, which I can manage via my phone; a big improvement over the old router/modem which had a very 2000's looking web interface.
I don't really mind having less buttons to accidentally push on my phone or other devices that go in my pocket, but I can't stand this when it comes to car dashboard interfaces. Thankfully I still drive a car from before this trend but in newer cars where e.g. changing the radio station requires fiddling with a touch screen. With physical buttons or knobs I can do this almost unconsciously, but with a touch screen I have to take my eyes off the road to even see what I'm poking on the screen.
With this kind of stuff, it always makes me wonder why it's there in the first place. Surely there's not much demand for touch screens in cars, and it must be more expensive to produce than analog buttons and knobs. Why has it become so ubiquitous?
This problem will depend on the vendors you buy your products from.
Having a few brands of smart home devices which are all compatible with homekit, I just swipe down on my lockscreen and have all of them as shortcuts in the single native interface or use my watch to operate them with voice.
Android seems to have the Google Home app for this exact same reason, but I have no idea how well that works.
I absolutely second this. "IoT" is a keyword to furnish up cheap hardware where the price of physical switches would have harmed the profit margin too much. This is not really ironic: Physical switches (with a price of probably 0,2 USD per component) are more expensive then SoC having Wifi implemented. Also it's cheaper to hire software-only developers to do as little hardware engineering as possible. It's all about cutting the price per unit down.
It probably costs more to add physical knobs/switches. They will end up taking more space/require more material to manufacture than the IoT device itself.
> Pretty sure that title was coined by Steve Gibson on his Security Now! podcast
In your source he explicitly says he does not know who the originator is.
> I don't know who the originator was because I saw it coming from several different sources over the past week. But I just love this. I mean, I liked the acronym IDIOT, I-D-I-O-T, which of course stands for I Don't Internet of Things. But I think even better is this slogan: "The 'S' in IOT Is for Security."
If you want to, you can turn it into a Home Assistant plugin (or even add it to the core). It's a great project that aims to provide this kind of interface for all kinds of "smart" devices in a user-friendly way.
I have found Home Assistant to be very user unfriendly and difficult to use. I have about $1000 in switches that are among the most popular Z-Wave devices on the market that I have not been able to get working, as well as other devices. I'm admittedly clueless with hardware, but I build software for a living. The few things that do work required hours of spelunking on forums into incomprehensible details of configuration. It's not a system I'd recommend to a typical consumer.
It's not that nobody heard of it, the problem is that it's not cheap to get stared since the devices are pretty expensive and you usually need to run wiring.
> It is administered by the KNX Association cvba, a non-profit organisation governed by Belgian law which was formed in 1999. The KNX Association had 443 registered hardware and software vendor members from 44 nations as at 1 July 2018. It had partnership agreements with over 77,000 installer companies in 163 countries and more than 440 registered training centres.[2] This is a royalty-free open standard and thus access to the KNX specifications is unrestricted.
It looks to me like it is competing with systems like Control4 in US since usually you want somebody to install and set it up for you.
Having said that I do believe that it is a good standard and I hope I will be able to implement it in my next home for the fundamental (must work) things like heating, blinds and lighting (maybe with DALI).
This is a great article explaining the need for open standards and non-proprietary approaches to IoT just like we have in the digital world. Vendor lock-in is a real issue for security and non-dependancy as well.
i took it as a google search, which made me laugh at how much I read before i got to the point. I enjoyed reading this post actually but there is very little meat to what actually happened.
IKEAs zigbee devices are cheap, realiable and accessible and works great with Home Assistant + the deCONZ usb dongle. No WiFi connected devices, not internet access. When I'm out of the house I "phone home" with a VPN to adjust the temperature and turn off the lights if I forgot. I have automated several basic things, like the color temperature of the lights and the temperature of my heaters when electricity prices spikes.
Unfortunately this is not really accessible for regular consumers, only for nerds who know their way around a terminal and vi(m).
Another problem: Even when the device is working as it should, there needs to be a "lock" mode that says, "don't download new firmware." Nothing like having your smoothly-functioning lighting setup FUBARed by an unnecessary and buggy firmware update - especially if you're far away from home when it happens.
I imagine it's mentioned elsewhere in this commentary, but the key point I think this chap missed was not connecting to a wifi network under his control.
"A browser hitting that returned a page to connect the lamp to local WiFi. That is a no-go ..."
You can buy prosumer routers nowadays for $99 USD which enable one to setup different subnets and VLANS such that a device is accessible on the network but unable to access the internet.
I'm not afraid of IoT like some other tinfoil types commenting here - just make sure they can't call home (I'm looking at you Samsung TV)
Software needs to be updated though, certificates need to be checked and all that. That's only possible with Internet - unless you run your own CA, Package Mirror on the local network. That said, there is also a trade off between having a having ports open for REST vs. having a gateway (whether that's on the local network or on the Internet). Also it's probably a difference whether one plans to update the installed system every now and then or whether that should be fully automated...
This is true, but honestly I have almost never seen an IoT device getting updated for security reasons - instead they seem to update things OTA to just add more crap to it.
In any case, a CA lasts ~20-30 years. Hopefully the IoT device will be dead by then
Can you believe Generac standby generators need you to download an app and receive an activation code which no doubt you key into the generator before it will work. I nearly got caught out with this when we were looking to replace our cottage genny. We don't have internet access how stupid a concept is this. Thankfully I found out before completing the purchase so I bought a different brand but I'm with this guy all the way. I'm not connecting my lightbulbs, toaster or intelligent microflushing loo to anything internet just to use the product.
Chipset developers like Silicon Labs* are developing very advanced but approachable security capabilities into their latest products (secure boot, secure debug, physical protection (DPA countermeasure, anti-tamper), key management, key storage, crypto engine, etc.)*.
The tools are there now to address this, and this should go a long way toward actually securing the application, the data, the IP, and overall simplify lifecycle management.
Unfortunately I've often found these capabilities end up being used against users as much as, if not vastly more than, they are used in their favour.
For example, secure boot and anti-tamper measures are often used to lock out users from being able to examine or modify equipment and software for their own benefit. Sure, these measures can be argued as ways to "protect" the user from themselves (preventing inadvertent/unsupported changes of hardware causing malfunction, or preventing the installation of malware, and so on), but to rob the users of their agency to decide what's best for themselves in these circumstances is fundamentally disrespectful.
Nonetheless, I hope your employer is in a position to be part of a movement to buck the trend here, but based on what I've seen in the industry over the years, I've learned to be very skeptical whenever I hear of such "security" capabilities being thrown around as universally beneficial for everyone.
The issue here isn't hardware capabilities, it's that vendors like to make their gadgets centrally connected for convenience and analytics and then on top often don't care about hygiene (e.g. no crypto at all).
Would it only allow for the lamp to be "secure" in the sense that the owner would not be able to take back control anymore? If that's the case, that's a "solution" worse than the problem, that's even unethical as hell given this will short/medium term accelerate the ecological nightmare.
I don't care how "secure" one can make an internet-connected lamp. I don't want or need a lamp to connect to the internet to change its operating conditions. The problem is that we, as a society, are being so suckered by cheap consumer devices that it's becoming difficult to even FIND NON-connected devices in some categories. Like the lamp in the article, I'm willing to bet that he looked for something with purely physical controls, and couldn't find one in a comparable price point. I honestly don't get it. I can't fathom what some company could possibly be doing with my usage data from some internet-connected LAMP, or why they would go about designing all the infrastructure to make it work. It would be orders of magnitude more easy to just put some buttons on the side of the unit. At this point, I guess someone out there thinks, "Oh, neat!" but this sort of situation is paving the way for it to be impossible to buy ANY consumer electronic device that doesn't phone home in the very near future.
Shameless plug:
We are working on the solution! Our motto is actually "Put the S into IoT" :D by working with security researchers on an automated tool which can scan and find vulnerabilities in all kinds of IoT firmwares. Check it out: https://www.iot-inspector.com/
Our old UI is "not very nice", but we already have a GraphQL API and pretty UI very soon.
If you are a security researcher or IoT shop, you should contact us!
AppleTV Airplay kind of fits this for me. Maybe it's secure, but, and MacOS Big Sur surfaced this for me. I click the screen sharing icon on my Mac and my 2 shares show up. I go to select the one I always select, asynchronously MacOS scans for more Airplay receivers. It finds my neighbors and adds them sorted alphabetically to the menu in real time. Result, 50-70% of the time I click the AirPlay device for another apartment since by sorting the list the positions change under my mouse. I've learned to click the screen share menu, then wait about 3 seconds for my neighbors' devices to appear, since the position of the device I want to click will move.
But, here's the thing. AFAIK a display pops up on my neighbor's TV showing a code I'm supposed to type into my Mac. Further, AFAIK, if the TV was off the device (usually an AppleTV) will turn on the TV on via HDMI. So, I've possibly interrupted my neighbors viewing. Or if it's late at night I just turned on their TV (no idea if it shuts it self off).
I know Apple has this feature to make it zero configuration but I'm not convinced it's the best feature. I've thought about figuring out how to send the same packets and building a small device/app that tries to connect to every Airplay device constantly. Then I could drive around the Apple campus and interrupt meetings.
Or, I could just put the app on my phone and walk around and hope that Apple will get enough complaints from users about "why does this code keep popping up on my TV" until Apple fixes the issue.
I think the issue is that the AppleTV uses Bluetooth as an extra communication channel to setup a session and you can turn it off but I suspect most users have not.
Is that a security issue that I can turn on my neighbors TVs and AppleTVs remotely?
I don't see a veil on a blog post where the author's name and CEO position in the company is the first thing you see.
Sure you can argue Purism won't exactly publish something that doesn't agree with their marketing, but at the same time I prefer seeing a blog post than some other product page on here. And they're not the only one, in fact right now the very top post on HN is a blog entry by Mozilla about a new feature in their product.
Let's be thankful that they are, in fact, using ESP32 for a central control chip and use a very simple REST protocol. It could be a lot worse, a lot more proprietary.
These are simple devices, but expensive as far as lights go. You can very easily get dumb lights that have only physical controls. For a lot cheaper too.
IoT runs across a range of use cases and connections. There is a lot of emphasis on WiFi IoT applications, but this makes things hard in other places.
I'm working on various IoT sensor products that require a cellular connection - NB-IoT is preferred for this use case due to the good penetration characteristics. But the problem is that UDP is recommended as the NB-IoT transport layer due to the problem with TCP ack timeouts due to NB-IoT latency. That means that you are practically reduced to MQTT-SN as a data protocol, which in turn means you lose TLS.
There are partial solutions - we whitelist our MQTT data sources (i.e. only the Cellular provider's NB-IoT gateway), and we can verify and whitelist the IDs of all connected devices). But it is a partial and imperfect solution.
[+] [-] danhor|5 years ago|reply
If that isn't an option (for reasons like not wanting to permanently damage them or being afraid of electrical shocks) a lot of them come with tuya firmware, which you can (still) often exploit and convert with TUYA-CONVERT [2].
I found the Tasmota Device Templates Repository[3] to be a really valuable resource, although I've been using zigbee devices for lightbulbs.
[0]https://esphome.io/
[1]https://github.com/arendst/Tasmota
[2]https://github.com/ct-Open-Source/tuya-convert
[3]https://templates.blakadder.com/index.html
[+] [-] mixedmath|5 years ago|reply
1. The real meat of this "pwning" was (it seems) a google search to identify the WEB API endpoint. Then it turns out that sending POST requests to this endpoint can turn the light on/off, change its temperature, and change its brightness.
2. In order to turn a light on/off using the "found" api, it is first necessary to connect to the lamp's network. So if I were doing this on my own linux machine, which cannot as far as I can tell connect to multiple wireless networks at the same time, my script to change the settings on the light would include disconnecting from my true wifi network, connecting to the lamp's network, sending the signal to the lamp, disconnecting from the lamp, and then reconnecting to my own network. Is that right? Is this what the bash scripts and apps mentioned in the post are doing?
3. If I lived in the apartment above the OP's (say), and I were malicious, I could even now also access the lamps' networks and, say, set their values to be whatever I wanted. And there is simply no way of stopping this (S in IoT, after all).
[+] [-] porbelm|5 years ago|reply
What this guy seems to have found out is possibly (and how, I don't know--the article is horribly lacking in detail) that the lamp accepts API calls /when it is in hotspot mode for setup/ as well as in HAZ_EXT_CONNECSHUN=1 mode
So what I think is that /anyone/ close to the lamp can send the API calls and affect it. Because the lamp is in perpetual setup mode with its unsecured hotspot active...
"A browser hitting that returned a page to connect the lamp to local WiFi. That is a no-go, so maybe there is a web API…" he said
the dumbass
e: Sorry, I misread your post on the lamp network part. I'll leave this here but now you know I spotted it. My apologies.
[+] [-] Spivak|5 years ago|reply
The security model of pretty much all smart lighting "if you can reach me on the network you're trusted" just like the security of light switches "if you can reach the switch you can flip it."
[+] [-] sdlion|5 years ago|reply
ESP32's are fairly cheap, easy to use and can even be programmed through micropython.
[+] [-] shp0ngle|5 years ago|reply
[+] [-] DarkCrusader2|5 years ago|reply
[+] [-] mason55|5 years ago|reply
Don't buy some garage opener that requires internet access to control your garage, hook a smart relay into the existing garage opener.
Make sure there's a physical remote for your TV or sound system in addition to phone control. You can buy third party remotes just for this purpose.
Etc., etc., etc.
Pretty much any smart home project can be done in a way that keeps all physical control in place. Yes, it costs a little more and requires a little more work, but it's the only reasonable solution.
[+] [-] hunter2_|5 years ago|reply
[+] [-] Cthulhu_|5 years ago|reply
The other thing is my thermostat, where it's mainly convenience to control it remotely via my phone. I'm not comfortable with it, it has a dongle directly in my router giving the company behind it access to it and its data. I mean the charts are convenient, but I think the whole thing could be made offline as well. Anyway, that one has a simple screen (LED light matrix?) and touch buttons so anyone can adjust the temperature until the next time block, making just the unit without the app as useful as the old dial thermostat it replaced.
Final 'smart' thing I have is my wifi router, which I can manage via my phone; a big improvement over the old router/modem which had a very 2000's looking web interface.
[+] [-] _peeley|5 years ago|reply
With this kind of stuff, it always makes me wonder why it's there in the first place. Surely there's not much demand for touch screens in cars, and it must be more expensive to produce than analog buttons and knobs. Why has it become so ubiquitous?
[+] [-] cube2222|5 years ago|reply
Having a few brands of smart home devices which are all compatible with homekit, I just swipe down on my lockscreen and have all of them as shortcuts in the single native interface or use my watch to operate them with voice.
Android seems to have the Google Home app for this exact same reason, but I have no idea how well that works.
[+] [-] ktpsns|5 years ago|reply
[+] [-] soheil|5 years ago|reply
[+] [-] sebastien_b|5 years ago|reply
[1]https://www.grc.com/sn/sn-586.htm
[+] [-] ullevaal|5 years ago|reply
In your source he explicitly says he does not know who the originator is.
> I don't know who the originator was because I saw it coming from several different sources over the past week. But I just love this. I mean, I liked the acronym IDIOT, I-D-I-O-T, which of course stands for I Don't Internet of Things. But I think even better is this slogan: "The 'S' in IOT Is for Security."
[+] [-] driverdan|5 years ago|reply
[+] [-] monocasa|5 years ago|reply
[+] [-] outadoc|5 years ago|reply
https://github.com/home-assistant/
[+] [-] hirundo|5 years ago|reply
[+] [-] throw080700|5 years ago|reply
https://en.wikipedia.org/wiki/KNX_(standard)
This classic talk - Learn how to control every room at a luxury hotel remotely (2015) [has eng subtitles]:
https://www.youtube.com/watch?v=RX-O4XuCW1Y
[+] [-] gog|5 years ago|reply
> It is administered by the KNX Association cvba, a non-profit organisation governed by Belgian law which was formed in 1999. The KNX Association had 443 registered hardware and software vendor members from 44 nations as at 1 July 2018. It had partnership agreements with over 77,000 installer companies in 163 countries and more than 440 registered training centres.[2] This is a royalty-free open standard and thus access to the KNX specifications is unrestricted.
It looks to me like it is competing with systems like Control4 in US since usually you want somebody to install and set it up for you.
Having said that I do believe that it is a good standard and I hope I will be able to implement it in my next home for the fundamental (must work) things like heating, blinds and lighting (maybe with DALI).
[+] [-] markild|5 years ago|reply
[+] [-] 1cvmask|5 years ago|reply
[+] [-] schnable|5 years ago|reply
A brief search of what?
[+] [-] sigmonsays|5 years ago|reply
[+] [-] johanbcn|5 years ago|reply
[+] [-] codazoda|5 years ago|reply
[+] [-] durnygbur|5 years ago|reply
[+] [-] messo|5 years ago|reply
Unfortunately this is not really accessible for regular consumers, only for nerds who know their way around a terminal and vi(m).
[+] [-] flyinghamster|5 years ago|reply
[+] [-] astrea|5 years ago|reply
[+] [-] mafro|5 years ago|reply
"A browser hitting that returned a page to connect the lamp to local WiFi. That is a no-go ..."
You can buy prosumer routers nowadays for $99 USD which enable one to setup different subnets and VLANS such that a device is accessible on the network but unable to access the internet.
I'm not afraid of IoT like some other tinfoil types commenting here - just make sure they can't call home (I'm looking at you Samsung TV)
[+] [-] blablabla123|5 years ago|reply
[+] [-] denysvitali|5 years ago|reply
In any case, a CA lasts ~20-30 years. Hopefully the IoT device will be dead by then
[+] [-] lrvick|5 years ago|reply
I even run tuya-convert to switch over my dozens of light bulbs.
Anything that can't run open firmware I control doesn't get to live on my internal LAN.
[+] [-] 1023bytes|5 years ago|reply
[+] [-] drivinmecrazy|5 years ago|reply
[+] [-] djcooley|5 years ago|reply
The tools are there now to address this, and this should go a long way toward actually securing the application, the data, the IP, and overall simplify lifecycle management.
* - disclaimer, I am an employee * - https://www.silabs.com/security
[+] [-] ls65536|5 years ago|reply
For example, secure boot and anti-tamper measures are often used to lock out users from being able to examine or modify equipment and software for their own benefit. Sure, these measures can be argued as ways to "protect" the user from themselves (preventing inadvertent/unsupported changes of hardware causing malfunction, or preventing the installation of malware, and so on), but to rob the users of their agency to decide what's best for themselves in these circumstances is fundamentally disrespectful.
Nonetheless, I hope your employer is in a position to be part of a movement to buck the trend here, but based on what I've seen in the industry over the years, I've learned to be very skeptical whenever I hear of such "security" capabilities being thrown around as universally beneficial for everyone.
[+] [-] tpolzer|5 years ago|reply
[+] [-] temac|5 years ago|reply
[+] [-] TheRealDunkirk|5 years ago|reply
[+] [-] kissgyorgy|5 years ago|reply
Our old UI is "not very nice", but we already have a GraphQL API and pretty UI very soon.
If you are a security researcher or IoT shop, you should contact us!
[+] [-] asiachick|5 years ago|reply
But, here's the thing. AFAIK a display pops up on my neighbor's TV showing a code I'm supposed to type into my Mac. Further, AFAIK, if the TV was off the device (usually an AppleTV) will turn on the TV on via HDMI. So, I've possibly interrupted my neighbors viewing. Or if it's late at night I just turned on their TV (no idea if it shuts it self off).
I know Apple has this feature to make it zero configuration but I'm not convinced it's the best feature. I've thought about figuring out how to send the same packets and building a small device/app that tries to connect to every Airplay device constantly. Then I could drive around the Apple campus and interrupt meetings.
Or, I could just put the app on my phone and walk around and hope that Apple will get enough complaints from users about "why does this code keep popping up on my TV" until Apple fixes the issue.
I think the issue is that the AppleTV uses Bluetooth as an extra communication channel to setup a session and you can turn it off but I suspect most users have not.
Is that a security issue that I can turn on my neighbors TVs and AppleTVs remotely?
[+] [-] edf13|5 years ago|reply
[+] [-] alpaca128|5 years ago|reply
Sure you can argue Purism won't exactly publish something that doesn't agree with their marketing, but at the same time I prefer seeing a blog post than some other product page on here. And they're not the only one, in fact right now the very top post on HN is a blog entry by Mozilla about a new feature in their product.
[+] [-] ShakataGaNai|5 years ago|reply
Let's be thankful that they are, in fact, using ESP32 for a central control chip and use a very simple REST protocol. It could be a lot worse, a lot more proprietary.
These are simple devices, but expensive as far as lights go. You can very easily get dumb lights that have only physical controls. For a lot cheaper too.
[+] [-] steve_gh|5 years ago|reply
I'm working on various IoT sensor products that require a cellular connection - NB-IoT is preferred for this use case due to the good penetration characteristics. But the problem is that UDP is recommended as the NB-IoT transport layer due to the problem with TCP ack timeouts due to NB-IoT latency. That means that you are practically reduced to MQTT-SN as a data protocol, which in turn means you lose TLS.
There are partial solutions - we whitelist our MQTT data sources (i.e. only the Cellular provider's NB-IoT gateway), and we can verify and whitelist the IDs of all connected devices). But it is a partial and imperfect solution.
Security is hard...