zlacker

[return to "Haier hits Home Assistant plugin dev with takedown notice"]
1. elkos+ya[view] [source] 2024-01-18 18:28:55
>>linker+(OP)
I wish there would be an appliance manufacturer that would actually hire developers to create and maintain Home Assistant.
◧◩
2. superg+bf[view] [source] 2024-01-18 18:46:39
>>elkos+ya
Home Assistant users are small minority of many of these companies user bases (including ours), and these integrations being locally focused often poll HEAVILY causing an upside down ratio in API traffic compared to all other users.

The solution is to allow local interfaces (matter, HTTP, etc) but most company cybersecurity teams just freak out at this.

Oh, and the reason we don't have a full time team managing HA is like I said.. addressable market versus FAANG/Samsung.

It takes a full time person (persons) to manage Alexa, Google, Samsung, etc.

◧◩◪
3. stefan+Tg[view] [source] 2024-01-18 18:54:11
>>superg+bf
Why would the cybersecurity freak out at that, that seems opposite. The company owning the data (and controls!) is much more of a risk.
◧◩◪◨
4. superg+mh[view] [source] 2024-01-18 18:56:04
>>stefan+Tg
Don't ask me to explain the mindset of your average "tool runner" cybersecurity person.

I've long advocated a local HTTP interface for our products, but usually a losing battle.

◧◩◪◨⬒
5. kube-s+Dn[view] [source] 2024-01-18 19:27:42
>>superg+mh
>local HTTP interface

A lot of the worst IoT vulnerabilities in the past have been due to exactly that. 'Local' unfortunately isn't something decided at design time, it's decided when someone connects it to a network. Most people plugging these devices in don't have any clue how to simultaneously secure them and connect them to the internet, so they often end up directly on the internet with default credentials or with outdated vulnerable software and a port open. That's the biggest reason all of the major players now just close all inbound ports and reach outbound to a cloud service. It checks both boxes of usability and network security with even the most misguided user.

Yes, this arrangement sucks for people who know better. But we aren't the people in the user stories.

◧◩◪◨⬒⬓
6. superg+Fp[view] [source] 2024-01-18 19:37:44
>>kube-s+Dn
Even though I advocate for a local interface, I also completely agree with your statement.

But, the alternative is we either accept this completely upside down API traffic ratio with locally focused integrations (bad, costs lots of money) or allow a local interface.

Another potential workaround I advocated for was a "cloud down" message that could enable the local interface for those that ONLY go looking for how to do it.

◧◩◪◨⬒⬓⬔
7. kube-s+TL[view] [source] 2024-01-18 21:18:59
>>superg+Fp
With my developer hat on, I agree.

With my business hat on, I'm not so sure. "Why are we spending development resources on a feature that isn't valuable for our target users?"

I could definitely see doing this if it were a product with a prosumer-type angle to the value prop. But for the devices we see on the shelf at a big-box store, I don't think those companies' management considers that valuable.

[go to top]