Haier Europe Eases Off on Legal Threat and Seeks Dialogue
hackaday.com
hackaday.com
https://corporate.haier-europe.com/press-release/hon-app-a-m...
It never ceases to amaze me how someone (or more likely some team) can write something like this and consider it an effective, or even just desirable, form of communication. The message is devoid of all signs of actual humans communicating.
It's all empty corp-speak.
Nothing about the reason this message was posted; no summary of what happened and what they perhaps did wrong. No explanation of how their actions came about. Even just “The API usage spiked; we freaked out and went straight to legal threats. We shouldn't have done that.” would feel less generic.
Had Haier reached out and asked the dev to optimise their HTTP calls, or perhaps adviced him on what kind of call pattern their cloud servers were optimised for so that costs could be kept low, Haier wouldn't have received all this bad press. Like many reverse engineered APIs, the HACS plugin probably does a whole bunch of inefficient API calls because there's no way of knowing what API calls are cheap and what calls are expensive.
Haier could've gone further, and set up a dialogue to include a Haier component into Home Assistant directly, and slap a "works with home assistant" logo on their products' website. I'm no market analyst, but I'd be surprised if Haier wouldn't turn a profit on implementing official Home Assistant support.
- Management sees cost spike, asks Sysadmins
- Sysadmins investigate and say "not our fault, it's them pesky commie devs"
- Management rings up legal, shenanigans ensue
If this is the real reason, how long can you expect Haier to support the API free of charge for existing customers? Not very long I bet.
The only sane solution are applicances that can be controled locally without an internet connection.
It would be great if we could go further and demand that manufacturers release the specs for their communications protocols if they exceed a threshold of unit sales, since they're effectively making a bunch of devices landfill fodder when they turn off the servers within the viable lifetime of the dependent devices.
There's cool stuff out there I'd love to buy but once I see it requires an Internet connection it's a no-sale for me.
(Even being locally controllable isn't a win if that comes with the requirement of running a closed source native "app". I'm still sad about some 32-bit iOS apps that Apple says I can't run on newer devices. I don't want to keep nursing an iPhone 3 along to be able to control a home appliance because the manufacturer figured out they can tie their product lifecycle to Apple's user-hostile backwards compatibility policies.)
Sometime in the last 20 years the tech industry became a game of tempting me with cool features and then snatching them away, versus the exciting progress I remember from the 80s and 90s. I'm sure getting older is part of it, but I can't imagine shaping my habits around technology that can be taken away from me at any time would appeal to me at a younger age either.
Or just support a local API with a published spec. Matter is supposed to be that standard, but adoption is going slowly. Pretty sure zero people using the original reverse engineered cloud API for the Haier stuff in HA want to be using it in preference to a local API.
This seems naïve: "Yes, it's making money, but it isn't making enough money" is the phrase on the tombstone of a lot of goods, services, and come down to it, countries through history. Being a customer is no guarantee you get to keep being a customer.
> and drive manufacturers to make locally-controllable devices to appeal to price-sensitive consumers.
"Special Deal: Comes With Free Six-Month Subscription With Purchase!" because six months is how long they intend to support the device, after which they turn off the service and brick all of them, and of course you can't opt out of the special deal because they don't get any of your data from a device that isn't slaved to their servers.
I'm jaded enough to know it's not a panacea. It's further along the spectrum from "This is costing us money..." at least.
Collective action would end this problem overnight, just like it did here (although I think they are insane for buying cloud appliances in the first place).
What boggles my mind is how the average person seems so accepting of this. I get this pervasive sense that because "it's computers" or "computer adjacent" it's a given that you'll have to accept loss of functionality as devices age.
I guess it needs to get a lot worse before it gets better.
Needs to isn't the write term... Going to get a lot worse is going to happen. Getting better, well the issue is in doubt.
They don't know much about how those things work. They do know if they're losing functionality even if they don't know how they work.
My observation is that people seem endlessly patient about losing functionality in computer adjacent devices-- far beyond what they would tolerate with other devices. I simply don't understand why this is the case.
For virtually every consumer good there is some ability for independent repair. I think people would be up in arms if their car stopped working and the manufacturer said "Yeah, you just need to buy a new one". We have consumer protection laws in the US to prevent this very thing.
With software connected to "smart" devices there are no significant protections. I don't think people even know to be up in arms about a device that doesn't work because it's "old" and the native app stops working or the Internet hosted servers went away. Worse, they just landfill the device and go buy the newest one.
I assume it has something to do with the subsidized nature of smart phones and relatively short time people stick with a given phone. The "wow" factor of new technology probably dazzles people into forgetting about long-term usability too.
Hopefully when the "throwaway" mentality of smart phones really starts to cost people (as more durable good type "smart" devices embrace this model) we'll see some public backlash.
The relevance to this situation is that PetNet made a pretty good pet feeder about 5 years ago. It dispensed well, had a good app, and mostly just worked. Then, during 2020, the company just disappeared. The app stopped working, and eventually, the feeders stopped feeding. I tossed mine into the ever-growing box of "I'll get to it later", and forgot about it for a few years.
Getting it up and running wasn't tremendously difficult, and now it works almost as well as it did when its new, working significantly better in one critical area: Instead of having to sign into some other random app and fiddle with it there, I can just press a button in HomeAssistant and my cat gets a bunch of food. Maybe later I'll wire in things like the hopper sensors, scales, and other features that the device had, but for now a 1 second pulse of power works well enough
There's not really any valid reason PetNet couldn't have just released the firmware flashing keys on the way out. The device likely runs on a microcontroller very similar to ESP32/ESP8622, and so had those keys been available, I could have used the "native" hardware.
I suspect the overwhelming majority of these feeders wound up in landfills, as very few people, even the technically competent, are willing to take it apart, solder in a new control board, and get said board up and running. Which is an absolute shame.
[1]: https://pdx.su/blog/2024-01-19-fixing-a-broken-smart-cat-fee...
Agreed. I wish companies would take the work already done for them with Matter and just integrate, but if they can't, the least they could do is support the things customers to do the things they want to do.
The only thing I can think of is someone outside of the "knowledge chain" caught wind of it and just fired of the legal threat.
For instance, if I told some people inside my company how much traffic HA uses in terms of how many users are on it they'd probably freak out like this too.
But their reason (cost and traffic) is the biggest reason we don't like it either.
So stop building cloud-only device interaction then... Home Assistant users will take a LAN API over a cloud API any day.
A LAN API should satisfy everyone really, no unnecessarily large bills for the manufacturer, and Home Assistant users can get better/faster integrations with shorter update intervals.
Security by obscurity is another phrase for it.
Local API for control, then submit telemetry via the cloud-version of the API they use for the app.
The obvious answer why not is: it enables people like me to just block the telemetry uploads.
But they can't have it both ways then, they can't make inefficient cloud-based control mechanisms, and then complain when people (ab)use them, because the truth is that that will not stop no matter how many cease and desists they send.
- Reading information from utility providers which few people are able to measure locally
- You want to integrate with some system which is physically outside your home, like I don't know a smart mailbox if those exist (and god damnit now I want that...)
- You are forced to because the product you have can't be controlled any other way and it's not feasible to replace it
- A locally controllable version of X exists, but it's three times the price of one from vendor Y which requires a cloud integrationI've seen a few people DIY them. You can put a reed switch or similar on the door, and watch for state changes, to trigger a "PostBox opened last at" style sensor, or use a light sensor in the box to do the same.
If you want to seriously over-engineer, you could put the box on a load cell, and measure the weight of the post.
Use an ESP32 for your control board, and its pretty much just basic ESPHome plumbing
But I appreciate the suggestions!
Get everything into HomeAssistant, build dashboards, have cool stats and automations tying stuff together. Increases the family-acceptance-factor as well, as its a hell of a lot easier to say "Everything is in this app on your phone" rather than "ok well the washer is in the Miele app and the lights are in the Lutron app and the sprinklers are the…" If something is cloud based, so what, you can still get it into HomeAssistant. Sure, local is better, but thats a secondary concern over just having it there to begin with.
Additionally, one might observe that you can make a "cloud-only" smart device local control with varying levels of intrusiveness from custom hardware devices. You can stick an ESP32 with a current loop around the power leads on a washing machine, for example, to track when the machine stops running. You could use a light sensor taped over the "DONE" light to do the same. But these are passive, observation only controls. What if you wanted to start the machine too? Or observe where in its cycle it is. An ESP based controller gets a hell of a lot more invasive, and your wife/partner might not be too happy that you just took apart the $2000 washing machine to stick a $2.50 "computer chip board" inside it.
Ideally, we'd all have everything 100% local. I'll even go out of my way to buy things that not only have local control over things that have cloud control, but within limits. Its a checkbox on a comparison sheet, not a be-all-end-all. I'll even favor things that use HTTP based configuration/APIs over apps and stuff (see the UnfoldedCircle remote, which is 100% browser configured) becuase its one less thing to have to worry about
Normal users don't want a LAN API though. They want an app that works. They want an app that works, and keeps working, even if their WiFi access point has client isolation, or their phone decides that it doesn't like the WiFi and switches to a cellular connection. They might even expect the app to work while they're not at home, and they certainly won't set up working NAT for it.
That means that the vendor has to implement a cloud API for the majority of users. At that point, it's probably cheaper to only have their app use that cloud API, even if the devices are on the same network and could see each other, simply due to the complexity of switching and maintaining the extra logic.
So the LAN API would be a completely separate feature that would have to be developed separately, and without extra effort, it would likely quickly go stale or break because there are no official use cases exercising it. That means a lot of spending for a small subset of users.
As much as I'd want a local API and would likely avoid most cloud-only devices that I can't somehow convert, I understand why vendors do it.
This aligns with the companies interests too because after they've built that they'll have somewhere to upload telemetry to.
The presence of a cloud API doesn't rule out a LAN API. The control functions exist regardless, just expose them to both the cloud and on the LAN. You could even use the cloud integration to provision authentication for the LAN API (although I'd much prefer a fully local version personally, but I'll take that compromise).
> That means that the vendor has to implement a cloud API for the majority of users. At that point, it's probably cheaper to only have their app use that cloud API, even if the devices are on the same network and could see each other, simply due to the complexity of switching and maintaining the extra logic.
Yep, that makes sense, still doesn't make having a LAN API for users to play with themselves in any way a problem, the device functions still need code somewhere to run, and exposing that code in two APIs is only marginally more work than once, the bulk of the work is in the endpoints/functions themselves.
You could even simplify the process by only building a local HTTP API, and then contain the functionality that communicates with the cloud in a single binary that just makes local HTTP requests and relays the response to the cloud.
> As much as I'd want a local API and would likely avoid most cloud-only devices that I can't somehow convert, I understand why vendors do it.
I'm not gonna lie or pretend to be naive, I understand as well, it's just that as a developer myself I know how I'd do it to provide both with minimal effort, and when I read articles like these it makes me mad because the engineering effort to get them out of this situation is tiny in comparison to the shitstorm they create by making it a legal issue.
I honestly think there needs to be some piece of regulation written about selling devices that require an online backend, because we've seen time and again how devices become non-functional because the company goes bust. That regulation should stipulate that any cloud-based functionality must be replicatable by a device-owner via local control.
Or, god forbid, contributed to the open source code repository in a way beneficial to all.
From https://www.redpacketsecurity.com/haier-hits-home-assistant-...:
> The plugins offered in the GitHub repositories enable users to control Haier, Candy, and Hoover air conditioners, purifiers, dishwashers, induction hobs, ovens, fridges, washing machines, and dryers through Home Assistant.
> According to a notice published by the repository owner, Haier claims these plugins cause the firm significant financial damage and violate copyright laws, requiring the developer to take them down to avoid further legal action.
But, I suspect that this whole event might go differently if the community response was slightly weaker. I'd rather thank the community, not Haier.
Haier should probably start handing out real money to those independent devs who's still willing to work on their appliances after this.
Literally nobody has a problem with that. What many people don't like is Russia's government and the way it's behaved towards everyone around them, for a few centuries at this point.
Go shill somewhere else, troll.
China is not your friend.
Also, maybe it's true that the entire thing was caused by one (I quote it from your comment) "European ... dirtbag", but that assumption is as true as almost any assumption under this context.
When I (and most people, really) criticize an international company, I'll not single out one of their local branch. When you criticizing Apple, will you specifically direct your complain towards say Apple UK? Why don't direct your anger towards the very top, where the power of uniformed change is concentrated? That's the most effective way of bringing changes out for everybody.
Haier Europe's main complaint was with the Home Assistant plugin's use of APIs running on Haier's servers. That's not a copyright issue, and so appears to be out of scope for 2009/24/ec.
Haier issued the takedown notice specifically on copyright grounds. Google and Oracle already battled this one out, and it was decided that using an API is fair use. This is probably the rule of thumb now barring exceptional cases.
From the original letter they sent [1]:
>> We are writing to inform you that we have discovered two Home Assistant integration plug-ins developed by you (https://github.com/Andre0512/hon and https://github.com/Andre0512/pyhOn) that are in violation of our terms of service. Specifically, the plug-ins are using our services in an unauthorized manner which is causing significant economic harm to our Company.
From their subsequent correspondence also shown on that page:
>> Recently, we've observed a substantial increase in AWS calls attributed to your plugin, prompting the communication you previously received as standard protocol for our company,
This is true:
> Google and Oracle already battled this one out, and it was decided that using an API is fair use
but not really relevant here. It just means that if you copy someone else's API that is not a copyright issue. It does not mean you have permission to call an implementation of that API that is running on their servers. That is out of scope as far as copyright goes.
[1] https://github.com/Andre0512/hon/blob/main/takedown_faq.md
> We take the protection of our intellectual property very seriously
The copyright implication is clear, even if probably it's just being used because copyright complaints are overpowered (right up there with terrorist/pedophile). Their real complaint is "it costs us money".
They directly cost more than they bring in. However, they're also:
1) Thought leaders / influencers. How you treat them translates directly into blog / forum / etc. posts.
2) Innovators / bounds-pushers. This can impact future products, market research, etc.
3) Ecosystem builders. Network effects!
It's a complex conversation. Apple courted education for much of its early history, not for direct profits, but so people entering the workforce would be trained on Apple. Balmer said "Developers, developers, developers!" even though developers cost money.
Now this customer was one of those 'you really do not want to make them mad as they will make full page ads kinda companies'. But the fun part it was not even all of their devices (which had a flaw) it was like 10 locations where they had the devices (out of their huge fleet) that was causing us 80% of our traffic. Their device would setup a call squirt the data and hangup. These devices were doing that 20k times per hour. Most other devices we supported were maybe 10-15 per day. Being the 'big co' they were they blamed us. Being another 'big co' though we were like if you do not fix this we will walk on your account. That worked because this thing was a big deal for them. It could have easily gone the other way and damaged our whole product line.
The solve was to properly moderate their calls and batch the data.
Also it is dead easy to get this sort of thing wrong. From a programmers PoV send data. Under all of that could be a queue (hopefully), some sort of ppp connection and all sorts of interesting machinations. Yet the programmer PoV it is just a tcp setup, send, and close out cycle. Then there are things like 'do you really need to send all of that data?' 'does it really need to be human readable json?' 'have you tried this in your target environment and not some developers desktop yet?'
If the company saw it any other way, they wouldn't be sending frivolous legal threats to those trying to bypass their app.
There is literally no incentive to have customers do well. I've seen a ton of frivolous litigation due to having legal strategy defined by outside counsel.
Internal counsel, charitably, at least, has employment and gets to slack off if there's less work. Outside counsel wants those hours.
There's a complex story about:
1) IANAL disclaimers and why it's often important to consult a lawyer rather than assuming you know the law
2) What NOT to trust lawyers on. This is much more than whether or not to sue; no lawyer ever got in trouble for being too conservative.
Business decisions like this one should not be made by lawyers at all. Lawyers, inside or outside, should explain what the law is, but the decision should be made by someone who can do math on things like risk and ROI, and who understands brand value / impact on the above of any action.
Thw chances of this is not naximised if you are fired. I imagine the person who sent the original letter isn't exactly viewed as 'trusted counsel' at the moment.
The consumer laws in China don't work the same way compare to (say) the one in the US. Chinese user often only permitted to use the product as-is, if you developed and/or published a tool that could change how the product function, and the company produced the product deems the change undesirable (say, it hurts their profit), the company then has all the rights granted by laws to force you to take your tool down, as well as ask you for compensation and/or even escalate it to criminal charges. Company might (likely, actually) choose not to do that, but if they really wants to, they can pursue it to that end.
That's maybe why Haier claimed that the project in question "harms their business model", which is a legal ground often used in lawsuit against Chinese developers. This case is a little bit more trickier since the project calls Haier's private API, because of that, according to Chinese laws, the violation could ranging from copyright infringement all the way to cyber attack (thus Haier claimed "violate copyright laws").
E.g. Haier could claim that the API is a trade secret that the HA integration is using illegally, or that by accessing the API, Haier's domain name is being used without authorization (though I think this is intended to combat impersonation where someone registers a domain with their competitor's name) etc. etc.
Funnily enough, it also outlaws "causing, in bad faith, incompatibility with an internet product or service lawfully provided by another business entity".
Did you miss the 'Europe' bit? They have presence in the UK, Italy, Romania and Turkey (not quite Europe, but close enough). They also have presence in China but Chinese consumer laws do not apply to EU subjects.
China doesn't rate a mention.
What does rate a mention is Haier's own people being on the record that their HON app is such a failure that the bulk of the traffic is generated by the HA plugin, which actually is more economical network wise than Haier's app. Also notable is the fact that they are talking out of both sides of their mouth, they claim they love 'open' and 'API' use but at the same time would like everybody to use their app, but since it is (1) crappy and (2) closed source and so not easily integrated it is logical that the people that need it chose to roll their own.
It's remotely possible that there is an instruction from China to Haier Italy that they needed to take action but you'd expect there to be some mention of this. Finally, from a security perspective you really don't want your appliances to send data to the rest of the world, China or otherwise.
edit: And finally: if they didn't make their appliances cloud connected but instead allowed for a local only version then I'm very sure the HA people would be ecstatic and the whole problem would go away. Why anybody would buy an appliance that requires a cloud connection is beyond me.
By definition, they are using MORE platform/API traffic than the average user and not paying more.
You don’t seek a dialogue after, figuratively speaking, putting a gun to someone’s head. Hell no, you don’t say it was a joke when the gun misfires.
They seek dialogue today, and tomorrow some beancounter from the legal department will pull this shit again to get their quarterly bonus. Heck, a company may have a written promise to never do stupid shit and then they renege on it because they feel like it.
Publish code under a non-revocable license like GPL, then we talk.
In the meantime, fuck Haier, fuck their legal department, fuck their PR team, and fuck the air conditioner they rode in on.
On the other hand, many companies act badly without realizing it and genuinely try to better themselves after understanding why what they did was wrong. (This is particularly common with security reports, with a threatening response first then a more reasonable response once someone who knows how to properly handle disclosures talks to management.)
There needs to be a balance - if there are no consequences for getting it wrong initially, many companies will try the bad way first and only backtrack when they get caught, but if we apply the standard that there is no possibility of redemption, a company would have no incentive to improve once they screwed up the first time.
There had been cases of the same companies doing several oopsie-daisies in a row. I can only be sure they can and will pull that shit again and again, and having done this once is proof enough.
The parable of the frog and the scorpion exists for a reason.
The only way a company may do something to prove they mean it is to do something they really cannot back away from by any reasonable means, not without paying a devastating cost.
And thus my point above about Haier still stands.