I think this is a good suggestion. It’s how my LG washer and dryer work.
I’m actually not totally ok with an app starting an appliance such as an oven. My Control4 home system can’t start my standard oven even though its integrated. I’m going to be the minority in this I think.
For your use case, I wonder if they could add a preference to the app that would push the settings to the oven but disable the actual start button, so you would have to be physically present to start it going.
I agree 100%. Internet controlled oven starts should be a feature that is not enabled by default or can be easily switched off on the oven itself. I would prefer for this not to be a software or app controlled part of the oven as it could easily be re-enabled from a future OTA update.
I have added a firewall rule for now to block the oven traffic so it cannot be controlled from the web.
Unsurprisingly the app doesn’t seem to support direct local WiFi oven communication and only uses their hosted service so is now useless. I primarily plan to use this for bread so I won’t miss the multi-stage app convenience as I can adjust the steam manually pretty easily when needed. I never used their app to control my sous-vide(s) so doubt I will miss it on the oven either.
This isn’t a sous-vide that is in water and fairly benign if compromised. I accept the risk of fire etc. is relatively low given the oven would have to be started with something inside to present a real hazard, however, I’m not sure what would happen if I sent stop/start commands continuously. I’d like to think this was part of their testing
It will be interesting to see if we can hack local control. I’m with you. I’m sure given the past history with reverse engineering on the sous vide devices it wont take long.
My reaction to hacking the interface you’re worried about behaving badly is, caveat emptor. If you start hacking it, you likely absolve the company of any liability should things go wrong…
At the moment I have to connect my oven over a different Internet connection, so I personally definitely don’t want to cut it off.
I think posting this feature request here (or disconnecting the oven) is probably the best course of action at the moment
Yes, we don’t have a problem assuming any liability. Nature of hacking. You don’t even have to add a warning. BTW: the hacking would be to interface with the device locally. That’s something just about any geek is going to want anyway. My subculture hacks anything to remove the cloud dependence on principle.
A potential issue there is that if you have to circumvent security measure to take local control, other hackers that can get access to your network can do the same.
At the moment, they would need to compromise the security of Anova’s network services- as local network access is irrelevant.
I’m guessing you aren’t a software engineer.
I can’t speak to how they implemented it, but if they have done things correctly so that the “keys to the kingdom” are based upon the user presenting authorization tokens signed by Anova, that is somewhat more secure than doing whatever something on the local network asks.
It’s technically possible to have local control and security.
Yes - I completely agree - more often that is by careful correct design though, as most hacking by definition sacrifices security to gain better control.
What are you trying to gain here? Clearly you have no interest and are not a software engineer etc. No, this is not the definition of hacking or reverse engineering permitted under DMCA.
I could hack insecure firmware and add new transports and transport security that didn’t exist.
Not sure if you are trying to climb up on a high horse or are just having some fun being contrarian.
Mainly the latter, no offense meant!
Example of the usual hack IMO: original Chromecast API being hacked for easier casting, but also then “rickrolling”
Ok, but I’m not sure of your intent. Seems like its just to create FUD. It’s ok if you don’t want open local control of your products. You might not want or need it. It’s ok to be different, right?
I think we’re talking past each other a bit.
Ideally I’d want every remote command to the oven cryptographically signed, both to prevent tampering and to assert authorization. In that case, local vs. remote doesn’t matter- the emphasis is on being secure regardless of from where. I think we still want remote emergency stop regardless of other functionality.
Other oven owners may not have as secure a local network as you do, so insecure local exposure would be a problem in those cases; it doesn’t surprise me thay Anova is requiring cloud auth and control at the start.
When they get more maturity on this one, I might trust them to correctly maintain both local and remote network operating modes… but for now, since practically speaking they can probably do at most one well, my vote is cloud.
Anova could have, if they wanted, implemented MQTT to a local application on a phone using the exact same certificates and TLS encryption as the cloud.
The ‘local network’ is the common transport for both implementations and is consequently a ‘red-herring’ - a properly designed local application on a local network will always be more secure than a cloud-based version. Period. The local implementation would not have or need a permanent point of presence on the internet on port 8xxx as the oven does right now as I type (well, not in my case as I have blocked it on my firewall).
Critical infrastructure does not use cloud-based services for a very good reason and indeed go to extreme lengths to ensure their systems do not have any connections to the internet. And no, I’m not classing my oven as critical infrastructure
Bad actors go after IoT devices connected to the web by scanning known ports and looking for responses. When they get a response they then exploit know vulnerabilities in these devices. Vulnerabilities often do not surface for many months or years down the line but when they do it can be very problematic to get security updates and patches deployed when the product is no longer in support. Google Ripple20 IoT as an example. I deal with the fallout from this type of thing on a daily basis…
Bringing the discussion back to oven suggestions/improvements - The oven, as a minimum, should require the end-user to confirm remote start oven commands when the oven is not already running.
Thank you for being another sane oven owner.
Looks like they are changing their api’s on the older sous vide devices and rolling them over to oath on anovaculinary.io. I have not looked at the traffic yet to see if the oven is doing same.
If there was local bluetooth control of the ovens we could proxy to MQTT like folks have done with the cookers. I do see that the oven fails back to AP when the wifi is not connected. Maybe there are some options there.
Example of someone using the new cloud API’s for the cookers to bypass the app:
Yes, or offer some sort of code on the device that needs to be entered in the app to start. My kid has already started the oven by accident so…
Also, the start on the oven is too sensitive. It needs needs debounce and could use a long press as has been suggested.
The most secure way to operate, via least privilege, would be for the oven to not run any open servers that could be hacked, and instead reach out to known trusted servers verifiable by certs etc. as we discussed earlier. That would reduce the local attack surface to zero, but would also prevent local functionality unless someone puts an AP there for MITM proxy attack on the oven’s control infrastructure. That is where local network functionality would compromise security. You generally don’t want folks to be able to control your car over local network, at all, but OnStar cloud function is acceptable to those that want it.
I do agree that they could implement local servers and still use modern security features, but that typically requires credentials on the devices themselves which could be compromised or changed.
Anyway, enough about that!
I think we all agree
Physically, it’s too easy to bump the oven and turn it on… hold time and/or other mitigations are very highly recommended!
For those who want it, there should be a way to disable remote start, ideally while still allowing remote emergency stop.
If it would not compromise security of the current implementation, there is some interest (at least from early adopters) in allowing only local control and not cloud/Internet.