Slashdot Mirror
Hundreds Of Smart Locks Get Bricked By A Buggy Firmware Update (bleepingcomputer.com)
An anonymous reader quotes BleepingComputer:
On Tuesday, August 8, smart locks manufacturer LockState botched an over-the-air firmware update for its WiFi enabled [RemoteLock 6i] smart locks, causing the devices to lose connectivity to the vendor's servers and the ability to open doors for its users... The device costs $469 and is sold mainly to Airbnb hosts via an official partnership LockState has signed with the company. Hosts use the smart locks to configure custom access codes for each Airbnb renter without needing to give out a physical key to each one. The botched firmware bricked the device's smart code access mode. Physical keys continued to work. The botched firmware was a nuisance for private home owners, but it was a disaster for Airbnb hosts, who had to scramble to get customers physical keys so they could enter their rents.
The post includes tweets from angry lock owners, one complaining about a two-week wait for a replacement. The company is also offering to fix the defective units within "5-7 days," promising that "Every employee and resource at LockState is focused on resolving this for you as quickly as possible."
The post includes tweets from angry lock owners, one complaining about a two-week wait for a replacement. The company is also offering to fix the defective units within "5-7 days," promising that "Every employee and resource at LockState is focused on resolving this for you as quickly as possible."
Yet another data point demonstrating outages are better caused by admins than by hackers.
"Tempers are wearing thin. Let's just hope some robot doesn't kill everybody." --Bender
Yet another data point to underpin the motto "Never allow any data or access or service that you value to be controlled by Somebody Else's Computer"
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
Way to Go Software "Engineers". I can't wait for the self driving cars to roll out.
We are sorry that your self driving car veered off the road and killed all its passengers. We have isolated the bug to the periphery scanning routine. Please accept 1 Mo of free self-driving car time, or 1 Mo of free Uber/Lyft service, and this complimentary condolence ham. Remember, our liability is limited to the price of the software, please accept this 1499.99 as full compensation for the death of your relatives.
Your insurance is fully liable for the remaining costs, re: the 4 pedestrians that were killed. Our liability ends here, have a great day!
I've seen it increasingly over the last few years, shortcuts on testing in order to get an update/new product out the door. This is short sighted. In a year, noone is going to remember it took you a week longer to get it out the door. People WILL remember if you brick all your devices.
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Is the backup unlocking device.
but if LockState is telling the truth, they're putting everything they have into fixing the problem
Nothing less should be expected, but that does not in any way diminish what happened. It is also likely not out of a desire to do what's right, but to reduce the number of lawsuits.
This is exactly the type of shit that happens when you have millennial dipshits writing your code. Experience matters, a lot. Something the borderline millennial dipshits that run these companies don't understand.
No. Some code should not be written.
Find a different way.
"Oh fuck, oh fuck, we're fucking fucked!"
Can I hear that again?
[...]causing the devices to lose connectivity to the vendor's servers[...]
So, lemme get this straight: These things, that lock my home doors, have a connection to their vendor, reacting to this vendor's command to unlock or lock my home. Did I get that right?
What sane person would WANT that in the first place???
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
And the real lesson is that if you're going to do firmware updates like that, you need to ALSO have a backup in ROM that is at least good enough to get connected and re-flash the primary firmware, and a mechanism to boot into it.
Other useful precautions include only doing upgrades when explicitly permitted (so, not just before the owner takes his dream vacation when a screw up would ruin his week). Perhaps best of all, get it right the first time or at least try hard enough that you feel comfortable making updates a very rare manually initiated end-user procedure.
Does anyone even know what the update was supposed to actually fix? It seems the users weren't complaining before the update went out.
Fundamental problems exist though, and they have fixes. First, allow the device to rollback to previous firmware, or allow a reset to original firmware/configuration. That's almost mandatory for serious companies selling to serious customers, but it's often treated as unnecessary by silly companies selling to the consumer market.
Second, put the customer in charge of when upgrades happen. The device belongs to the customer unless you're merely leasing it. Again, this is mandatory for serious companies selling to serious customers (and sadly, Microsoft isn't in this category anymore)
Finally, always test any change, no matter how innocuous, do not ever believe the developers when they say the last minute change is safe. If you're the CEO of a company you do not want to put your company's fate into the hands of an underpaid and overworked low level manager or developer. Sadly, serious companies for serious customers screw this up all the time, but they can recover from the disaster because of the first two guidelines.