>> The thing about the app is that it was written with Electron [an open-source framework developed and maintained by GitHub that allows you to build applications using only javascript-based HTML]. Even though the app relies entirely on Chromium, which has a really strong sandbox in Windows, in this case, it’s actually running on Windows without any kind of sandbox. So what I was doing in the demo is downloading an .exe file from the internet, and I just ran it because there’s no sandbox involved.

This is the first I've heard of electron running without a sandbox. If this is correct, then the security implications are much wider than just sex toys; I had (perhaps naively) presumed that since electron is chromium-based it shared the chrome sandbox strength.

I know nothing about how Electron works but from that line what I read is that, even though Electron has a sandbox, it was disabled at build time for that application.

Given that it has to interface with a low-level dongle over some presumably raw protocol that Windows would have blocked, I would not be surprised if the devs just gave the app more and more permissions until it worked and called it a day.

> You can compromise the sex toys in the same way because, again, they don’t prevent you from just uploading your own code.

To the plug? If you have a programming device or the firmware enables it. I don't think this should necessarily be changed in the interest of open firmware. Sure, a client app probably focused on threats from the other direction, even if this application strongly hints at the dangers from the backside. Or maybe that motivated a relaxed approach in the first place. And if the vulnerability is in the SDK from the BT-chip, the plug developer isn't even the culprit.

Chuck Tingle title imitating life again.

I guess he found a backdoor?