Chamberlain v. Home Assistant [LWN.net]

The developers of Home Assistant, which has recently been covered here, have announced that they will be removing support for Chamberlain and Liftmaster garage-door openers after being locked out by the company.

Because we cannot continue to work around Chamberlain Group if they keep blocking access to third parties, the MyQ integration will be removed from Home Assistant in the upcoming 2023.12 release on December 6, 2023. We are very disappointed that it has come to this and sincerely hope that Chamberlain Group is willing to reconsider its position.

Longtime readers may remember that Chamberlain tried to use the DMCA to block the use of third-party remotes nearly 20 years ago.

to post comments

Chamberlain v. Home Assistant

Posted Nov 8, 2023 18:52 UTC (Wed) by ringerc (subscriber, #3071) [Link] (4 responses)

I'm expecting to see more and more of this as companies consolidate their hold on "their" products - that you happen to have have purchased and have in your home.

Philips / Signify is currently in the process of locking down the Hue system "for your security". They refuse to explain how this actually improves your security. Emails are replied to with generic copy/pastes. It's a grab for control and it's being shoved down the throats of existing customers. They're attacking direct, local management via wifi and trying to force everything through their cloud.

My 8 year old bridge is getting a forced update from Philips, presumably to remove my owner control over it. I firewalled it off from direct Internet access, but the app now refuses to talk to it unless I apply the update. If I downgrade the app it refuses to run after checking in with Philips servers. I can firewall that access off but it persistently killswitches itself if it gets Internet access via mobile to bypass the firewall.

The various release notes etc say nothing about any of it.

Absolutely disgusting behaviour, but the only unusual thing about it is that I had any cloud-free ownership or control in the first place.

Chamberlain v. Home Assistant

Posted Nov 8, 2023 20:54 UTC (Wed) by Karellen (subscriber, #67644) [Link]

You forgot to air-quote "purchased"

ha ha, only serious.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 3:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Philips / Signify is currently in the process of locking down the Hue system "for your security".

They apparently backed off a bit, the local API will be available and users will be able to disable data sharing: https://www.theverge.com/2023/9/28/23892761/philips-hue-a...

Fortunately, Hue bulbs are ZigBee, so there's nothing special needed to control them. Any modern hub will work.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 6:59 UTC (Thu) by oldtomas (guest, #72579) [Link]

This is just phase 3 ("adaptation") in Zuboff's dispossession cycle. Business as usual.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 17:08 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

It’s not just automation companies.

Vendors have discovered modern crypto is cheap. As a security measure it was overhead, as a lockdown antifeature tool it’s dirt cheap. They’re all in the course of locking down all their products to block third party-compatible hardware and software.

Basically with a minimal crypto implementation you can make it so your chip refuses to pair with anything that does not present a signature signed by the vendor. Digital signatures are delivered to the hardware via a custom mobile app as an aftersell process that checks you have bought “original” hardware from an “approved” reseller.

It‘s all the badness of DMCA abuses with teeth now that tech advances have made it possible to apply strong locking down indiscriminately.

To make sure customers accept the lockdown you need to make the mobile app useful for something else than delivering lockdown signatures. To make the mobile app attractive you need to kill alternatives.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 7:03 UTC (Thu) by oldtomas (guest, #72579) [Link] (6 responses)

Remember when you had to have a hardware dongle to your software? The roles seem to have been swapped now.

Remember when they said "if you don't pay for it, you aren't the customer, you are the product"?

- one thing has changed: nowadays it doesn't seem to matter whether you have paid or not.

- another has become clearer: you aren't the product, you are the means of production (think livestock, cabbage patch).

Chamberlain v. Home Assistant

Posted Nov 9, 2023 14:18 UTC (Thu) by smoogen (subscriber, #97) [Link] (5 responses)

I like that new quote: "You aren't just the product, you are the means of production."

I think it also comes down to 'you get what you paid for.' or 'if its too good to be true, it ain't true'. Most of these devices have been sold at prices to get them into people's homes and most of the people buying them not reading the fine print about what you are actually 'buying'. Now the fine print is getting used to get back as much production as possible.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 0:51 UTC (Fri) by ringerc (subscriber, #3071) [Link] (1 responses)

Some of them really haven't though. Both Chamberlain remotes and Philips Hue are pretty premium priced.

It doesn't even matter if you choose the premium product without the forced cloud tie and obvious subscription bait and switch. Because now these companies can change the rules on you after you bought it and you have basically no recourse.

Mobile platforms and stores make it very hard to keep the old version of the control app. It'll be incompatible with a new OS release in no time. And it'll have a phone home to check for updates that killswitches the app anyway. This makes it hard to just refuse to update anything and keep using the last version that worked.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 2:40 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

The MyQ module is $30 and includes things like a strobe LED to alert to closing doors, I don't think it's massively overpriced compared to the hardware involved. It's somewhat inherently cloud based (the major selling point is "I'm a couple of miles away and I want to know whether I left the garage open") so if the income is marginal per unit and upkeep is expensive then it's unsurprising that they'd look at ways to reduce costs and generate additional revenue.

Of course, one way they could have reduced costs is supporting push notifications over something other than phone native platforms, and then people wouldn't be polling every 30 seconds. Failure to do so is clearly wanting control over the platform.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 7:14 UTC (Fri) by oldtomas (guest, #72579) [Link] (2 responses)

"you get what you paid for"

If that phrase is intended to mean that cheaper products surveil you harder, times have changed.

There is even one premium product line which blazed the trail: Apple with its iTunes "ecosystem": they even sport the humour to sell it as "privacy enhancing" -- I always liken it to the farmer protecting their cows from parasites, which of course are always the others.

There's another premium: Tesla. They milk every sliver of data they can from you. Valuable data to train autonomous car algos.

I'm sure we can find more if we look.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 8:24 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

> There's another premium: Tesla. They milk every sliver of data they can from you.

You can opt out. The car works quite well without connectivity, entirely unlike the cloud-mandatory and app-only nonsense certain other companies require for a goddamn light bulb. Or, in this case, a garage door.

> Valuable data to train autonomous car algos.

So? if you don't want to share your data, turn that off.

Granted that Tesla could be somewhat more transparent WRT their data use. On the other hand, the cars do have an API which, while neither cloud-free(*) nor documented officially, is stable enough to support several third-party solutions, Home Assistant included. They don't lock anybody out, and until they do (which IMHO they won't) they're not the bad guys in the context of this article.

* don't know about you, but my garage doesn't have WIFI …

Chamberlain v. Home Assistant

Posted Nov 12, 2023 8:55 UTC (Sun) by oldtomas (guest, #72579) [Link]

Me? My WiFi has no garage...

Chamberlain v. Home Assistant

Posted Nov 9, 2023 12:07 UTC (Thu) by nye (guest, #51576) [Link] (5 responses)

I don't understand why they would be blocking third party access. If there is a third party tool that increases the value of your product, without you having to invest any time or money, then what's the business case for investing time and money to stop it? Do they just hate making money?

Chamberlain v. Home Assistant

Posted Nov 9, 2023 13:17 UTC (Thu) by excors (subscriber, #95769) [Link] (3 responses)

The Home Assistant integration is not local, it's still communicating with the device through the myQ cloud API, so it does require some time and money from Chamberlain. They say: (https://chamberlaingroup.com/press/a-message-about-our-de...)

> Unauthorized app integrations, stemming from only 0.2% of myQ users, previously accounted for more than half of the traffic to and from the myQ system, and at times constituted a substantial DDOS event that consumed high quantities of resources.

so it sounds like they'd rather accept the cost of losing <0.2% of users than spend enough to make their system more robust.

It has also been noted that Chamberlain's Android app has ads, and pushes their video storage subscription service. (Some of their garage door openers have built-in cameras, so you can remotely open your garage for a delivery driver and watch to make sure they're not stealing from you). And the Home Assistant post says:

> In their partner program, the partner companies pay Chamberlain Group for the privilege of letting MyQ owners control their own garage doors.

So Chamberlain is making money from both first-party and official third-party apps, but not from Home Assistant (beyond the initial purchase of the product), so they probably see HA users as less valuable than regular users and not worth the hassle.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 16:54 UTC (Thu) by nye (guest, #51576) [Link]

Wow okay that does explain it, and it's a lot more awful than the general mindless idiocy I was expecting.

So it literally is a case of "even though you're paying for the product, you're still the product" as one of the other comments alluded to.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 9:05 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (1 responses)

> > Unauthorized app integrations, stemming from only 0.2% of myQ users, previously accounted for more than half of the traffic to and from the myQ system, and at times constituted a substantial DDOS event that consumed high quantities of resources.

I was about to ask if they were running this thing on a 386 with a dial-up line...

> It has also been noted that Chamberlain's Android app has ads, and pushes their video storage subscription service. (Some of their garage door openers have built-in cameras, so you can remotely open your garage for a delivery driver and watch to make sure they're not stealing from you).

That explains why it's possible for API users to take up significant resources on their side. But I'd still argue they're incompetent (or, more likely, deliberately controlling and greedy). P2P streaming has been a solved problem for ages, and at least since WebRTC has become commonplace, it's something that lots of normal everyday home users do (without the - undeserved - stigma of BitTorrent etc). So ISPs can't just block it or they'll be flooded with complaints from a lot more customers than those with these garage openers. And even if they still supported a proxy mode as a fallback, for most users WebRTC would probably simply work, reducing the load on their system.

> So Chamberlain is making money from both first-party and official third-party apps, but not from Home Assistant (beyond the initial purchase of the product), so they probably see HA users as less valuable than regular users and not worth the hassle.

So this is the real reason. For them, the thing that's not working right is not their API. In their eyes, what's not working as designed with these customers is their business model.

All in all, more than enough reasons to stay well away from this company. Shenanigans like this are one of the reasons I'm suspicious of 3rd party mediated remote access services, and I completely refuse to use any such things that would cause anything more than a minor inconvenience if they stopped working.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 12:36 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

>I was about to ask if they were running this thing on a 386 with a dial-up line...

As if rate control was an unsolved problem and as if it was more complex to add an access fee to the mQ system than trying very indirect strike gold via antifeatures.

Chamberlain v. Home Assistant

Posted Nov 9, 2023 16:45 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Closed vendor software/firmware devs hate third party tools, it makes them look bad when it is better, it will expose bugs they paper over in their own implementations, they fear their company will force them to contribute to some open structure where the tech decisions are made with someone else and they fear contibuting to some open structure will lead to one form of downsizing or another.

Closed vendor marketeers are convinced that if they manage to build some form of closed garden they will strike gold one way or another by feeding antifeatures to their captive customers.

Closed vendor management has no opinion but will follow the advice of its tech and marketing heads.

Chamberlain v. Home Assistant

Posted Nov 10, 2023 7:07 UTC (Fri) by MortenSickel (subscriber, #3238) [Link] (10 responses)

And a few Australians learned this week why it is a Bad Idea to have the lack of internet access turning smart homes into really stupid homes...

https://www.theguardian.com/business/2023/nov/10/optus-we...

"Marayke Jonkers first realised something was wrong when all her bedroom lights turned on early in the morning. All the devices in the Paralympian’s home are smart – they need the internet to work. When the internet went down, the lights went on and she couldn’t turn them off."

Chamberlain v. Home Assistant

Posted Nov 10, 2023 14:40 UTC (Fri) by eduperez (guest, #11232) [Link] (9 responses)

This is why it is so important to use local-only integrations, and ensure that everything has a physical switch.

Chamberlain v. Home Assistant

Posted Nov 11, 2023 7:00 UTC (Sat) by ssmith32 (subscriber, #72404) [Link]

Agreed, and adding a physical switch via a surge protector is usually trivial, but per the article, having the lights voice controlled took on additional importance due to the paraplegic state of the owner.

Chamberlain v. Home Assistant

Posted Nov 13, 2023 17:06 UTC (Mon) by nye (guest, #51576) [Link] (7 responses)

> This is why it is so important to use local-only integrations, and ensure that everything has a physical switch

They almost certainly had a physical switch - at least it's hard to imagine another scenario. When they failed, they deliberately failed safe, becoming non-smart devices, which were therefore on. People often get very upset about smart devices whose fail-safe behaviour is to act as close as possible to the non-smart version of that device, but IMO this is categorically correct, and any other choice has some indefensible failure modes.

The real problem here is simply that lack of internet access became a failure state at all, which is completely outrageous. That said, we probably don't know the whole story here and there could have been a power failure involved or some other situation where the designers decided that the best response would be to trigger the fail-safe behaviour.

Chamberlain v. Home Assistant

Posted Nov 20, 2023 20:38 UTC (Mon) by calumapplepie (guest, #143655) [Link] (6 responses)

For a light, lack of internet over a long time should be a failure state: you don't want all your lightbulbs to become bricks because they were off when you switched to a 5GHz network when they only support 2.4GHz

Chamberlain v. Home Assistant

Posted Nov 22, 2023 15:33 UTC (Wed) by karath (subscriber, #19025) [Link]

For me, the requirement of a light for internet access to allow basic functions is a failure state.
And for that matter, how will a light that only supports 2.4GHZ access the LAN when there is no 2.4GHz network, never mind the internet?

Chamberlain v. Home Assistant

Posted Nov 23, 2023 13:19 UTC (Thu) by nye (guest, #51576) [Link] (4 responses)

> For a light, lack of internet over a long time should be a failure state

I don't want my lights to depend on the internet at all. Ideally they'd access their control plane via Matter/Zigbee, but local WiFi isn't completely terrible (although it has more opportunities for failure and a worse UX).

What *would* be completely terrible is if my smart light switch were to function by sending a request to the internet, and then the light receiving that request from the internet. That really doesn't seem like a device that's fit for purpose, and that's what I mean by saying it's outrageous for lack of internet access to be a failure state.

All mainstream smart lights I know of, including pretty cheap mass-market ones like the Ikea range, function perfectly well using local networking only. No doubt there are plenty of counter-examples that people could point to - all I'd say is that I wouldn't buy them and wouldn't recommend them to anybody for any purpose.

Chamberlain v. Home Assistant

Posted Nov 24, 2023 8:28 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> What *would* be completely terrible is if my smart light switch were to function by sending a request to the internet, and then the light receiving that request from the internet. That really doesn't seem like a device that's fit for purpose, and that's what I mean by saying it's outrageous for lack of internet access to be a failure state.

If you read the original story, the failure was that the lights were controlled by voice, and I guess that was what needed the internet. Oh - and control by light switch was *physically* impossible, hence the *need* for voice control.

Cheers,
Wol

Chamberlain v. Home Assistant

Posted Nov 27, 2023 16:44 UTC (Mon) by nye (guest, #51576) [Link] (2 responses)

I haven't seen the original story, just the Guardian article posted upthread which doesn't have any references that I can see. That article just describes the standard expected behaviour where the lights revert to their default state (on) after a failure that they're a bit vague about, and the user wasn't able to control them due to physical disability.

Even without knowing any more details, I can safely say that voice was not the only way to control those lights, just the only way accessible to that user in the circumstances. The question is whether that would take the form of resorting to the physical power switch on the wall (ie they failed in such a way as to turn them into normal dumb lights) or whether they were in fact capable of local operation, if only she'd been able to use the remote. That distinction doesn't matter for this particular user, but it does matter in general. We don't have the information to tell whether this particular smart platform is good or bad, but this user actually requires it to be pretty well *perfect*, which is impossible.

In other words, this discussion is actually about two issues. The broader issue is that as a society we should never be forcing anyone into a position where they're entirely dependent upon some piece of technology, or indeed any single point of failure even if that's a trusted person.

On the one hand, voice control that works when you have internet access is better than no voice control at all. On the other, technology that works *almost* perfectly can encourage people to skip backup plans - like alternative technologies with independent failure modes, regularly scheduled checkups from a human being, etc. I don't think the inability to be perfect reflects badly on any particular technology, but unwillingness to accept that, and insistence that we can find cheap technical solutions, does reflect badly on society.

Chamberlain v. Home Assistant

Posted Nov 27, 2023 18:05 UTC (Mon) by farnz (subscriber, #17727) [Link]

It's also the case that people overindex on the most recent failure; yes, the issues this time were due to an Internet outage. But what was the plan in the case that the power was out completely? Or if the lightbulbs had a hardware failure? And, given that there are multiple possible causes of a failure, why couldn't the plan for a total power outage be used to handle the total Internet outage?

FWIW, I have smart lights, with local touch remotes, a local-only mobile app, and cloud-based voice service and mobile app. As long as my local WiFi is up, I can use the mobile app to control the lights. As long as the lights are working, I can use the touch remotes. But to use the cloud-based voice service, or remote mobile app, I need my home Internet to work, too.

Chamberlain v. Home Assistant

Posted Nov 27, 2023 18:20 UTC (Mon) by excors (subscriber, #95769) [Link]

In this case it appears the backup plan for smart home failures was to contact a support worker to come and sort it out, which sounds like a good enough plan. Smart home technology can be helpful at giving greater autonomy to disabled people, and if it fails then you're just back to being dependent on other people and you're no worse off than before.

But the Optus outage affected internet, mobile and landline phones (reportedly including calls to emergency services in some cases), so she couldn't contact anyone at all, and there was apparently no backup plan for that. (Maybe she and her support workers could each have two phones on different networks, but that sounds pretty expensive and still not an infallible solution.)

When she was stuck in bed (because of her disability) with no means of contact (because of the outage), leaving her with "no access to food or water", and she'd have faced that serious problem even if she had no smart home technology, it seems odd to focus on the relatively trivial issue of not being able to control the lights.

A relatively trivial issue is still an issue - coincidentally one I'm experiencing right now, since my internet service has been down for a couple of days and I can't mumble at my bedside light to turn it off, I have to make the effort of leaning over to press the button (still a smart button; it's Hue which works okay offline) - and it's probably an issue worth addressing. But this story seems like a poor case study for that.