Hacker News Reader

Comment by khamidou | Hacker News Reader

I don't get the hate, it looks like they reverse-engineered the nest thermostat and wrote a firmware for it? That's super cool and the fact that an open source project doesn't have a privacy policy yet doesn't really matter at this point

View on HN

> ...looks like they reverse-engineered the nest thermostat and wrote a firmware...

Not to diminish what this project has done, but they modified existing firmware to make it communicate with a different server. They've also implemented a server for the thermostat API.

It's pretty neat but, at this point, it's just a hacked firmware that talks to a different proprietary server.

Edit: It's not even a modification to the firmware binaries. They're just injecting /etc/hosts entries into the firmware[0]. If the Nest device just uses DNS to resolve these names then you wouldn't even need to modify the firmware-- just point it at a DNS server that's authoritative for the necessary names.

[0] https://github.com/codykociemba/NoLongerEvil-Thermostat/issu...

Does it not use TLS? Wouldn't the Nest have to trust a CA willing to issue certificates without proving ownership?

They're also injecting a CA bundle so, presumably, they're in including their own root of trust so they can sign their own certificate. I'm on mobile and can't easily look at what they're including.

Edit: Guess I've got openssl in my termux environment. They're injecting a fake Nest root CA key. Makes sense.

I'm shocked it was this easy to subvert the root of trust on these devices. I would expect a newer device would have the trust root pinned in hardware (TPM, etc) and firmware updates would be have been authenticated.

I'm glad they didn't go that far... I wouldn't want that to get into a home device as long as it requires physical access to bypass/update the security in place. I'm really not a fan of excessively locked down hardware.

>I would expect a newer device would have the trust root pinned in hardware (TPM, etc) and firmware updates would be have been authenticated.

All those things cost money in hardware or development time, so companies basically never bother. You're probably also letting all the stories about DRM on phones or whatever color your experience on IOT as a whole. TPM basically makes no sense to implement on anything that's not a PC. Not even phones use it.

Secure phones use it. IPhones (Secure Enclave), Pixels (Titan M2).... Yeah, that's not much....

"TPM" =/= Secure Enclave =/= Titan M2

You could argue TPM can work as a generic term for security coprocessors, but on a technical forum that makes as much sense as saying the pixel tablet is an "iPad".

To be fair, I was using TPM a little genetically (hence the "etc"). I (perhaps wrongly) assume most SoC's today have a non-volatile area for storing roots of trust and possibly a bootloader. My only embedded experience was an Android-based tablet project where DRM on the firmware was of major import because features were locked behind time/geo-limited license keys.

Piling-on to my comment here: They're using an exploit to get access to the filesystem of the device: https://wiki.exploitee.rs/index.php/Exploiting_Nest_Thermost...

It’s the “no longer evil” marketing without actually proving that “no longer evil.com” is in fact … from from evil.

I was assuming that I could point the nest data stream & control UI to my own hosted thing on eg my local NAS or docker farm. That’s what I think would warrant the moniker “free from evil” in this kind of strong privacy preserving marketing.

If they really want to show that they're building something that protects user privacy, they'd open source their backend server, and make it possible and easy to self-host it and point the modified firmware[0] at your own instance.

[0] They didn't write their own firmware; they hacked the stock firmware to redirect traffic from Google's servers to their own.

Edit: looks like they plan to open source the backend and enable self-hosting "soon". Hopefully that comes to pass!

Running open-source firmware someone's hacking on (which gets little to no testing) on a gas appliance that can burn your house down is probably not the best idea.

If you are paranoid about Nest being evil maybe stick to one of those Honeywell round hockey-puck things with the mercury inside.

Or use a Z-Wave/Zigbee thermostat from a reputable vendor (there aren't many) and control it from a gateway of your choice.

This is for people who have already bought a nest and got burnt by the deprecation of their online services. Of course they could get another thermostat but then that'd just be more stuff for the landfills.

Early generation Nest hardware was garbage, and was known for blowing FETs that failed closed, turning people's ACs into giant ice cubes. Putting it in the landfill would be doing yourself a favor.

The ex-Apple culture in the early history of Nest was evident, which ostensibly spec'd FETs over mechanical relays for superficial reasons, because clicking sounds are ugly. The results were in the spirit of other Apple engineering marvels (Titanium Powerbook, Antennagate, Bendgate).

Well that's certainly a take. Solid state relays using optoisolated MOSFETs have been around for fifty years. Mechanical relays are overkill for signal switching as in HVAC thermostats, IMHO, but you do you.

Anecdotally, I have a first generation Nest and haven't had a problem. Maybe some of the earlier hardware had fewer protection against misuse (e.g., with non-24VAC systems or otherwise incorrect installation), but that's generally the case with most new things.

Sounds like something Nest engineers would have said.

It's not "signal switching", you see.

HVAC equipment is as old and varied as you can imagine, and there is higher current than you think running through those terminals, powering all sorts of nasties, oil burner relays, damper motors, crude AC contactors causing voltage spikes etc. HVAC low voltage power is as dirty as can be.

No one took this into account, they were more concerned with making the thermostat pretty.

Nest is hardly the only thermostat out there using solid-state relays. Have you considered the possibility that they did take it into account and they deliberately chose to use SSRs instead of electromechanical relays? Have you considered the possibility that they were concerned about the impact that mechanical relays may have on the RF, especially if "there is higher current than you think running through those terminals"? Have you considered the possibility that they were worried about making the first one fatter than it already was?

In my heat pump, none of the thermostat wires directly control the contactors. They all run into a logic board that applies logic like time delays, temperature-controlled defrost cycling, and active protection lockouts for the compressor. I mean, there's a seven-segment LCD on the logic board for system troubleshooting. The air handler has a variable speed blower as well.

I understand that HVAC equipment varies wildly, but if you try to solve every possible problem or scenario and target every possible customer, you'll never make it to market.

I also understand that I am the target demographic.

It doesn’t just not have a privacy policy yet, but it’s not actually open source either. Honestly they probably fully intend on doing it, but it is important to point out that it is not yet open source.

> Open Source Commitment

>We are committed to transparency and the right-to-repair movement. The firmware images and backend API server code will be open sourced soon, allowing the community to audit, improve, and self-host their own infrastructure

Reply on news.ycombinator.com