Live data from Hacker News

Haier hits Home Assistant plugin dev with takedown notice

bleepingcomputer.com

171–172 of 172 posts

Re: Haier hits Home Assistant plugin dev with takedown notice

#171

I'm in the process of reverse engineering an appliance myself to allow it to be integrated with Home Assistant, one which requires an mobile app to operate remotely and is connected to the net all of the time, when it doesn't need to be. I was gifted this particular appliance, but the solution is really to just not give companies like this your money. Unfortunately it's easier said than done, but looking for things w…

If some company sells stuff that requires a connection to their cloud then it is 100% fair game to reverse and utilize that cloud to get the product working the way you want. They have no right to be upset about that. They sold you a requirement to connect to that cloud. If they don't want anyone connecting to their cloud, then don't sell cloud connected junk.

I think the issue, particularly in the case of some of the companies that have been hostile to Home Assistant integrations, is that, according to them, the small number of users with reverse engineered access to their cloud, tend to abuse the API by creating a significant percentage of the traffic, presumably by accessing it "incorrectly".

I agree with you wholeheartedly that it should be fair game, but ultimately, if reverse engineered users are creating, say, 50% of traffic[0], because they're polling instead of using the proper push mechanism, these sorts of companies can and will get upset.

Frankly, as a backend software engineer myself, if any system I built with the purpose of being constantly accessed by a fleet of devices sold on the open market couldn't handle the relatively tiny numbers MyQ created a fuss[1] over, I'd be embarrassed.

[0] https://chamberlaingroup.com/press/a-message-about-our-decis... [1] https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...

Re: Haier hits Home Assistant plugin dev with takedown notice

#172

Earlier quoted context omitted.

> 'Local' unfortunately isn't something decided at design time, it's decided when someone connects it to a network. It's obviously connected to the public internet when it talks to cloud servers, and that's somehow (claimed to be) secure. Comparing a good cloud API with a poorly designed local API is a false dichotomy. Would you set up your cloud servers with default credentials of admin:admin? Have a hidden physical…

There's a at least a dozen ways for set up a secure local API. Whether it is possible was never the question. The question is whether Joe Blow can pick one up off the shelf at Best Buy and successfully implement it. The answer to that question is no. Joe Blow wants to download the app, click the button, and make it work. This is 99.999% of the users that buy something off the shelf at the big box store. Asking why a…

> Joe Blow wants to download the app, click the button, and make it work. This is 99.999% of the users that buy something off the shelf at the big box store.

And I don't dispute that, this option should remain available. What I dispute is the idea that the lack of local control is somehow beneficial to the end user by "protecting" them from vulnerabilities.

The only thing such arrangement is protecting is the manufacturer's bottom line, by allowing them to 1. harvest and sell data, 2. take away features or start pushing upsells when they need to boost their quarterly profits.

> Asking why a Haier dishwasher doesn't have a local API is like asking why a Toyota Sienna doesn't have configurable launch control, power-take-off, or a fifth-wheel.

Well that's just ridiculous, all of those features have significant per-unit cost to implement. Exposing some form of local control would take, if we're being generous, a couple of person-weeks of effort and it would cover the entire product line with a marginal per-unit cost of a single switch.

Post reply on HN