Hacker News Reader

Comment by jimrandomh | Hacker News Reader

A lot of comments here are blaming the user for using the same username/password on multiple sites, allowing their account to be compromised. This is missing the point.

Nest cameras are a security product aimed at non-technical users, so of course this happens frequently, and of course this was foreseeable at the very earliest design stages. The designers needed to come up with a solution to this problem, and blaming the user is not an acceptable excuse.

The solution is actually pretty easy: require a pairing procedure that can't be done remotely. For example, the Nest app on a phone could display a QR code with is public key fingerprint, which you show to a camera, and the camera will only send video to phones it's been paired with. That would pretty much completely eliminate this failure mode.

View on HN

Former co-founder & CEO of Dropcam (Nest cam) here.

There's no way to say this humbly, but imo stuff like this is the reason that companies lose their way when they lose an empowered "buck stops here" product-oriented CEO with enough engineering chops to modulate product decisions.

I had an endless to-do list of improvements, including security enhancements like the one you suggest (but done in a way that would not impair usability, like anything with QR codes :-)).

The problem is, a string of well-meaning but amazingly risk-averse managers came in and killed the soul of the company by introducing enough bureaucracy that the team and I no longer cared to bang our heads against brick walls anymore.

If the leadership doesn't a) understand product, b) understand business, c) know/respect good engineering, or d) have "fuck you, we're doing this" authority ... it will fail in spectacular ways through a series of seemingly good short-term decisions, it's just a matter of time.

Combine product, business, engineering, and authority to lead, sprinkle in some ethics and respect for your customers/employees, and baby you've got a stew going.

This whole privacy mess in home & so-called "IoT" is a result of people who don't even know what would be required to operate ethically with such powerful technology in the first place. I believe they are mostly good people, they just don't have the mindset or philosophy to know what to do. It kinda makes me misty-eyed. They know where to find me if it sounds like some of this could help... I'd be happy to try and get the band back together again.

The fact that this was on your list of "improvements" rather than being a minimal requirement before being willing to launch, sell, etc, is pretty damning on it's own. No need to get misty-eyed.

Sorry, but that shows a fundamental misunderstanding of the problem space. We entered the "IP camera" market in 2010, when all the competitor products booted a 7-year old Linux kernel with busybox and UPnP'd a port to the public internet. Admin/admin, no string escaping, buffer overflows, inadvertently indexable by Google, rooted and/or turned into botnets.

Dropcam v1.0 eliminated all of those security problems.

The only gotcha is that we required cloud storage. However, my plan for v2.0 Dropcam was to go with open-source verified builds + kill the cloud-storage requirement (but offer it optionally with e2e crypto).

If I had required that at v1, the company wouldn't exist today, and worse stuff would have taken its place. Good product engineering requires prioritization and stepwise problem-solving, not ivory tower ethics.

> open-source verified builds [...], kill the cloud-storage requirement [...] optionally with e2e crypto

In your opinion, in the current space, do you think there's room for this kind of product now? I bet most of the readers here know why these are good features if you don't like adversarial software running sensors on your home network and uploading stuff, but I also bet we're in a tiny, tiny minority in the market.

No, for two reasons:

1) You get no credit with customers for security features, only blame if they get hacked. You must invest in good security engineering because you believe it is a good thing and a good long term investment, it will only cost you in the short term.

2) Unfair competition from large tech and China-based companies, in terms of pricing and incumbent advantage. (And yes, I helped create this situation by selling Dropcam to Google, and profited from it)

In order to win, you'd have to make something better in every other respect (or find some yet-unknown killer feature that average customers actually care about), sell it for the same price, beat them in price wars, and spend enough on marketing to undo the PR damage they've done to the space AND rise above the noise floor.

Doesn't Apple's HomeKit do this the best? It was designed to be secure (so much that they had to backtrack on requiring hardware encryption chips) and it works locally.

With all respect, just because the state of the market was terrible doesn’t make a more secure insecure product good for the end user. And more than take market share away from less secure cameras, nest created a great ux helping expand use to unsophisticated consumers.

We'll have to let god balance that out on the scales of morality when I reach the pearly gates someday.

There's a lot of good and bad that came out of Dropcam but I think it's been mostly good. Lives saved, murderers in jail, happy moments captured that would otherwise have been lost.

Plus, we had every intention of improving this aspect, and I'm even commenting unpaid on the internet to put as much pressure as I can on Google to follow through on that!

  nest created a great ux helping expand use to unsophisticated consumers

Thanks for the compliment though. Maybe god will pardon those who create good UX. :)

> With all respect, just because the state of the market was terrible doesn’t make a more secure insecure product good for the end user.

With all respect, let us know when you (or anyone else) releases a perfect version of a product. Nobody has unlimited money and time in which to polish a product to perfection.

I'm in the throes of this right now, trying to beat a once-miserable codebase into something that that improves our customers' lives, is stable, is secure, etc. on a shoestring budget. It's a hard, wretched slog but we're doing it, one point release at a time.

This is exactly right, and way better than my reply.

Your polish can improve as you scale and get more resources. That doesn't mean there isn't a min-bar of basic security practices and ethics, but if min-bar is perfection on all counts, get ready for a long and fruitless existence...!

Nobody's asking for perfection, just something that doesn't get hacked and play pornography for 3 year olds. Nest had polish. Security took a backseat to UX, and here we are.

It's silly to call that a minimal requirement. There's nothing simple about local pairing especially when you need to be concerned about your entire market, what phones they're using, what devices they're using, and how much funding your call center has. Yours seems like a very naive, hindsight is 20/20, comment.

take your holier than thou attitude out the door. it's so easy to play an arm chair quarter back and not know the struggles people in the tranches have to go through to get features and improvements through management.

My non technical parents set up their wyze cams by showing the qr code on their smartphone to it. I think it is just for communicating the wifi password to the camera, but it didn't really seem like a big deal for them.

My quip about QR codes was kind of tongue-in-cheek, but any step that can be eliminated should be and there are just better ways to do it. QR codes can also fail in interesting ways, e.g. bright sunlight or cracked screens.

Most QR code based setups were just transmitting wifi credentials in plain text. That's insecure, and it doesn't solve the pairing problem, only the wifi connection. There's actually a fair bit of 2-way data that needs to be exchanged to provide the best experience. And sure, you could start streaming encrypted setup information through animated QR codes, but there's better ways to do it.

Not to mention that we're talking about Wyze cam, which has been filled with hilarious(ly scary) security flaws since day one. Be careful with those things...

Probably the best UX I've seen in this area is Hue, where to add a device or confirm access to a hub you physically push a clicky button on the hub within a certain time limit.

A close second would be Apple TV, where to add a remote you hold it next to the device (presumably some kind of short-range Bluetooth thing).

Right - just to be clear my point wasn't about the security of wyze cam(security? lol), but about the ux for setup involving a qr code, which could be seamlessly extended to pairing specific devices. I'm sure you could use other means to transmit the relatively small number of bits to pair the device as well which could overcome most device limitations, for example by having a black and white flashing screen held in front of the camera (I had a watch in the 90s that could do this), or encoding messages through an audio channel.

I've got a table of a zillion different methods with myriad categories of benefits and drawbacks. And a weighted scoring system. And ... I may be slightly obsessive about this topic! :)

Would you mind writing them down and sharing somewhere? This would be beneficial to any ethical IoT maker.

I'll try when I get a moment. I think it might actually be better and easier to open-source SW and HW modules that do the right things.

I think it might be a good way. OS designs are a boon for the free market too, as they separate out concerns and allow independently competitive submarkets to exist.

One potential challenge I faced myself with my DIY attempts at IoT hardware was dealing with power. I'm not an electrical engineer, and I don't trust myself enough to plug anything to mains power - and I don't trust random OH stuff you can order soldered from China either.

Oh man this sounds like my experience at google. The unlimited stream of money on our project meant avoiding risk was too easy. I feel like I could have done a lot of good for way less money but nobody was interested in new ideas from folks in the trenches.

I know what you mean. Product engineering gets weird when you remove all constraints, and you actually end up hobbled instead of empowered by the "resources".

I think if they made projects require independent profitability (after a startup period), a lot of that weirdness would go away and customers would be happier too.

I don't understand. If I were running a project with unlimited money, I'd engineer it so that it would never send data to me (it would work over LAN, VPN, and a cloud service used only to establish a direct link between the camera and the viewing device) and wouldn't be subscription based. That's ethical design. It seems to me the projects were indeed constrained, and most of the weirdness in IoT can be attributed to the core constraint: since the business model of selling crappy hardware as a loss leader to hook people on an Internet service is allowed to exist, it's very hard to compete without doing it.

Every rung you climb between client-server towards fully distributed increases software difficulty non-linearly.

It seems simple at the outset, but once you actually try to build a complex business/product like this one you realize you have to start with something simple just to get the money to fund something more complex/better.

RE: internet service loss leader model, I think it can be beat with a better product and a better model. But someone is still always going to need to pay to maintain and update software, and it seems fair to profit off of that as long as you allow for competition (& that's where I believe the law should e better protect consumers).

> Every rung you climb between client-server towards fully distributed increases software difficulty non-linearly.

That's true. In my mind, fully distributed doesn't have to be the goal. I believe the number one problem for getting people to talk to their smart devices are NATs. I imagine a cloud service responsible only for NAT punching, and all the actual communication between user's smartphone and smart device happening directly (or rather, between the smartphone and home hub). It's probably more complex in practice than I think it is, but I can't think of an obvious show stopper.

> But someone is still always going to need to pay to maintain and update software

I think this is mostly a self-inflicted problem (or rather, a problem created and then used as an additional justification for subscription models). E.g. for a lightbulb, there's only few bytes of data that needs to be transmitted over the control channel. On/off state, color, intensity - setting them in one direction, reporting in another. That + overhead of whatever communication protocol is used. Such a device doesn't need an update. There's nothing to update there. The hub might, but arguably, hubs are designed overcomplicated too. But vendors seem to like to put a whole software stack on the devices, which now creates an attack surface that doesn't need to exist in the first place - and suddenly, security updates are required.

I think I understand where you are coming from, and I've thought similarly before.

But billion-dollar companies have been made almost purely on "NAT punching". I've written the code, and it's more complex than it seems.

And RE: your lightbulb example, I love it, because it I will now use it to illustrate how even seemingly simple devices require ongoing software maintenance. Is it using a wireless protocol compatible with other devices? Does it use encryption/authentication (e.g. to keep the neighborhood hacker kid from controlling my lights)? Does the setup process require interoperation with a changing set of personal devices (phones, etc)? All of these things could require software updates, see e.g. heartbleed. And if you have a software update system, it now needs maintenance as well...

Not to mention if consumers want their hardware investment to continue paying dividends through new software features. That part should definitely be opt-in and open to competition.

But those engineers you hire to maintain your software aren't commodities. They have shifting interests, bills to pay, and boot-up time to re-remember all of the old code. Costs will be lower to keep them employed and making continuous improvements once a product reaches sufficient scale.

Competition would prove out which model is best, though, so no need to think too hard about it, we just need to improve antitrust/competition law.

Thanks for the clarification on both points.

You've changed my mind a bit about the update capability - I suppose any wireless protocol necessitates a software update capability because it's exploitable remotely (e.g. from outside the house), and you'll never get it bug or vulnerability free the first time.

But this then calls into question the utility of consumer-level IoT as a whole. It's nice to be able to operate devices remotely from wherever you are, but this immediately creates a very large category of problems.

> Competition would prove out which model is best, though, so no need to think too hard about it.

Unfortunately, I'm not convinced of that, for several reasons. Information asymmetry - non-tech consumers can't evaluate these products, so vendors designing bad products have competitive advantage. Thanks to recurring revenue, service-backed devices can be at much lower price points than their service-independent counterparts, and most customers are very price-sensitive. Add in surveillance and data mining, and the price can be lowered even further. User-hostile business models have a distinct competitive advantage, because they offer immediate benefits but the costs are deferred. Therefore, I don't think competition alone is going to solve it.

Being capable of changing one's mind is a great thing. Thanks for the honest conversation – that's what's great about HN these days!

We competed head-on every single day with companies that lied like it was a national pastime, and we beat them handily. I think it is because good people tend to make the best products. There's an efficiency increase from passion, and all it takes is one good leader to unlock a team of hundreds or thousands of good people. I believe it is enough to take to the bank against shady practices.

That said, I do support better antitrust laws, we need to update them for the 21st century tech oligopolies + IP-stealing/currency-manipulating nation-states.

But all it takes is one good motivated person like you or me to Make The World A Better Place (™ HBO Silicon Valley). So let's get to it...!

> In my mind, fully distributed doesn't have to be the goal. I believe the number one problem for getting people to talk to their smart devices are NATs.

Ubiquiti does a good job with this - they provide the interface to get into my equipment remotely with little setup, but don't send the data to their equipment.

I went from a stream of permanently money-scarce small businesses that had to work within tight means, to one that was small but with almost unlimited cash, where bugger all got done because there was no pressure from deadlines - why worry about making money if you're never going to run out?

My takeaway: abundant money can be poison.

I think the risk adverse managers messing everything up and the angry responses in this thread are coming from the same place.

It's a result of the authoritarian lean of our current times.

The concept of freedom IMPLYING responsibility has been completely done away with. The operating concept is: adult consumers are like children, and need to be protected.

The pathology of this can really be felt when it's a CEO of creators.com complaining that he can't be bothered to use different passwords. In other words, he wants to have all the rights and privileges that come with having the highest levels of social power, but none of the responsibility. It seems he doesn't feel it's fair to be given the responsibility I've seen school children master (keeping different passwords)

That seems true. I'm a fan of empowering users, with safeguards in place that they can disable if they opt-out and know what they are doing.

For a product like this, though, you need to make sure everyone who is ever in eye or ear-shot (or will purchase it used) are considered/informed as well.

In my book, once information is equalized, be adults, go nuts.

Is it authoritarian though, in the paternalistic/patronizing sense? I view it more as abusive. Customers are viewed as children in the sense that it's trivial to just steal a lollipop from a kid, or repeatedly exploit their trust to part them with their lunch money.

Can you please specifically say what you want? I mean, how did they fail, what should be done, and how that requirement isn't authoritarian?

To be clear, if they broke criminal laws they should go to jail. If they broke civil laws they should be sued. I'm not some crazy anti-gov person, just someone who believes in personal responsibility and that our blame/victim culture is perverse.

Your post is filled with innuendos and blame. I'd suggest that if you compare a company to 'stealing a lollipop from a kid' you can provide strong and concrete examples of theft. It's a pretty damning accusation.

Also, you are comparing adults making purchasing decisions to someone stealing candy from a kid. To me that sounds like the epitome of authoritarian patronizing. I'm guessing when you say that you don't see yourself as the child, only other adults right?

Well, sure: customers are treated like children in the sense that companies correctly notice that non-tech-savvy users have no clue how to evaluate anything about a tech product (nor should they), and exploit it. Regular people can't in advance tell that a device is insecure. Regular people haven't yet learned that a device tied to an Internet service will be a paperweight in a year or two. Regular people don't understand what a botnet is, why is it a bad thing, and that their service-based IoT device is likely to be one for most of its lifetime.

My point is simple observation: vendors exploit the extreme information and understanding asymmetry on the market to sell insecure, low quality and abusive offerings. If you haven't noticed it yourself yet and need more direct evidence, follow https://twitter.com/internetofshit.

You have a fact:

> vendors exploit the extreme information and understanding asymmetry on the market to sell insecure, low quality and abusive offerings

This is true.

Now, please tell me how this applies to the FA we are talking about? The FA is about a nest customer using an insecure and exposed password and then complaining about his nest being taken over by a hacker.

And this isn't some joe shmoe. This is a CEO. He is complaining. RTFA and you will see.

My point: he has not right to complain, his complaint is based on the authoritarian perspective that people need to be protected against themselves.

He has no giant information asymmetry which Nest exploited to hurt him. He messed up. Simple. If he can't understand how to keep passwords, he really shouldn't be a CEO, ESPECIALLY of a tech company. And here's a bigger idea, if you can't keep passwords, maybe don't use systems that need them. Just as if you can't drive drunk... maybe not drive or maybe not drink? Blaming beer companies for being abusive (which they can be) is in no way relevant to the RESPONSIBILITY people have to not drink and drive.

IF a company sells a defective and bad product, they should and will be sued. If they imply you can drink and drive. Sue. If they imply or say their product doesn't need safe passwords, sue. INAL, but this probably doesn't apply here. Which is why the guy who penned the FA is writing it. He wants to shame nest. And those who are authoritarian inclined seem to me to be backing him up. Instead of seeing the article for what I see it: A captain of industry wanting all the rights and rewards of being a captain of industry, but not having to keep the responsibility of maintaining proper passwords.

It is Apple style "we know what's best for you" authoritarianism. Multi-button mice are confusing. USB ports and headphone jacks are ugly. Nobody needs an Escape key. We'll take those away and restrict what you can do with the product to enhance your experience.

Maybe if they had asked Carl Weathers for advice, this wouldn't have become an issue.

I remain miffed by their recent decision to force the blue lights to on with my dropcams. I actually was able to gather critical evidence when cleaners (who were swapped out for my regular people without warning by the cleaning service) decided to search my home and commit identity theft instead of their jobs. They actually picked the dropcam up off the shelf and looked at it - getting a great, clear shot of their faces for the police - then decided it was broken and put it back down instead of destroying or unplugging it. Now, that wouldn't happen. They'd just unplug them or point them elsewhere. They even blink if I decide to look and see what's going on - a clear warning to any well-informed thief.

I miss the old Dropcam. You created something great. Sorry to see the buyers screw things up so badly.

Thanks, I appreciate that!

I feel you about the lights. Ultimately, I have grown to think that users should have ultimate control over the software running on their devices. If I want a light you can't disable, it should be by designing the hardware that way ... and you're still free to use a sharpie/tape/drill to modify your own hardware.

It's a fine line balancing making things difficult for creeps vs fully empowering a homeowner/caretaker to protect their castle/family how they see fit. But freedom for users to find their balance and law to punish truly bad uses are the only stable solutions... otherwise, creeps can always just use crappy products with no protections instead and you, the regular person, get stuck with crappy restricted products.

Some poignant examples of this are the many art installations that contain Dropcams. Suddenly a bunch of them have ugly blue dots that weren't intended by the artists. Does the artist now have to visit their installations with a sharpie? It's a stupid and limiting rule change that further pushes what was once a generally useful tool into a one-trick home security pony.

I hope you'll forgive me if I suggest that one might have hoped that security wouldn't be an item on your "endless to-do list of improvements" after you've released the product. I mean, what with that whole "good engineering" thing.

That's not a very generous interpretation of what I wrote, and honestly hints at an immature understanding of good engineering and security.

Dropcam v1 was one of the most secure internet products in existence at its inception, by design, full stop.

Making things more secure is a never-ending charge, and we never stopped. Google/Nest continue to try to improve things as well, but they've been slower and more inefficient at doing so than we were in our heyday. That's why these stories never seem to stop coming. The attackers are outpacing the defenders.

>Dropcam v1 was one of the most secure internet products in existence at its inception, by design, full stop.

Well, with all due respect, that doesn't exclude that the security may not have been "good enough" (then) as much as it is not "good enough" (now):

https://en.wiktionary.org/wiki/in_the_land_of_the_blind,_the...

Erasmus also said “What is life but a play in which everyone acts a part until the curtain comes down?”

“With all due respect”, which part are you playing right now?

My comments were not meant as logical proofs. But, I am content to say that Dropcam, as designed at launch, could likely be proven “net good” based on several popular moral axiomatic systems. That’s the best I’ve got, chum! The alternative is to convert oneself to a motionless blob, attempting to exert the least possible influence on reality unless intense logical calculation and polling of prevailing subjective moral bases has occurred first.

I choose instead to just try to do the right thing, and build cool/good stuff too. And always try to make things better, as long as you have breath. I highly recommend it over the blob strategy.

Have to admit though, I had forgotten how much fun it is to comment on the Internet!

> but done in a way that would not impair usability, like anything with QR codes :-)

LOL, there was a whole lot of head scratching when someone came up with the QR-for-pairing idea. Also, wink wink, nudge nudge, when are we grabbing a beer?

Anytime!

> A lot of comments here are blaming the user for using the same username/password on multiple sites, allowing their account to be compromised. This is missing the point.

I disagree. This is the equivalent of blaming car manufacturers in the 70s for stolen cars when people left the keys in the cars. This is 2019. We've had PINs and passwords for decades. At some point people have to take responsibility for their own lives, their own property, and their own safety and take some things seriously. Nest and other companies can only do so much when the users keep doing stupid things like "password" for their password.

If you leave your front door unlocked when you go on vacation, yes, the crook should be jailed, but you should lock the darn door.

I have a lot of junk sites I log into that have a REALLY shitty password - it's not tied to my credit cards or any personal info, but it was just to get something working/going. It's not the same as leaving your keys in the personal car and more equivalent to the leaving the keys in the golf cart I rented at the golf resort. Sure there's still some negative consequences of that, but if the golf staff just tell everyone to leave their keys out in the open when they're done renting, then that's what people do.

All of the "2000 era china cams" (foscam or whatever) I bought had a username password that only mattered if you were on a local network. I can imagine Nest users would probably assume that's what they were doing.

1. Your examples aren't on the same level as Nest, and I do the same thing. If you happen to hack my account at some random forum so I could see someone's attachment, have at it.

2. If anyone was so dumb as to think a camera they can view on their phone while at work or on a cruise ship was "only on their local LAN" then, again, it's 2019 and there's no excuse for that. If you can't figure out that you're seeing your house from 2,000 miles away because it's connected to the internet, I don't feel bad for you.

I don't disagree fully. I'm all for personal responsibility. But it's largely a failure of the technology of passwords. You want me to remember 30 different passwords. That's a non start.

So put all my eggs into a password manager basket. But I've been scared off those because I read that some are crap or Chinese or other scary things. And it fundamentally feels insane to give everything to one app on my phone. You haven't convinced this old bag of coal that's a good idea to do.

So now I'm backed into what I perceive as a "smug young tech people corner" where I feel damned no matter what I do because clearly I need to be tech savvy but you insist I don't need to be, that this is just a baseline intelligence kind of problem.

That whole story is a complete failure of technology, not the user.

Use keepass. It's an encrypted db with great mobile and desktop clients. Problem solved.

That sounds great. So I need someone smart to tell me which manager to use. And also to have confidence in them.

That's truly not awful. But it's not as easy as car keys.

Use the official desktop client for windows. The Linux version has to be run using wine, but there's a snap that makes the install a one-clicker. Use keepass2android for mobile.

Use a keyfile and password just in case your password is compromised, the attacker would still need access to your machine to open the dB.

Great, you want one password, use one password and two-factor authentication.

TANSTAAFL

I agree. Manufacturers want people to believe that their products are as safe as possible, we tech users know what it takes. The fact that "normal" users are unaware of the risks and not guided into securing their system is onto the manufacturer.

Most manufacturers don't care, because they know that a) users aren't able to tell what's secure, and b) they face zero consequences. As a tech user, I know that if an IoT device routes data through vendor's cloud, it's unsafe, period. As evidenced by breach after breach after breach after breach.

How about us tech users, that "know what it takes" do actually communicate that it takes something like 2FA to properly secure an account?

Instead, we are here looking for ways how Google could fix people's tendency to opt-out of additional security.

Because contrary to your claim, most bigger online services these days absolutely do guide and nudge their users into setting up 2FA, because adding a legit phone number to an account makes that account data that much more valuable for selling ads [0].

[0] https://techcrunch.com/2019/10/08/twitter-admits-it-used-two...

Sort of like the HomeKit pairing requirements...

I wouldn't say their response "misses the point", I'd say it's a lazy response and they don't care (or have enough financial motivation) to dive deeper into the underlying cause of the problem.

I really like your idea of a physical pairing procedure. It's not a large price to pay for dramatically increased privacy. Some other possible partial-solutions I initially thought of:

1.) Don't allow users to create their own password. Generate a strong password for them, and only show it to them once upon password creation/change. (like how API secret keys are often only displayed once upon creation) --- this would eliminate the "same password on multiple sites" issue

2.) Require a device whitelist where some type of fingerprinting/calibrating is done upon initial login by each device added to the list.

3.) Geofence logins to a pre-specified radius surrounding the camera location. E.g. if the parents work < 10 miles from home, they can set up a radius of 10 miles and understand that if they travel further than 10 miles away from home they won't be allowed access. --- this would be hackable, but would at least add another layer of protection.

> The solution is actually pretty easy: require a pairing procedure that can't be done remotely. For example, the Nest app on a phone could display a QR code with is public key fingerprint, which you show to a camera, and the camera will only send video to phones it's been paired with. That would pretty much completely eliminate this failure mode.

This is how Tesla pairs a new phone to work as a key -- you need to have one of the two RFID key cards that come with the car present, and be inside the car with the new phone. You pair _that particular device_ and then authorize it with the RFID card. Simply having the login to the app/account is not enough, and from the car itself you can always remove a paired phone.

A key for a car frames the problem in much clearer terms and Tesla engineered a secure solution. It is unfortunate this isn't done for other things where security is equally important.

> A lot of comments here are blaming the user for using the same username/password on multiple sites, allowing their account to be compromised. This is missing the point.

Omitting the lack of 2FA is missing an even more important point because it's cases like this why 2FA is pretty much mandatory today.

But instead of using already available solutions, you want to reinvent the wheel with "a pairing procedure". Gee, that sounds awfully familiar to what 2FA does, which also would have completely eliminated this failure mode, if the user would have bothered to actually use it.

In that context, I really don't see what Google could do differently with Nest. If users don't use additional security, then you can add all the additional security you want.

It never ceased to amaze me that the Blizzard game I used to play had better security than my brokerage.

We just aren't trying that hard.

So every time you add a camera, everyone in the family/workplace has to go find it and physically pair every one of their devices with it? That doesn’t sound workable.

Doesn't it? Compared to the nightmare described in the article?

I see this idea being proposed in an early design meeting. Then I see a product manager seriously consider it and then veto it. Why? Because their product's goal is to be the easiest to use camera system, and this makes using it much harder.

But let's say the PM and the rest of management was convinced. So they make it require pairing and send it out for field testing. Field tests come back: "it's really annoying that I have to pair all of my phones individually with each camera." Management tells engineering to fix that.

But let's say that the engineers once again convince management that this is a good idea. The product is launched. The review from CNET or Wirecutter or something comes back: "it's crazy in this day in age that I need to get a ladder and go around to all of my cameras to introduce them all to my new phones every time I do my yearly iPhone upgrade." CEO now has a crisis and demands this be fixed. Engineer pushes back again and is probably fired this time. Feature is removed.

A few years later, this article comes out and it causes much, much less damage to the brand than the bad usability reviews. Everyone learns the wrong lesson.

But why individually? Can't all the cameras in the local network share a single pairing code?

Or they pair with a "controller" device and any user pairs direct with that?

Could be a dongle with a button that plugs in to a router usb port.

FWIW, this is what Ikea's system does, and all that lets you do is turn the lights on and off.

Also: pair the cameras with the hub before installation, so you don't need a ladder later on.

I don't think the answer is to throw up our hands and say, "oh well, I guess security is fundamentally incompatible with usability in consumer electronics; caveat emptor is the best we can do." I concede there's a tension between security and usability (and that compromising on usability to achieve security makes your product less appealing), but we should demand that companies find better ways to design around that tension, instead of making the bare minimum concessions to security and adopting a "blame the user" mentality.

Or you do something sensible like have a hub. Every client device pairs with the hub. Every sensor device pairs with the hub. The hub brokers rendezvous and authentication. And to pair anything with the hub you have to be sitting there next to it with physical access.

I would expect it being even simpler, once you are paired to the network of connected devices you are connected to any future devices added to the same.

next time your app connects it simply indicates a new device has been added and asks if you accept it.

Those are equivalent, in the sense that the hub is a router to the IoT network. This functionality could be implemented on an Internet router itself, but it isn't, and honestly I wouldn't trust any consumer-grade router with it.

Sounds perfectly sensible to me. If I'm setting up security cameras in my own home then requiring physical interaction with the device to pair sounds like a great idea

One reason to have a camera would be to provide access to a parent or family member who is far away, perhaps even in another country.

And now that far-away person will have to ask someone with actual physical access to the device send a screenshot of a QR code. This is fine.

¯\_(ツ)_/¯

You only really need 1 person to physically pair, and then they can authenticate other people wanting to share it.

I mean, how often are you adding cameras?

I have to push a physical button to control my Hue lights, and we can't require physical access to a /camera/ ?

Perhaps something like Keybase's solution is workable? Where you generally need to access one of your existing Keybase clients to authorize a new Keybase client. Presumably you'd add cameras and the like the same way.

https://keybase.io/blog/keybase-new-key-model

Pair them with a hub. Cameras should talk to the hub on LAN, not the Internet. You can everyone's devices with the hub once. As explained in parallel, QR codes and distance are not mutually exclusive.

Reply on news.ycombinator.com