Hacker News Reader

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 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!

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.

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.

> 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!

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.