Hacker News Reader

Comment by lvh | Hacker News Reader

Based on my local big box store and garage installer availability, Chamberlain has a de facto monopoly. They also pulled the rug out from under customers: that behavior had been in Home Assistant since 2017, and it's their own recent changes that caused the alleged "DDoS". They say it's to promote official products, but the company previously had a local hub that didn't require their cloud service and discontinued it.

The API breakage coincides pretty well with their brand new CTO, whose objective is apparently "transformation to a smart access software company".

It's unclear if the CTO just doesn't understand that "DDoS" generally implies malice, or if they're intentionally using that language to blame users for using their product.

Good news: ratgdo, an ESP-based local solution works great. I hope the author is making a decent profit on the kits.

View on HN

> It's unclear if the CTO just doesn't understand that "DDoS" generally implies malice, or if they're intentionally using that language to blame users for using their product.

I've definitely seen "DDoS" used when there was no malice, such as when a developer accidentally releases a client that generates way more traffic than it was supposed to. Probably because we don't seem to have a good term for "event that at the server looks exactly like a malicious DDoS attack but was actually due to a mistake or to the server becoming unexpectedly popular" :-).

My favorite example of whatever we are supposed to call this was John Carmack in 1997. From his 1997-12-09 .plan:

> Cyrix has a new processor that is significantly faster at single precision floating point calculations if you don't do any double precision calculations anywhere.

> Quake had always kept its timebase as a double precision seconds value, but I agreed to change it over to an integer millisecond timer to allow the global setting of single precision mode.

> We went through and changed all the uses of it that we found, but the routine that sends heartbeats to the master servers was missed.

> So, instead of sending a packet every 300 seconds, it is sending one every 300 MILLISECONDS.

> Oops.

> To a server, it won't really make a difference. A tiny extra packet three times a second is a fraction of the bandwidth of a player.

> However, if there are thousands of network games in progress, that is a LOT of packets flooding idsoftware.com.

> So, please download the new executable if you are going to run any servers (even servers started through the menus).

That's fair. Maybe my security background is shining through here. I guess we used to have "slashdotting" but that doesn't generalize well :)

I did do some napkin math to quantify how much that bad traffic may have been: HA estimates between 6857-25576 intallations of the MyQ integration. Let's say 16k clients. HA makes it really easy to detect and "add" the integration (which counts as an installation even if it's not configured), so, that's definitely not all clients hitting the API. Let's say it's 50%, so 8k actually using it. Most users just notice myQ is broken. Let's say some fraction retry, which would look the same as an extra user from a volume perspective. Call it an even 10k users (including repeat users).

The most recent change is after they broke everything past the OAuth dance. Let's say the OAuth request is 1kB. The retry code retries up to 5 times with exponential backoff. Let's say 5 requests over 10 min.

(5 requests / 10 minutes) * 1 request/user * 10k users = 5k requests/minute, or 83 per second, amounting to 83kB/s inbound.

There's no reason to assume those requests would synchronize, but I'm sure there's something (let's say every single myQ user updated at the same time).

If what they're saying is true, sounds like actually malicious botnet wielders can ransom the living daylights out of them. Given 1Tbs DDoS attacks they'd only need a tiny fraction of the full bore ion cannon! ;-)

[1]: https://github.com/arraylabs/pymyq/blob/master/pymyq/request...

83 rps would be a challenge when hitting a Java EE app written to make use of tutorial-level ORM code without any caching or optimizations. An app where a request takes 300ms to resolve (pulling numbers out of hat for an average poorly written Java EE app; ignorantly assuming 300 ms are spent with 100% CPU utilization of a single core), would require a 24-core machine to keep up with 83 rps. Accounting for some peaks in usage (how about 5x around 7-8am?), 400 rps could make almost every morning an "all hands on deck" event for the ops?

A term I hear a lot for non-malicious or non-intentional DDOS is the Hug of death.

> I've definitely seen "DDoS" used when there was no malice, such as when a developer accidentally releases a client that generates way more traffic than it was supposed to. Probably because we don't seem to have a good term for "event that at the server looks exactly like a malicious DDoS attack but was actually due to a mistake or to the server becoming unexpectedly popular" :-).

This is a problem with the service, not with the developer.

If the service (doesn't want) / (can't handle) something, then it should rate limit it's response.

If the service can't handle "0.2%" of it's clients making a 'not unreasonable' amount of requests, how will the service hold up against a hostile actor who aims to DDOS their service.

> I've definitely seen "DDoS" used when there was no malice,

Absolutely. Used to work on the Identity team somewhere. Dev accidentally removed code that was supposed to cache a token on a very chatty service. Brought auth to its knees and called it DDoS.

>The API breakage coincides pretty well with their brand new CTO

You can go and engage him directly on the topic, maybe he'll present a perspective we haven't seen, or maybe he'll listen to your arguments and reconsider:

https://www.linkedin.com/in/dan-phillips-9a33831/

(and no, this is not doxing: his profile is public).

Still, linking out to socials and encouraging brigading is pretty gross.

That project looks great! Now the issue is finding a Chamberlain or Liftmaster opener without myQ built-in. Or maybe I just don’t have to activate it.

Odds are that whatever nice Chamberlain opener you want will have myQ built in because that's their business strategy. You can try getting a different brand if you're voting with your wallet -- but if all you care about is security: the Cloud connectivity is optional and you can just not connect it to WiFi.

The ratgdo is more trustworthy, and it just connects (really easily, too, especially with the new v2.5 board) to the opener via the same contacts that the dry contact button does.

Came here to plug ratgdo as well - mine is supposed to arrive today! And he should definitely charge more.

Glad you all mentioned it. I'm ordering today. Hope they don't run out. :) HN cometh.

Can someone post the endpoint it is trying to reach for “research” purposes?

Tsk tsk.

I’ll ddos whoever the fuck I want you loser

Huh, nice. I went with a dry contact kit from Athom but status feedback is tempting (mine just uses a reed switch to detect state):

https://www.athom.tech/blank-1/garage-door-opener-for-esphom...

I use the Athom one also, and putting a reed switch in the fully closed state, as well as in the fully open state allows me to reasonably determine where the door is. Might not be enough for your case, but for me it was enough to know that the door is “kinda open”, or “fully open”, or closed.

I did the same with a MHCOZY Zigbee dry contact relay and two Aqara door/window sensors. I use the dry contact relay for two doors, and have two more channels to use for other stuff if I need to.

Additionally, I tried using an Aqara vibration/tilt sensor for more accurate "partially open" status reporting but it was a) not sensitive enough b) too unreliable c) too slow to update. I guess it's more meant for detecting impacts or falls.

I've also toyed with the idea to mount an ultrasonic distance sensor at the top of the (rolling) door, which could measure how far from the ceiling/far wall the top of the door is, but it'd be pretty bulky and problematic to power mounted on a moving part like a door.

Getting status information from the door is the entire value prop from something like the ratgdo. It's the only reason I ordered one. Otherwise, momentary switches with HA integration are readily and cheaply available.

Replaced my openers in the spring, and 100% wouldn't have chosen them if there wasn't HA MyQ integration. Such a silly move.

I used a local Meross install on my old garage doors, time to break them out, but ugh...

I'm happy to not have one of their devices but if they did this after I had installed it based on the fact that it works with HA then I'd definitely sue them for breach of contract or whatever else I can think of or to get a full refund.

What a shit move to pull on your existing customers.

It was $30. I highly doubt it’s worth it, unfortunately.

It's not about the amount, even though you are right that it isn't worth it, it's about the principle of being screwed after you're on-board.

Reply on news.ycombinator.com