The line should be what is illegal, which, at least in the US, is fairly permissive.
The legal process already did all the hard work of reaching consensus/compromise on where that line is, so just use that. At least with the legal system, there's some degree of visibility and influence possible by everyone. It's not some ethics department silently banning users they don't agree with.
Then, the ad-adverse users will just use software that downloads the video and reprocesses the file to remove the ads. Ytdlp already does this with SponserBlock integration, and I imagine detecting ads is something AI would be pretty good at.
Of course, you lose the ability to mindlessly browse YT with no ads or get the dopamine hit of clicking an interesting video. I'm sure that's something YT considered if they pushed this option. They don't want you to just watch the few vids from your subscriptions per day and close the app.
Especially the 'backend' languages that do all the heavy lifting for domain-specific software. Just in my vertical of choice, financial software, there are literally billions of lines of Java and .NET code powering critical systems. The code is the documentation, and there's little appetite to rewrite all that at enormous cost and risk.
Perhaps AI will get reliable enough to pour through these double-digit million LOC codebases and convert them flawlessly, but that looks like it's decades off at this point.
I worry more about aging parents/relatives, many of whom aren't exactly tech-savvy to begin with. Many of these scams are becoming increasingly sophisticated, at the same time that being able to perform verification in meat-space is disappearing (companies don't have local support reps that answer phones, etc.)
I just started a company in May to address exactly this! There is so much cyber security tech, but we just felt that no one has really focused on that aging group of users who are historically not technical and very susceptible to phishing attacks. I would love to chat with you about what kind of features you would want to see in that kind of product and/or invite you as a beta user
The stuff on the shelf, sure, but you can always go 'prosumer-grade' like Ubiquiti or Mikrotik for hardware that actually receives timely updates and has competently written firmware.
Ubiquiti is awful, it's a cloud-centric ecosystem. The best "prosumer-grade" stuff is probably OpenWrt. If you need more power, opnSense or a plain Linux distro on an x86 machine.
Not entirely true. There's a local admin option, where your Ubiquiti devices never see the internet (well, except your gateway). You can then connect and admin the whole thing remotely via your own VPN. It's quite nice, actually.
OpenWRT is trading money for time. It's fine to recommend to someone interested in setting up their own custom router, but for most "prosumers" Ubiquiti will provide a better experience.
It's worth noting that Ubiquiti provides local admin support, and that the Ubiquiti Cloud data breach was actually a false story spread by a disgruntled internal engineer in an attempt to extort his employer.
As a MikroTik user. Do not start unless you know your ways around networking. And if you do prepare some time to get used to it. Once you do it isn't hard but the onboarding and having 20-40 options for everything you can do is confusing.
Also, KeepassXC and OG KeePass with a plugin can auto-open another vault from an entry in the primary vault. This works well if you have the more secure vault open a less secure vault, or in my case open a shared vault used for common passwords off a network share at work.
I also preach the tiered password security model. For the common, frequently used passwords that don't need max security, I just use the browser store (with a copy in KP).
Given how modern browsers are increasingly hostile to long-lived, self-signed certs, I've resigned to paying the .com tax every year for a real domain. There's so many ACME clients now (e.g. HomeAssistant has a plugin), that it's fairly easy to have legitimate certs on internal devices. A side benefit is having a subdomain that can be used as a dynamic DNS record.
Cloudflare (and probably others) let you enter non-routable IPs into their DNS, so myhomeserver.mydomain.com can point to 192.168.1.45 on your LAN without having to run your own DNS/hosts.
Are they? Browsers treat long-lived self-signed certs pretty much exactly how they always have, from what I’ve seen: if you’ve trusted the cert in your system trust store, it just works. If you haven’t, you get a red warning page and have to click to proceed.
I got burned recently by Ecobee in the same way. The problem with 'smart' interfaces for traditionally mechanical devices is that the useable lifetime (support period) of low-end microprocessors and software, especially online APIs, is often far shorter than the mechanical device it's attached to.
Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units.
What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality. I and many others in the HA/ESPHome community have written hardware integrations to devices over RS485/UART with unpublished/black-box protocols, so a simple HTTP API would have an integration within days.
It would maybe cost an engineer at Nest/Ecobee a day or two of work, and the goodwill would make me far more likely to purchase a newer model. As it is, I've committed to avoiding (where possible) devices that aren't local-first.
As an early Nest employee who worked on the first-gen thermostat I can tell you definitively that you're way off base here. That doesn't mean that Google shouldn't have done more to keep these units alive (and indeed that's one of the reasons I left Google). But these devices were designed in 2010-11. Even keeping the Linux kernel up to date with the latest version is a major undertaking. Adding major functionality like Matter compatibility, or even a simple (but secure!) local API, would take a seasoned engineering team a considerable amount of time.
That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.
Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent." It might be unfair, but on a day when Google Search, Youtube History Search, and (whaddya know) my Nest Thermostat have all failed me, the temptation is strong.
If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?
Even more pertinent, when it gets time to go through the promo process and when I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs, why would I want to be on a project supporting old legacy tech that I can’t spin to show how it helped the company’s revenue?
I’ve never worked for Google. But incentives based on the promo culture is endemic to all of BigTech.
And even worse, every company is focused on “AI” these days. If you aren’t part of an initiative that can be said to be AI adjacent, if you care about your career and comp, you shouldn’t touch it with a 10 foot pole.
I would expect a thermostat to last 15+ years across multiple home owners - it should be an improvement over a mechanical one, after all. If that's not adding to Google's bottom line, they shouldn't have "disrupted" that market in the first place.
> If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?
Empathy and being a good human being in relation to society. Making devices that look good at first and cause pain later, when it's too late to do anything about it... is bad.
> I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs
Fair, and that's a reason to _not_ put in the effort to make longer lasting devices.
> But incentives based on the promo culture is endemic to all of BigTech
And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.
Say the employee did want to work on the product in spite of it not being in their best interest. How are they going to get the buy in and the team to make the change and the support to get it pushed to devices in the field?
And no one works for a privacy invading ad tech company because they want to make the world a better place. It’s purely about making a shit ton of money.
> And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.
Despite the newest LP about being the best employer, Amazon has been the shittiest of the BigTech employer as long as I can remember. Their reputation hasn’t changed anything about their profitability or stock price.
Before you ask if I knew that, why did I work there. I was 46 at the time, it was my 8th job out of 10 and it was purely remote and a “field by design role” that was remote until a year after I left. It was purely a money and resume play.
> Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent."
Engineers don’t make business decisions on when to end support, that’s a management decision; engineers ideally ought to be consulted on what it would take to continue support, but even that isn’t guaranteed. If planned obsolescence has been a business strategy, literally having an obsolescence switch and pulling the trigger on it has to be tempting to certain decision-makers even when support would be practical.
I think the reality is that the engineers are competent but this was just not a priority they were given and they were not going to spend nights making this happen instead of hanging out with their kids.
They might even have gotten in trouble if they had rolled out an update that product management didn't ask for and is perceived to reduce incentive to upgrade to a new device
Let me turn it around. Imagine that you are a Google engineer who worked on Search, YouTube, or Nest. How would you feel reading your own post? You would probably vehemently disagree! I'm not sure your sentiment is relative in 2025. Everyone on HN knows that any "web scale" public product (with billions of users) 100s of engineers behind it. And, it takes very good ones to keep them running and continuously improve them.
Thus, in response to:
> It might be unfair
I say: Yes, it is unfair and unnecessary to post. It adds very little to the wider discussion.
Security is always the excuse, but it's a local device connected to Wifi. Add a setting to the existing menus that is opt in to turn on the new API.
Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.
For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.
"Even keeping the Linux kernel up to date with the latest version is a major undertaking."
To me this sounds always backward. We make a choice of tools, and now we can't support you longer, and blame it on the tools. It's like "I need a car because I've moved out of the city center." Yes, of course you need a car, but because of your choices and actions.
If you prioritize easier development over long term support when choosing tools, then this is what you get.
Of course it's ok and valid to make that tradeoff, but then don't blame it on the tools, but on your choices.
Nest made an implicit choice of tools back around 2010 when it selected the particular SoC that powers the early thermostat. Options were more limited then, and vendors often provides kernel tools and libraries that included proprietary closed-source components. Over the years most of these tools have been abandoned or EOLed by their providers (as companies will do). Keeping these tools working and building new releases of software in the context of a modern build environment is a full time jobs itself, especially in the context of Google with its highly idiosyncratic internal processes.
While I was at Google I complained bitterly about the repeated killing Nest products. But there was no way I had the bandwidth (or the permission) to serve as the sole lifesaver for any of them.
A bit of an unusual idea, but: if the users of such a thing are folks who're already playing with HA and are tech savvy, why not just expose the API and tell users that they're "only allowed to use the "hacker's update in good faith" if they put the devices on a separate network without internet access?
Your team doesn't need to spend a ton of time on making it super secure, and DIYers can continue to use the hardware for as long as it physically works, me thinks
Not a lawyer, but liability waivers may not apply if there is determined to be gross negligence or recklessness.
Making a reasonably-designed API available, only if connected to an inaccessible network, doesn't sound dangerous, but the goodwill gained might be hard to weigh against a miniscule chance of malware, which would revise everyone's opinion of the degree of negligence or recklessness.
I'd be worried about any internet-connected IOT device in my home. It the very least it can snoop on traffic. The Nest in particular could a) use it's motion detector to report if you are home b) harass you through temperature changes (and maybe even gaslight you by not showing them) c) maybe overload something (itself?) and cause fire?
That's just what I can come up with sitting here and having no in-depth knowledge. I am sure actual security experts could come up with more scenarios.
Absolutely nothing is stopping Google from keeping all the integrations working until the thermostats physically break. No one asked for a new kernel and whatnot.
Is keeping alive the infrastructure that servers the 1st and 2nd generation devices online and just proxy the communication between the old features and new features available in HomeKit and other smart home hub apps such as big undertaking that Google balked at it?
Okay, but isn’t this really about, why should Google spend money making things work better for iPhone users? It doesn’t like doing that. That’s what Matter support is really about. It’s always been about Apple Home.
And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?
> What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality.
The last dev who understands the code and the build tooling left years ago.
At least HVAC systems have a mostly standard control system and thermostats are easy to swap out. If a thermostat goes out of support and looses functionality, you do not need to replace the entire HVAC system; only the relatively cheap thermostat.
I'm contrast, while it is often possible to replace an infotainment system, the replacement needs to have been designed for a fairly specific set of cars, and actually installing it requires paying a mechanic for most people.
If your car is old enough to have a standard DIN radio, you can easily replace it with a modern CarPlay/Android Auto unit. And cars that are new enough to have CarPlay/Android Auto built in seem to be generally holding up. It’s really just cars from a specific window (after they started putting nav systems and screens, before adopting CarPlay) that age really badly.
In the early 2000s, even cars with oddball radios (like a CD slot adjacent to climate controls for example) could have an aftermarket head unit installed because dash trim kits were available to replace the proprietary layout with a DIN slot. Is this not the case for the era you mentioned?
I’m not sure what the problem is, but there are a lot of cars where you couldn’t buy anything off the shelf to fit a DIN radio. People on forums were hacking solutions together with literal hacksaws.
> Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units
I would never buy a car that doesn’t support CarPlay. The four protocols that Apple created to interface with non Apple devices - the original iPod protocol, AirPrint, AirPlay and CarPlay haven’t had any breaking changes. As of at least three years ago, I could use an old first gen iPad from 2010 (the first to support AirPlay/Airprint) and use it with modern Roku TVs with AirPlay support and modern printers.
My old 2011 Sonic that I had with a USB port that supported the iPod protocol for displaying titles for audio and controlling iPods still worked with every iPhone I had.
But I would never trust Google not to kill a device.
I got lucky with my 2011 Toyota because the inputs are standard Bluetooth, an aux port, and iPod-style USB. The display is also a VFD pixel display and not some crappy LCD with a resistive touchscreen.
Of course, new devices might use some incompatible Bluetooth standard in the future.
I don’t get who uses Nest or other non-first party thermostats anymore:
All modern furnaces/ACs/heat pumps require their own smart thermostat to work optimally. So if you install Bryant furnace, you end up with Bryant smart thermostat, and so on. In fact, when choosing new furnace/AC choose brand with good software in thermostat first and foremost - units themselves are pretty identical otherwise.
That really isn’t true. I have a split level heat pump with no thermostat, well, there is one in the remote control that sets a mini thermostat on each internal unit. Basically, we don’t have a central thermostat but that isn’t weird for Seattle.
Incidentally, I would love for a better remote control that was easier to use, we might use our heat pump more than a couple of weeks a year in that case.
Serious question: What does this mean? I'm such a dumbo about networking. Is it simple for an app to distinguish between "LAN" and "WAN" network requests?
Not all goods and services involve the same process, some come with more pollution.
For example, Nvidia will contribute to a big chunk of US GDP, but it only designs the chips, which won't have the same pollution impact as the country in which they'll have it manufactured.
I'd add that computing has changed in the last 5 years as well. The amount of actual apps a typical user installs is minimal. You really just need a web browser for most tasks, and obviously Linux can provide that.
Besides drivers for some weird hardware, the only daily application might be an office suite, which OSS still can't quite match the MS offering. However, I've found many are willing to deal with the differences given the licensing cost of Office.
The legal process already did all the hard work of reaching consensus/compromise on where that line is, so just use that. At least with the legal system, there's some degree of visibility and influence possible by everyone. It's not some ethics department silently banning users they don't agree with.
reply