> Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in.
What follows are my two pennies as a developer working in home automation for 7 years. In this venue, readers may even have more knowledge regarding security, but I hope to speak to a common case.
I develop this exact feature though not for Ikea. Having made the sausage, some of these UX-first flows are worrisome.
Consider a lightbulb that factory resets given a rapid succession of power cycles. Most consumers won't have redundant power during a brownout, so there is an edge case where dirty power can mistakenly send the bulb to a reset state. (More plausibly, a child tugging at a light switch?) Now, any device in radio range has an opportunity to take over the bulb.
Provisioning is rare. Unless the owner enjoys tinkering, a residential IoT device is provisioned a handful of times in its life. I personally think it's a waste of time to optimize this flow if the improvements are also vulnerabilities.
Suppose I have a great new smart bulb. I'm ready for a larger market so I prepare a demonstration for Lowe's, hopeful for space in their lighting and rough electric aisles. Lowe's has seen this before. My bulb works fine but my users aren't technical. Lowe's replies, "we can't carry this. Users must deploy and control from a single app in 5 minutes." If I want my smart device to compete, my hand may even be forced to implement UX-first provisioning.
Companies like Lowe's and IKEA don't want to be in the tech support business. My bulb is a liability because their customers will call with complaints or questions.
I find QR codes to be a slick implementation. They don't even need electricity! Users can manage the system even when components go offline. Folks are trained on social security numbers and PINs for bank cards. It's easy to comprehend the QR code as a password.
on the other hand - I had contractors install our Nanoleaf recessed light cans (thread over matter) in our new house. In all the hubbub, I forgot to make sure to save the light cans boxes that had the QR codes inside. I found around half the QR code stickers, but I lost the other half. The light cans also have the QR codes printed on the top, but we have nailed-down attic flooring that covers them completely. So I'm basically just praying that Nanoleaf's CS can give me the pairing codes based on my order number, haha.
Oof, yes that's certainly a way QR codes can go wrong. Ideally manufacturers print the QR code on the device such that it lasts the device's lifetime.
It would be nice if technical users (installers) could reset the certificates or keys too. Besides losing the QR code, secondhand owners also want some assurances.
Usually these LED puck lights are only held in place with little spring-loaded arms that grip the back side of the drywall, and all you need to do to remove them is tug on them a bit and they'll come out. The light is connected to the electrical junction box with a short low voltage cable with a plug on it, and the LED driver and line voltage connections are all inside this junction box.
I feel like the problem is a lack of realism about what is required to meet the usability standards of traditional analog switches. Like, I hear you talking about a tradeoff between security and usability for a "rare" provisioning event but I think in practice if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
The security concerns probably have typically zero impact on the operation of the device. I'm not saying that the security concerns are unjustified. Really I'm actually leaning more that this is completely impractical and not a good replacement for a dumb physical switch. The security issues are unacceptable and the downtime caused by even the useless security measures available is even worse. (Also, the security measures seem more concerned with whether or not I have a license to watch my video on that particular device than preventing people from turning on my toaster.)
> if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
Can you explain more about how you reached this conclusion? Why are devices offline for years now?
The Bluetooth connection gets screwed up for some reason and it needs to be reprovisioned. The device is in a room which isn't really the domain of the person who can reprovision it. Whoever is actually affected by the outage can't fix it, has to realize that it's a solvable problem and ask the person who can solve it to fix it. This social problem of recognizing that a chore needs to be done will likely take at least a week, typically a month or even years to resolve.
And the whole point of this is to provide a seamless experience that's easier than using a physical switch. But in practice this just generates chores that are actually more time-consuming than simply using a physical switch. (Even in the single-user setup, I can imagine that I actually just revert to using whatever hardware controls are available on the device for quite some time because reprovisioning it is too much of a chore, and whatever wireless options it provides are not worth doing that chore.)
while your example is correct, I have many many examples in my experience why scanning a qr code is simply infeasible in some situations and as a owner of a heavily automated home I welcome the development with open arms.
What follows are my two pennies as a developer working in home automation for 7 years. In this venue, readers may even have more knowledge regarding security, but I hope to speak to a common case.
I develop this exact feature though not for Ikea. Having made the sausage, some of these UX-first flows are worrisome.
Consider a lightbulb that factory resets given a rapid succession of power cycles. Most consumers won't have redundant power during a brownout, so there is an edge case where dirty power can mistakenly send the bulb to a reset state. (More plausibly, a child tugging at a light switch?) Now, any device in radio range has an opportunity to take over the bulb.
Provisioning is rare. Unless the owner enjoys tinkering, a residential IoT device is provisioned a handful of times in its life. I personally think it's a waste of time to optimize this flow if the improvements are also vulnerabilities.
Suppose I have a great new smart bulb. I'm ready for a larger market so I prepare a demonstration for Lowe's, hopeful for space in their lighting and rough electric aisles. Lowe's has seen this before. My bulb works fine but my users aren't technical. Lowe's replies, "we can't carry this. Users must deploy and control from a single app in 5 minutes." If I want my smart device to compete, my hand may even be forced to implement UX-first provisioning.
Companies like Lowe's and IKEA don't want to be in the tech support business. My bulb is a liability because their customers will call with complaints or questions.
I find QR codes to be a slick implementation. They don't even need electricity! Users can manage the system even when components go offline. Folks are trained on social security numbers and PINs for bank cards. It's easy to comprehend the QR code as a password.