Require user to hold down the on-handle button for 1-2 secs to start (or slide across) to avoid starting the oven from incidental contact - especially since timer expiration does not turn off oven heat. Should not be needed for phone app, IMO.
Consider - at least on phone app - a way for users to turn off the oven at end of all stages if (timed and) desired. In theory, it could be something the phone app does itself (auto-stop at end of time) requiring no changes to oven firmware. Or a stage that is āStopā that one can add at the end. In a prior post, someone mentioned that microwaves have unfortunately trained us to think that zero time means off, which I do agree with.
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 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.
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.
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?
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.
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.
