393
you are viewing a single comment's thread
view the rest of the comments
[-] GreyEyedGhost@piefed.ca 5 points 2 days ago

The code is open source. Like any open source software, unless it's been vetted, you're relying on trust. The premise is that the software is running on the vacuum, so there is no cloud or remote storage. So, just like anything else self-hosted, unless your network is compromised or you configure it to allow it, nothing external is accessing it. If you don't trust it, vet it. Read the code or check your network logs.

[-] VibeSurgeon@piefed.social 3 points 2 days ago

I'm not talking about the code in Valetudo - I'm talking about the code that's already running on the robot vacuum before installing Valetudo. It remains on the device after you install Valetudo.

Basically, any concerns about privacy stemming from the original software on the robot vacuum do not get eliminated by installing Valetudo

[-] gopher@programming.dev 4 points 2 days ago

Valetudo actively blocks the cloud connections. Also, only firmware versions specifically installed with Valetudo is supported (so no chance an update to the original device firmware happens, and does new things).

I think there's a very low chance something escapes to the vendor cloud.

None the less, I personally run these on a separate VLAN without internet access.

[-] VibeSurgeon@piefed.social 1 points 2 days ago

Valetudo actively blocks the cloud connections.

Are you sure about that? It'd be a pretty big feature to implement, and surely it would be something that the Valetudo author would mention in the docs for the project.

[-] Hypfer@discuss.tchncs.de 1 points 9 hours ago

It’d be a pretty big feature to implement, and surely it would be something that the Valetudo author would mention in the docs for the project.

Dude. What?

It is literally the only feature of Valetudo.

Wat.

What else would Valetudo possibly be doing other than disconnecting from the cloud?

[-] VibeSurgeon@piefed.social 1 points 1 hour ago

Given that you are the author of the project, I do consider you the higher authority on what it can and cannot do.

But to me, there's a slight distinction to be made here - Valetudo allows you to directly control the robot from a server running locally on the robot, giving you the option to not interact with a cloud service in order to remotely control the robot vacuum.

This doesn't immediately imply that the robot is directly prevented from passing information to a cloud service - just that the cloud service does not have to be involved as a command proxy.

The larger feature I was thinking of was not only serving a local server to allow commands to come in directly, but also actively prevent any outgoing connections from the robot vacuum to its manufacturers cloud.

Again, you are the author - you know far better what Valetudo does and does not do, so your information weighs heavier here.

I guess I can also mention that I will be pleasantly surprised if my Chinese robot vacuum has actually been prevented from logging any information back home as a part of me having run Valetudo for the past years.

[-] Hypfer@discuss.tchncs.de 1 points 1 hour ago

I wouldn't recommend "taking my word for it" tbh.

This is something not decided by authority of a person but authority of the code - and, in turn, authority of a pcap file.

[-] VibeSurgeon@piefed.social 1 points 1 hour ago

Fair enough. I searched for pcap files in all the repositories for Hypfer on GitHub but found nothing - do they live somewhere else, or is this just GitHubs search being generally lacking?

[-] gopher@programming.dev 5 points 1 day ago

It's just DNS based, and iirc dont require any major effort other than patching the hosts file. Of course it is possible it is not enough, but I have high confidence in the authors after also having watched various talks at I.e DEFCON, that i would be surprised if they missed the firmware doing other nasty things.

Patching DNS is specifically possible to enable/disable on the firmware build tool: I.e https://builder.dontvacuum.me/_dreame_r2416.html and the source for that is here https://github.com/dgiese/dustbuilder-script-public/blob/7afed16999711833a8ac0b3b482e935c3ef77219/modifys8image.sh#L169

[-] Hypfer@discuss.tchncs.de 1 points 9 hours ago* (last edited 9 hours ago)

It’s just DNS based, and iirc dont require any major effort other than patching the hosts file.

Incorrect. That was technically sorta the case back on the S5 (and even there it needed firmware modifications), yes, but if DNS redirection was all it needs, then why even root the bots in the first place. Just do that on a network level and be done with it.

[-] gopher@programming.dev 1 points 49 minutes ago* (last edited 20 minutes ago)

Oh okay, I just assumed the main method to redirect the vendor cloud connections to the local valetudo was based on the patch DNS parts in dustbuilder that seems present on most models, but if you say more is required elsewhere to block vendor cloud connections I'm sure that's true.

In any case your work is highly appreciated! And i didn't mean to suggest that it hasn't taken a massive amount of work overall to make valetudo work as well as it does.

[-] Hypfer@discuss.tchncs.de 1 points 17 minutes ago* (last edited 10 minutes ago)

Aaah! Oh. Yes that makes a lot of sense indeed.

The UX (and architecture, for that matter) of the dustbuilder has been.. uh.. lacking.. due to the lack of refactoring. It evolved over all these years, and things that had a meaning once suddenly gained a different one, but are still named in the old ways.

Good point, thanks for pointing it out! I've been doing some refactoring there, actually, and there, it's named "disable cloud", but I just did that for correctness. It did not occur to me that from a user-perspective, this is not just weird but actively misleading. I mean it kinda did, but I did not make the mental connection to this specific misconception. Oh well.

[-] VibeSurgeon@piefed.social 1 points 1 day ago

Interesting.

This seems to be a model-specific quirk and moreso a side effect of getting Valetudo to work rather than an explicit goal - the same option does not appear in DustBuilder for my model (Roborock S5, still going strong after 941 hours of cleaning time).

I feel like I should check out this DEFCON talk though.

I learned something new today, thank you for that

[-] GreyEyedGhost@piefed.ca 2 points 2 days ago

From what I can see, one of two things happens. First, the main cloud communications are intercepted and handled by Valetudo. It replaces the cloud infrastructure with the firmware it adds to the vacuum. Second, some require connectivity to your router or the internet in general. Connections to your router shouldn't be harmful, and he specifically leaves blocking connections to the internet (which shouldn't be required for the vacuum to function). I'm only speculating here, but given the open-endedness of the comment I'm guessing explicitly blocking certain connections could be considered an illegal circumvention by laws such as the DMCA. I'd like them to note which vacuums those are so they could be more easily avoided.

this post was submitted on 20 Sep 2026
393 points (99.2% liked)

Technology

88185 readers
4799 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS