> he soon discovered that the same credentials that allowed him to see and control his own device also provided access to live camera feeds, microphone audio, maps, and status data from nearly 7,000 other vacuums across 24 countries.
This is extremely similar to what I accidentally discovered and disclosed about Mysa smart thermostats last year: the same credentials could be used to access, inspect, and control all of them, anywhere in the world.
The "smart" thermostat stuff is scary. I have Haier minisplits in my house and they have some "smarts" built into each head unit. The way it works from the user's perspective is you connect to the device in the GE Home app via Bluetooth, enter your WiFi network's credentials, then the minisplit joins your wifi network and phones home to GE Cloud. Then your GE Home app can monitor and control your minisplit via GE Cloud.
I haven't done anything to analyze it further, instead after trying that out once I promptly changed my WiFi password and never looked back. The long term solution will involve some ESP32s, AHT20 temp/humidity sensors, and IR rx/tx.
But it just occurred to me reading this that if there's a similar vulnerability in HVAC system controls an attacker could cause one hell of an unanticipated power demand spike.
This is honestly why it's important to insist on Z-wave or Zigbee if you don't have control over the device firmware and must have smart controls. Why people don't seem to understand now that if it's "WiFi" it's suspect at best, I'll never understand.
The ideal setup is having a separate vlan for your IoT things, that has no internet access. You then bridge specific hubs into it, so the hubs can control them and update their firmware.
If you have IoT devices that are unsafe but cannot be updated any other way, you can temporarily bridge the IoT VLAN to WAN.
Honestly, what IoT stuff needs is something similar to LVFS. Make it so all the hubs can grab updates from there, and can update any IoT device that supports Matter. It would also serve as a crapware filter because only brands that care about their products would upload the firmwares.
None of the existing smart controls stuff I've found really does it for me. I'm trying to build a hybrid heating system with 4 hydronic zones and 8 minisplits. For my HVAC controls the design is converging to a round mechanical Honeywell thermostat for each hydronic zone with a "smart" thermostat (no cloud) wired in parallel--TBD whether buy vs build. For the minisplits I'm building my own thing that can speak their IR protocol, which will also double as a per-room temperature sensor. It all gets tied together with outdoor temp sensor via HomeAssistant. So if all the "smart" stuff fails, the trusty mechanical guy will keep the house from freezing.
There are halfway decent hybrid controls available for ducted systems but you can't afaik buy anything off the shelf to merge hydronic + minisplits. And as far as I can tell, none of the off-the-shelf smart thermostats has any built in analog backup. I view that as absolutely critical for my use, if the power goes out and I'm not around I need to be 100% certain that when the power comes back on the heat will also.
EDIT: Digging around a little more it seems that Mitsubishi H2i minisplit systems don't speak zwave or zigbee, neither does Haier Arctic. I'm not 100% sure if that's accurate, but I haven't been able to find any documentation in the affirmative or negative. Those are the two heat pump options available locally. I'll be remodeling a small barn into an ADU this summer, that project will be more amenable to a forced air hybrid system, so maybe I'll be able to get away with a Honeywell smart zigbee capable thermostat that can drive it.
The vulnerability was in their backend cloud structure. The backend wasn't restricting access to only devices associated with your account.
> Out of sheer laziness, I connected to the Mysa MQTT server and subscribed to the match-everything wildcard topic, #. I was hoping I’d see messages from a few more MQTT topics, giving me more information about my Mysa devices.
> Instead, I started receiving a torrent of messages from every single Internet-connected production Mysa device in the whole world.
The devices had unique IDs, but they were all connected to one big MQTT pub/sub system that didn't even try to isolate anything.
It's lazy backend development. This happens often in IoT products where they hire some consultant or agency to develop a proof of concept, the agency makes a prototype without any security considerations, and then they call it done because it looks like it works. To an uninformed tester who only looks at the app it appears secure because they had to type in their password.
Not sure why this is being downvoted, it's a pervasive flaw across all these IoT products. See my description elsewhere here about how Haier "smart" controls work. It's completely insane, and pointless. For systems that can't fail--I include heating systems in the winter--this kind of "move fast and break shit" way of doing it is malpractice. The last thing in the entire world I want my furnace controls doing is an automatic OTA firmware update. Ever.
I think it's about being a configuration management nightmare. If every device has a unique password, you need the decoder ring for serial number to password. However, not all processors have unique IDs. So you either need to find a way to reliably serialize each board during manufacturing and hope it stays (like a sticker/laser/printer/etc) or add a serial number chip which is cost and complexity. It's not impossible, it's just extra work that usually goes unrewarded.
I'm a long way from embedded development. But I was under the impression a lot of microcontrollers these days have some ID capability built in, even some relatively low-end ones. This strikes me more as laziness than anything.
This is true, for example many stm32 series have a 96 bit unique id which is derived from the lot number, wafer id and position [1]. Even the low cost stm32g0b1 series I am using has them, but they are missing from some older series.
Moreover, on any device that is connected to Internet you already have a unique MAC address on its Ethernet or WiFi interface.
You can hash this unique MAC address, together with other data that may be shared with the other devices of the same kind, to generate unique keys or other kinds of credentials.
Surprisingly it's not everywhere. I'm very in embedded development and cannot count the amount of time I look for "unique" "id" etc in a reference manual and come up short. It's certainly more common than not, but you often have to design systems for the lowest common denominator.
It is indeed. And that sucks but that's what it is. Product design is about calculated risks and trades. It's a good thing regulators are here to help because companies won't do it on their own and the general public doesn't care enough.
I have not knowledge of this kind of software dev/hw production, so can you please explain why the units cant just be born with a default pass and then have the setup process (which is always there) Force the owner to set a new password?
Knowledge or not, this..
> It's not impossible, it's just extra work that usually goes unrewarded.
.. is just not an acceptable way for business to think and operate i 2026, especially not when it comes to internet connected video enabled devices
I'll answer your question with a question: how often do you see people complaining about needing setup processes vs the old way of just plug and play? There's no perfect answer that placates all sides. Things can certainly be better, but when those people win and you no longer need to have a setup process, then what?
While true that in $current_year it would be nice if things were more secure, the sad truth is that most people don't care.
I agree that yes most just want PnP and basically don’t care about security. But it seemed on the posts above that there was an engineering complexity,
and a robot vaccum needs local WiFi, so there will be a setup flow. Whats preventing a password selection
just be part of that?
Due to the wonders of technology, you can now do the equivalent of the Steven Wright joke:
“In my house there's this light switch that doesn't do anything. Every so often I would flick it on and off just to check. Yesterday, I got a call from a woman in Germany. She said, 'Cut it out.'”
Anyone who's somewhat technically inclined should, in my opinion, only be buying valetudo [0] compatible vacuums and replacing the default software as soon as possible.
I found the “Why Not Valetudo” page on that site extremely persuasive. I would consider myself technically inclined. I also own a robot vacuum so I can spend more time doing important things that leverage my skills. Valetudo does not serve this mission.
Very impressive, but I disagree that this is the clear best choice for anywhere close to anyone.
Many geek hobbies like 3D printing and home automation are becoming full of unnecessarily smug evangelization if you're not using hivemind approved software and tools, even if it requires a lot more work to do.
It's nice to a see a project encourage their userbase to be realistic about what it is and refrain from trying to force it on everyone as the only acceptable way to use a robot vaccuum.
The main value proposition is privacy and security. If you are content with the privacy and security of your existing vacuum, then yes, I'd agree it's not for you. That being said, your critique seems to imply that Valetudo will increase your overall time spent managing the vacuum, and this has not been my experience. There is the initial setup time which I'm sure varies by robot, but for me took (conservatively) and hour or two, and then I never think about it again, to the same degree that I would before. You still have schedules, etc. and all the same features that make a robot vacuum a time saving item.
- all the same downsides as keeping the stock OS would have ("it's opinionated software", "it's not about you", and the last one "it's not a community" basically means "you can't tell me how to change my software and be confident I'll do it")
- that this fan project is not necessarily as polished as the original software (as I would have expected)
- Only supported robots are supported (as the author themselves say: duh)
- it only works in english
- you can't revert to stock software if you don't like it
For me, the latter is the only thing worth mentioning. You made me curious what all these compelling downsides are but the rest is obvious and the latter isn't surprising / I would have known to check beforehand
How did you come to the conclusion that it's not likely the right choice for nearly anyone? Do you think so many people wouldn't understand enough English to operate the controls of a robot vacuum cleaner? Have you found features to be missing or clunky/fragile enough that people would frequently want to revert to stock? Do you think people care so much about it being community-driven FOSS that they'd rather keep the proprietary OS instead of open source that isn't community-driven?
Btw I have no experience with the project whatsoever and am not involved, only interested in trying it out once we need a new vacuum. I just came to a very different conclusion and am quite surprised by yours
Agreed, this sort of thing should at minimum be considered gross negligence at this point, but because regular consumers who buy these products rarely see and almost never understand these news articles it doesn't really impact sales so the company doesn't care.
If this discovery was guaranteed to result in meaningful fines companies would get their act together pretty quickly. 7000 counts of negligent exposure of private data (camera/mic feeds) should in a just world be millions of dollars in fines at the least and arguably criminal charges for management.
Exactly. If GDPR fines can be so high, then something like this that is pretty much intentionally leaking personal data should be in the same ballpark.
Internet connections on devices are an anti feature to me. I need something to work reliably without internet. And then maybe add some extras through internet access through open and secure protocols, so I can always write my own implementation.
I don't knowingly have any live cameras or microphones in my home other than my laptop and phone (I know those are big "buts", but still), and I plan to keep it that way.
I remind myself of this no matter how much convenience I may be missing out on. (Getting a TV without em is kinda hard!)
Planning in advance, same for any AR stuff, not in my life, I'm sticking to it.
> In order for the Romo, or really any modern autonomous vacuum, to function it needs to constantly collect visual data from the building it is operating in.
I specifically bought one without a camera or mic.
My Eufy claims to do all processing locally. I admit I never verified this (eg turn off the wifi while it's running - I should actually). But they were the only Chinese manufacturer that at least bothered to write anything about data locality and privacy in their marketing materials, and that got them my money.
Obviously at any point the brand can send a firmware update down the wire that does send a realtime video feed from my home right to Chairman Xi's bedroom. I'm aware of that, but the reality also is that the European/US brands currently don't get anywhere near the Chinese price/quality ratio, and I didn't want to muck about with Valetudo, I'm not courageous enough for that.
I'm not super happy about this situation but I am super happy about the robot. It's really very good.
> In order for the Romo, or really any modern autonomous vacuum, to function it needs to constantly collect visual data from the building it is operating in.
IMO the random bouncing of older Roombas was unfairly pilloried. Sure, it didn't look great, but in practice it was effective at cleaning.
I'm sitting here drinking an Aeropress-made coffee as I type this, but thinking about how the kettle I used to boil the water is wifi-connected. (Although the smarts are limited to firmware updates, there's no control of the kettle or useful data collected from the kettle.)
I understand why such a device might have firmware. For instance: The drip coffee maker in my kitchen also has firmware; it is used for things like operating the clock (which I've never set...), starting automatically at a pre-set time, and for turning the hot bits off after an hour or two. It's completely offline; these are just pre-programmed functions that will never change.
But I have some questions, if you've got a moment.
Why does the kettle's firmware need updating? What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
(And remember: Since the kettle has a radio and a network connection, data collection isn't necessarily limited to kettle operations. Deducing location is easy for a motivated party using wifi and/or bluetooth signals in populated areas where others are using wireless technologies; see, for example: https://www.qualcomm.com/internet-of-things/solutions/qualco... )
> Why does the kettle's firmware need updating? What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
Notably, bug fixes to the same features that your drip coffee maker has (clock/scheduling stuff stuff), and the addition of new languages to the UI.
> What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
I assume these are somewhat rhetorical questions where we both know the answers - I'm not harbouring illusions here - as with any internet-connected software you have to trust the vendor.
If it were up to me, I'd prefer a Z-Wave-connected kettle that received its firmware updates via Home Assistant... but fancy pour-over kettles are niche enough that a market for a Z-Wave one simply doesn't exist.
As-is, I've got enough trust in Fellow that I'm leaving my kettle connected for firmware updates. Of course, that may change.
That's a very nice-looking kettle. Having looked at it, I agree with you completely. It seems rather unlikely that it would turn into a manufacturer-supported attack vector.
We do have a different out-of-band/disconnected/not-wifi way of doing firmware things, and perhaps we should use it more than we do: Bluetooth. It's about as universal as it gets.
I mean: Imagine a Venn diagram, with two groups. One group represents people who update the firmware in their kettles. The other group represents people who have Bluetooth-capable pocket supercomputers.
The two groups overlap so neatly that the diagram is indistinguishable from a circle. :)
Some software features are actually quite nice on kettles! e.g. Mine has adjustable altitude calibration which simplifies things that are temperature-sensitive if you live somewhere with a boiling point notably below 100°: https://www.precisekettlepicks.blog/blog/buying-guides-by-us...
I'd like to think that they should have reasonable security with my best interests in mind, but I really have no way of investigating what the baseband is or is not doing.
“Accidentally” is not accurate. He used AI to inspect the source and found credentials that work in all devices. He also never gained control of anyone else’s devices. He never used the exploit.
I didn't read the article but based on the title and subheading I assume they say "accidentally" because he was trying to reverse engineer the communication protocol to use his own device and he did not expect to find something as dumb as master credentials that would work on others' devices.
"Accidentally" as in his intent was to gain control of his own device but instead discovered what would in a just world be considered criminal levels of either incompetence or indifference to the most basic levels of security in the entire product line.
One advantage of AI-generated copy is it generally doesn't make mistakes like this.
The only mistake I've noticed, besides inexplicably lapsing into Chinese mid-sentence, is parallel construction errors, like "This product is fast, lightweight, and won't break the bank!"
Audio and video surveillance via robot vacuum is a feature: you can control the vacuum, see and hear the world from its perspective, and spy on your cats. I wish I were kidding.
Surely this also requires reporting DJI to the authorities for gross negligence? This is not an oopsie, this is deploying a surveillance network without telling anyone.
every single one relevant to where you live? If you're in the US, the US. Good fucking luck and lol and all that, but do it anyway. In the EU? Your country has agencies for this, as does the EU as a whole.
You know where to report things if you live on Earth and use the internet.
This is a DJI company? Ouch. [edit] ah it is right in the title of the og article. Wow. Just wow. In China we just use a broom, so maybe it is an oversight (aka no one uses this overprices crap)
Well it only took until the 2nd paragraph, and the words "DJI’s remote cloud servers" for me to be forehead-slappingly disgusted again.
Obviously proper diligence wasn't followed with this product, and obviously this is going to be something we've all heard before, but why does a vacuum need to talk to a server at all?
And also, to go even further back, is there anything more leopards-ate-my-face than a compromised robo-vacuum? I have never understood the appeal of these things. Except as satire. Pushing a vacuum around takes minutes, once a month, all the more so when you live in a 3m x 3m box with 12 roommates, and is badly needed exercise for a lot of pathetic little nerd noodle-arms.
> Pushing a vacuum around takes minutes, once a month, all the more so when you live in a 3m x 3m box with 12 roommates
That's a lot of assumptions.
I budget an hour every couple of weeks to vacuum the entire house (kitchen more frequently, but that's quick). When we had pets, which we'll probably have again in the future, this had to be done weekly.
I get the frustration, but this is how pretty much all of the connected home devices on the market work. Sure, there are local-only versions of many of these things, but that sort of design is in the minority both in number of products and in sales.
And it makes sense: most people want this stuff to just work, and be accessible when they aren't at home on their WiFi network. The only reasonable way to do that these days is to have a central server that both the devices and the control apps connect to. Very few users (and yes I am one of them) are going to set up a local control server and figure out how to securely set up remote access to it.
It's a crappy situation that leads to security incidents like this one, but that's just where we are right now.
Regarding cleaning frequency: no need to repeat what the sibling commenter said, but I will say I suspect your cleaning needs are much lower than those of the average person.
> he soon discovered that the same credentials that allowed him to see and control his own device also provided access to live camera feeds, microphone audio, maps, and status data from nearly 7,000 other vacuums across 24 countries.
This is extremely similar to what I accidentally discovered and disclosed about Mysa smart thermostats last year: the same credentials could be used to access, inspect, and control all of them, anywhere in the world.
See https://news.ycombinator.com/item?id=43392991
The ideal spy army. Nobody expects the spanish inquisition I mean, being able to spy into households via cheap house-cleaning devices.
The "smart" thermostat stuff is scary. I have Haier minisplits in my house and they have some "smarts" built into each head unit. The way it works from the user's perspective is you connect to the device in the GE Home app via Bluetooth, enter your WiFi network's credentials, then the minisplit joins your wifi network and phones home to GE Cloud. Then your GE Home app can monitor and control your minisplit via GE Cloud.
I haven't done anything to analyze it further, instead after trying that out once I promptly changed my WiFi password and never looked back. The long term solution will involve some ESP32s, AHT20 temp/humidity sensors, and IR rx/tx.
But it just occurred to me reading this that if there's a similar vulnerability in HVAC system controls an attacker could cause one hell of an unanticipated power demand spike.
This is honestly why it's important to insist on Z-wave or Zigbee if you don't have control over the device firmware and must have smart controls. Why people don't seem to understand now that if it's "WiFi" it's suspect at best, I'll never understand.
This, pretty much.
The ideal setup is having a separate vlan for your IoT things, that has no internet access. You then bridge specific hubs into it, so the hubs can control them and update their firmware.
If you have IoT devices that are unsafe but cannot be updated any other way, you can temporarily bridge the IoT VLAN to WAN.
Honestly, what IoT stuff needs is something similar to LVFS. Make it so all the hubs can grab updates from there, and can update any IoT device that supports Matter. It would also serve as a crapware filter because only brands that care about their products would upload the firmwares.
I replaced all my thermostats for both of my homes with Sinopé products. Here's the hardware, software, and setup:
https://news.ycombinator.com/item?id=45145220
None of the existing smart controls stuff I've found really does it for me. I'm trying to build a hybrid heating system with 4 hydronic zones and 8 minisplits. For my HVAC controls the design is converging to a round mechanical Honeywell thermostat for each hydronic zone with a "smart" thermostat (no cloud) wired in parallel--TBD whether buy vs build. For the minisplits I'm building my own thing that can speak their IR protocol, which will also double as a per-room temperature sensor. It all gets tied together with outdoor temp sensor via HomeAssistant. So if all the "smart" stuff fails, the trusty mechanical guy will keep the house from freezing.
There are halfway decent hybrid controls available for ducted systems but you can't afaik buy anything off the shelf to merge hydronic + minisplits. And as far as I can tell, none of the off-the-shelf smart thermostats has any built in analog backup. I view that as absolutely critical for my use, if the power goes out and I'm not around I need to be 100% certain that when the power comes back on the heat will also.
EDIT: Digging around a little more it seems that Mitsubishi H2i minisplit systems don't speak zwave or zigbee, neither does Haier Arctic. I'm not 100% sure if that's accurate, but I haven't been able to find any documentation in the affirmative or negative. Those are the two heat pump options available locally. I'll be remodeling a small barn into an ADU this summer, that project will be more amenable to a forced air hybrid system, so maybe I'll be able to get away with a Honeywell smart zigbee capable thermostat that can drive it.
Edit: misread.
Is this cutting corners on manufacturing/assembly where they're skipping installing a unique set of keys on each device?
The vulnerability was in their backend cloud structure. The backend wasn't restricting access to only devices associated with your account.
> Out of sheer laziness, I connected to the Mysa MQTT server and subscribed to the match-everything wildcard topic, #. I was hoping I’d see messages from a few more MQTT topics, giving me more information about my Mysa devices.
> Instead, I started receiving a torrent of messages from every single Internet-connected production Mysa device in the whole world.
The devices had unique IDs, but they were all connected to one big MQTT pub/sub system that didn't even try to isolate anything.
It's lazy backend development. This happens often in IoT products where they hire some consultant or agency to develop a proof of concept, the agency makes a prototype without any security considerations, and then they call it done because it looks like it works. To an uninformed tester who only looks at the app it appears secure because they had to type in their password.
> The vulnerability was in their backend cloud structure.
The vulnerability is in having a backend cloud structure.
(There are plenty of ways to provide remote access without that, and no other feature warrants it.)
Not sure why this is being downvoted, it's a pervasive flaw across all these IoT products. See my description elsewhere here about how Haier "smart" controls work. It's completely insane, and pointless. For systems that can't fail--I include heating systems in the winter--this kind of "move fast and break shit" way of doing it is malpractice. The last thing in the entire world I want my furnace controls doing is an automatic OTA firmware update. Ever.
Exactly. I want a "smart thermostat" that's entirely under my control, not the manufacturer's.
I think it's about being a configuration management nightmare. If every device has a unique password, you need the decoder ring for serial number to password. However, not all processors have unique IDs. So you either need to find a way to reliably serialize each board during manufacturing and hope it stays (like a sticker/laser/printer/etc) or add a serial number chip which is cost and complexity. It's not impossible, it's just extra work that usually goes unrewarded.
I'm a long way from embedded development. But I was under the impression a lot of microcontrollers these days have some ID capability built in, even some relatively low-end ones. This strikes me more as laziness than anything.
This is true, for example many stm32 series have a 96 bit unique id which is derived from the lot number, wafer id and position [1]. Even the low cost stm32g0b1 series I am using has them, but they are missing from some older series.
[1] https://community.st.com/t5/stm32-mcus/how-to-obtain-and-use...
Moreover, on any device that is connected to Internet you already have a unique MAC address on its Ethernet or WiFi interface.
You can hash this unique MAC address, together with other data that may be shared with the other devices of the same kind, to generate unique keys or other kinds of credentials.
Surprisingly it's not everywhere. I'm very in embedded development and cannot count the amount of time I look for "unique" "id" etc in a reference manual and come up short. It's certainly more common than not, but you often have to design systems for the lowest common denominator.
> It's not impossible, it's just extra work that usually goes unrewarded.
That sounds like profit motivated negligence, and it sounds like a standard justification for why Europe is going to hold companies liable.
It is indeed. And that sucks but that's what it is. Product design is about calculated risks and trades. It's a good thing regulators are here to help because companies won't do it on their own and the general public doesn't care enough.
We will all owe the EU a massive debt of gratitude. Hopefully USB C was just the tip of the iceberg.
I have not knowledge of this kind of software dev/hw production, so can you please explain why the units cant just be born with a default pass and then have the setup process (which is always there) Force the owner to set a new password?
Knowledge or not, this..
> It's not impossible, it's just extra work that usually goes unrewarded.
.. is just not an acceptable way for business to think and operate i 2026, especially not when it comes to internet connected video enabled devices
I'll answer your question with a question: how often do you see people complaining about needing setup processes vs the old way of just plug and play? There's no perfect answer that placates all sides. Things can certainly be better, but when those people win and you no longer need to have a setup process, then what?
While true that in $current_year it would be nice if things were more secure, the sad truth is that most people don't care.
I agree that yes most just want PnP and basically don’t care about security. But it seemed on the posts above that there was an engineering complexity, and a robot vaccum needs local WiFi, so there will be a setup flow. Whats preventing a password selection just be part of that?
I am shocked really, i think this is actual law in China.
This is just people working 24/7 for 50 dollars a month? Because we want cheap shit
Due to the wonders of technology, you can now do the equivalent of the Steven Wright joke:
“In my house there's this light switch that doesn't do anything. Every so often I would flick it on and off just to check. Yesterday, I got a call from a woman in Germany. She said, 'Cut it out.'”
At scale, over the Internet.
Anyone who's somewhat technically inclined should, in my opinion, only be buying valetudo [0] compatible vacuums and replacing the default software as soon as possible.
[0] https://valetudo.cloud/
I found the “Why Not Valetudo” page on that site extremely persuasive. I would consider myself technically inclined. I also own a robot vacuum so I can spend more time doing important things that leverage my skills. Valetudo does not serve this mission.
Very impressive, but I disagree that this is the clear best choice for anywhere close to anyone.
Also, the first line in "Why Valetudo?"
> First of all, please do not try to convince people to use Valetudo.
A good realist position for such a project to take.
That is very refreshing.
Many geek hobbies like 3D printing and home automation are becoming full of unnecessarily smug evangelization if you're not using hivemind approved software and tools, even if it requires a lot more work to do.
It's nice to a see a project encourage their userbase to be realistic about what it is and refrain from trying to force it on everyone as the only acceptable way to use a robot vaccuum.
The main value proposition is privacy and security. If you are content with the privacy and security of your existing vacuum, then yes, I'd agree it's not for you. That being said, your critique seems to imply that Valetudo will increase your overall time spent managing the vacuum, and this has not been my experience. There is the initial setup time which I'm sure varies by robot, but for me took (conservatively) and hour or two, and then I never think about it again, to the same degree that I would before. You still have schedules, etc. and all the same features that make a robot vacuum a time saving item.
For anyone else wondering, "Why Not Valetudo" <https://valetudo.cloud/pages/general/why-not-valetudo.html> lists:
- all the same downsides as keeping the stock OS would have ("it's opinionated software", "it's not about you", and the last one "it's not a community" basically means "you can't tell me how to change my software and be confident I'll do it")
- that this fan project is not necessarily as polished as the original software (as I would have expected)
- Only supported robots are supported (as the author themselves say: duh)
- it only works in english
- you can't revert to stock software if you don't like it
For me, the latter is the only thing worth mentioning. You made me curious what all these compelling downsides are but the rest is obvious and the latter isn't surprising / I would have known to check beforehand
How did you come to the conclusion that it's not likely the right choice for nearly anyone? Do you think so many people wouldn't understand enough English to operate the controls of a robot vacuum cleaner? Have you found features to be missing or clunky/fragile enough that people would frequently want to revert to stock? Do you think people care so much about it being community-driven FOSS that they'd rather keep the proprietary OS instead of open source that isn't community-driven?
Btw I have no experience with the project whatsoever and am not involved, only interested in trying it out once we need a new vacuum. I just came to a very different conclusion and am quite surprised by yours
I wonder if Claude could do a good job or setting this up for someone not technically inclined
Until it can disassemble a robot to attach a programmer to the mainboard, it cannot.
Companies this inept really need to get fined.
Like how many layers of people had to have OKed having the same password for all of them? It’s incompetence on an impressive scale.
Agreed, this sort of thing should at minimum be considered gross negligence at this point, but because regular consumers who buy these products rarely see and almost never understand these news articles it doesn't really impact sales so the company doesn't care.
If this discovery was guaranteed to result in meaningful fines companies would get their act together pretty quickly. 7000 counts of negligent exposure of private data (camera/mic feeds) should in a just world be millions of dollars in fines at the least and arguably criminal charges for management.
Exactly. If GDPR fines can be so high, then something like this that is pretty much intentionally leaking personal data should be in the same ballpark.
Just one underpaid dude.
Internet connections on devices are an anti feature to me. I need something to work reliably without internet. And then maybe add some extras through internet access through open and secure protocols, so I can always write my own implementation.
I don't knowingly have any live cameras or microphones in my home other than my laptop and phone (I know those are big "buts", but still), and I plan to keep it that way.
I remind myself of this no matter how much convenience I may be missing out on. (Getting a TV without em is kinda hard!)
Planning in advance, same for any AR stuff, not in my life, I'm sticking to it.
I have a roomba It has never been connected to wifi and I’ve never used a phone app for it (I don’t have a phone)
It works perfectly.
a room a?
Sorry, autocorrect. Roomba
Original story: https://www.theverge.com/tech/879088/dji-romo-hack-vulnerabi...
Accompanying discussion on hn https://news.ycombinator.com/item?id=47047808
> In order for the Romo, or really any modern autonomous vacuum, to function it needs to constantly collect visual data from the building it is operating in.
I specifically bought one without a camera or mic.
My Eufy claims to do all processing locally. I admit I never verified this (eg turn off the wifi while it's running - I should actually). But they were the only Chinese manufacturer that at least bothered to write anything about data locality and privacy in their marketing materials, and that got them my money.
Obviously at any point the brand can send a firmware update down the wire that does send a realtime video feed from my home right to Chairman Xi's bedroom. I'm aware of that, but the reality also is that the European/US brands currently don't get anywhere near the Chinese price/quality ratio, and I didn't want to muck about with Valetudo, I'm not courageous enough for that.
I'm not super happy about this situation but I am super happy about the robot. It's really very good.
> In order for the Romo, or really any modern autonomous vacuum, to function it needs to constantly collect visual data from the building it is operating in.
IMO the random bouncing of older Roombas was unfairly pilloried. Sure, it didn't look great, but in practice it was effective at cleaning.
Are there any like that that would have automatic emptying?
Roborock q revo
Ive got a q revo pro, which can dry the mops.
Happy with it but note that I dont have carpets, I guess for carpets you need something with more features.
The Roborock is what I have, and I've had no complaints; the Q5 Max+. With some googly eyes, it's pretty cute :)
The Q Revo series does have a camera and mic.
They don't, the camera equipped ones are the maxV series.
Q Revo has an IR sensor which doesn't transmit that data anywhere.
I had a Q Revo Edge that had a mic (it responded to "Hey Rocky" commands) and I could remotely view my house through the camera.
Are you thinking of the S8 line? That's the one with the MaxV model.
No, I'm thinking about the Q Revo line which does not have cameras as I mentioned.
How do you know? For sure, I mean?
I wrapped mine in foil to be safe and now it's fabulous
I mean your coffee maker could be a one-off spy device with nation-state backing. But it seems unlikely.
if they can build an internet connected coffee maker with mic and camera for 60 bucks that's freakin' amazing!
$17.60 for the internet connected microphone and camera (see parts list below),
list of coffee machines for under ($60-$18):
https://www.google.com/search?q=coffee+machine+under+%2442
m5stack camera: $7.10 https://shop.m5stack.com/products/unit-cam-wi-fi-camera-ov26...
m5 stack microphone: $3.50 https://shop.m5stack.com/products/pdm-microphone-unit-spm142...
m5stack atom light S3 controller: $7.50 https://shop.m5stack.com/products/atom-lite-esp32-developmen...
I'm pretty sure they'd be happy to swallow the loss when building a one-off device to specifically target you.
defeated by walking into a random shop and picking one off the shelf
rather than buying it from scamazon
Undefeated when they break into your home
at that point the coffee machine is sort of redundant
Would it include a cell radio and SIM card? Or are they hoping for an open WiFi network in range?
Radiate the signal out through its power cord, silly.
If Google thought it was okay to hide a microphone, I'm sure less scrutinized companies try to get away with worse. https://www.bbc.com/news/technology-47303077
he did say he was trained at the kremlin...
phew, yet another reason it pays off to not be a coffee drinker.
:) I'm sticking with my Aeropress
I'm sitting here drinking an Aeropress-made coffee as I type this, but thinking about how the kettle I used to boil the water is wifi-connected. (Although the smarts are limited to firmware updates, there's no control of the kettle or useful data collected from the kettle.)
I understand why such a device might have firmware. For instance: The drip coffee maker in my kitchen also has firmware; it is used for things like operating the clock (which I've never set...), starting automatically at a pre-set time, and for turning the hot bits off after an hour or two. It's completely offline; these are just pre-programmed functions that will never change.
But I have some questions, if you've got a moment.
Why does the kettle's firmware need updating? What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
(And remember: Since the kettle has a radio and a network connection, data collection isn't necessarily limited to kettle operations. Deducing location is easy for a motivated party using wifi and/or bluetooth signals in populated areas where others are using wireless technologies; see, for example: https://www.qualcomm.com/internet-of-things/solutions/qualco... )
> Why does the kettle's firmware need updating? What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
It's a Fellow EKG Pro kettle. They've got release notes here: https://help.fellowproducts.com/hc/en-us/articles/9593179929...
Notably, bug fixes to the same features that your drip coffee maker has (clock/scheduling stuff stuff), and the addition of new languages to the UI.
> What inhibits a future firmware update from controlling the kettle and collecting data? How would you or any other owner of this style of kettle know if it had shifted gears?
I assume these are somewhat rhetorical questions where we both know the answers - I'm not harbouring illusions here - as with any internet-connected software you have to trust the vendor.
If it were up to me, I'd prefer a Z-Wave-connected kettle that received its firmware updates via Home Assistant... but fancy pour-over kettles are niche enough that a market for a Z-Wave one simply doesn't exist.
As-is, I've got enough trust in Fellow that I'm leaving my kettle connected for firmware updates. Of course, that may change.
That's a very nice-looking kettle. Having looked at it, I agree with you completely. It seems rather unlikely that it would turn into a manufacturer-supported attack vector.
We do have a different out-of-band/disconnected/not-wifi way of doing firmware things, and perhaps we should use it more than we do: Bluetooth. It's about as universal as it gets.
I mean: Imagine a Venn diagram, with two groups. One group represents people who update the firmware in their kettles. The other group represents people who have Bluetooth-capable pocket supercomputers.
The two groups overlap so neatly that the diagram is indistinguishable from a circle. :)
A kettle needs firmware updates?
I'd say "has" firmware updates rather than "needs". You can see release notes: https://help.fellowproducts.com/hc/en-us/articles/9593179929...
A kettle needs firmware?
Some software features are actually quite nice on kettles! e.g. Mine has adjustable altitude calibration which simplifies things that are temperature-sensitive if you live somewhere with a boiling point notably below 100°: https://www.precisekettlepicks.blog/blog/buying-guides-by-us...
Does your smartphone have a mic?
You've brought up such a brilliantly useless point to this discussion. I'm really appreciative of your efforts
Smartphones at least have some semblance of security, whereas iot devices are a free for all
Do they?
I'd like to think that they should have reasonable security with my best interests in mind, but I really have no way of investigating what the baseband is or is not doing.
“Accidentally” is not accurate. He used AI to inspect the source and found credentials that work in all devices. He also never gained control of anyone else’s devices. He never used the exploit.
I didn't read the article but based on the title and subheading I assume they say "accidentally" because he was trying to reverse engineer the communication protocol to use his own device and he did not expect to find something as dumb as master credentials that would work on others' devices.
"Accidentally" as in his intent was to gain control of his own device but instead discovered what would in a just world be considered criminal levels of either incompetence or indifference to the most basic levels of security in the entire product line.
How long before there is a claw controlled network of robot/device spies and soldiers?
He couldve cleaned up....
Well - imagine how many cat furs can be vacuumed with this!
"sneak peak"
Sigh
https://slate.com/culture/2012/01/stealth-mountain-the-twitt...
One advantage of AI-generated copy is it generally doesn't make mistakes like this.
The only mistake I've noticed, besides inexplicably lapsing into Chinese mid-sentence, is parallel construction errors, like "This product is fast, lightweight, and won't break the bank!"
> [...] the same credentials that allowed him to see and control his own device also provided access to live camera feeds, microphone audio [...]
Sorry what? Why would a vacuum cleaner even need a microphone?
As an impractical idea, echo location popped into my head.
Control by voice? Not that absurd.
Audio and video surveillance via robot vacuum is a feature: you can control the vacuum, see and hear the world from its perspective, and spy on your cats. I wish I were kidding.
https://youtu.be/TltYXEDoong?t=412
Who is "you" in that sentence?
One.
control what?
"get out of my room"?
Surely this also requires reporting DJI to the authorities for gross negligence? This is not an oopsie, this is deploying a surveillance network without telling anyone.
It is gross negligence, but to which authorities are you reporting them to and which criminal violations are you claiming they broke?
every single one relevant to where you live? If you're in the US, the US. Good fucking luck and lol and all that, but do it anyway. In the EU? Your country has agencies for this, as does the EU as a whole.
You know where to report things if you live on Earth and use the internet.
This is a DJI company? Ouch. [edit] ah it is right in the title of the og article. Wow. Just wow. In China we just use a broom, so maybe it is an oversight (aka no one uses this overprices crap)
I invoke Hanlon's Razor [0]. Never attribute to malice that which is adequately explained by stupidity
0: https://en.wikipedia.org/wiki/Hanlon%27s_razor
Well it only took until the 2nd paragraph, and the words "DJI’s remote cloud servers" for me to be forehead-slappingly disgusted again.
Obviously proper diligence wasn't followed with this product, and obviously this is going to be something we've all heard before, but why does a vacuum need to talk to a server at all?
And also, to go even further back, is there anything more leopards-ate-my-face than a compromised robo-vacuum? I have never understood the appeal of these things. Except as satire. Pushing a vacuum around takes minutes, once a month, all the more so when you live in a 3m x 3m box with 12 roommates, and is badly needed exercise for a lot of pathetic little nerd noodle-arms.
> Pushing a vacuum around takes minutes, once a month, all the more so when you live in a 3m x 3m box with 12 roommates
That's a lot of assumptions.
I budget an hour every couple of weeks to vacuum the entire house (kitchen more frequently, but that's quick). When we had pets, which we'll probably have again in the future, this had to be done weekly.
I get the frustration, but this is how pretty much all of the connected home devices on the market work. Sure, there are local-only versions of many of these things, but that sort of design is in the minority both in number of products and in sales.
And it makes sense: most people want this stuff to just work, and be accessible when they aren't at home on their WiFi network. The only reasonable way to do that these days is to have a central server that both the devices and the control apps connect to. Very few users (and yes I am one of them) are going to set up a local control server and figure out how to securely set up remote access to it.
It's a crappy situation that leads to security incidents like this one, but that's just where we are right now.
Regarding cleaning frequency: no need to repeat what the sibling commenter said, but I will say I suspect your cleaning needs are much lower than those of the average person.
>once a month
We vacuum and mop our kitchen and dining room daily. It gets dirty, especially when you have young kids.
Terrible writing in the article.
>It retails for around $2,000 and is roughly the size of a large terrier or a small fridge when docked at its base station.
So, large terriers, and small [presumably 'smart'] fridges can have docking stations?
accidentaly a god, a sucky kinda god, but a god none the less " I command thee to make vanish the minor sins of this world my minions"
His code sucks...
Tough crowd. Even the robots got the suction reference.