I feel like I'm missing out on a huge bulk of money simply because when I have ideas of "Internet of Things", I cant get over the security obstacles and cancel the ideas. If only I just didn't care (or didnt know) and just implemented whatever the heck brought in money from oblivious customers.
Under pressure in an interview, yesterday, I found myself saying "'The Internet of Things' is short for 'The Internet of Things you don't need, sending surveillance data you don't want, to people you don't know.'"
I argue to people that I'd rather have my photos on Googles servers than on the friendly local Dropbox clone.
Why? Because I know Google has systems in place to detect sysadmins browsing in data unrelated to their job and I know they have fired people over it even if was tought to have been done with good intentions.
Edit: as for tracking I wish they would up their game and stop providing ads for <insert eastern country here>-dating.<tld-of-the-day>
I wish they would take into consideration that I am happily married with more than 3kids, belongs to a subset of the population that has way less than 10% divorce rate and I might even be in the market for a new car at some point.
Nah companies want obediant placid fungible workers not free thinkering radicals. Even the hipster ones that let you work remotely and choose your own projects and stuff.
At the interview for my current job I was asked how I'd secure a remote service. My first response was along the lines of "Ask someone who actually knows about security, because I know just enough that I'd probably mess it up".
Or you could just implement them as-is, earn a shitload of money and then enhance their security in the next version or with a firmware update once you'll have the luxury of investing in R&D. At least it's better if a security-wary entrepreneur implements them instead of someone who simply doesn't give a flying fuck.
Keep in-mind that we're talking about always connected devices. Firmware updates could be done remotely without the end user needed to do anything, except perhaps give his approval.
There are way to build things so that this isn't a problem. Modularize.
It's easy to build it in a way so that the worst that the software can do is cause it to turn into a "dumb" fridge.
My problem with this whole hatred of iot is that it's not productive.
it's a bunch of people commenting how the trend is dumb and how everything was so much better in the past. Nobody ever gives suggestions on how to improve it, or how to fix some of these issues, or even what they would like to see. It's always just "Who wants a wifi light switch anyway?" or "Oh great now my door lock can freeze".
> It's easy to build it in a way so that the worst that the software can do is cause it to turn into a "dumb" fridge.
If it's so easy, why don't more companies do it? Why didn't Nest build their thermostats so that when the battery runs out, it reverts to a "dumb" thermostat instead of turning off your heat? http://www.theguardian.com/technology/2016/jan/15/bug-nest-t...
To be fair, most "dumb" thermostats still require an external power source to continue to operate.
Very few actually pull operating current from the 24v C wire if it even exists on the given system. If it doesn't, R (the switched 24v power for Heat and Cold signals) isn't guaranteed to continually have current. Only when your Heat is turned on (probably a standard toggle lightswitch on the side of your furnace) will there be current on the Rh line, and only when your AC is enabled (possibly a breaker shunt on the side of your house near the condenser unit in a small box) will there be current on the Rc line.
Nest tries to recharge it's battery by trickling the C wire, if available, and if not it will try to charge off of one of the R wires, either during normal operation, or it will try and "pulse" the heat signal to pull a little bit of current to keep going. Thermostats were designed at a time where they didn't even consume any electricity on their own. We're trying to retrofit computers into signaling system, not a circuit.
The GP is right: most new thermostats don't take power from the 24VAC line. That surprised me when my heat wouldn't come on one morning because the battery was too weak to pull in the relay for more than a few seconds. That's what I get for ignoring the "low battery" warning! All my previous electronic thermostats only used the battery as a backup.
In any case, are you really saying that using a toxic metal (mercury), or an imprecise bimetallic strip is really an improvement over a simple $10 electronic thermostat?
I should have been more specific by stating the difference between a dumb digital thermostat as I was describing, and a truly analog thermostat like the Honeywell T87.
A dumb digital thermostat is just a thermocouple and a relay, which you could rig together with very little EE knowledge and a weekend with an Arduino.
It's clearly more work to do it that way, as you'd need multiple "layers" of firmware/code which all need to communicate and run on their own, but i personally see that as insurance against the exact situation you are describing.
Nest is far from what i'd consider a good IOT company. They are the epitome of vendor lock in, proprietary and buggy code, and shitty support.
I'd consider Philips one (specifically whatever part of the company does Hue products; even with their recent base-station changes to only work with their bulbs). I don't think their base station has EVER crashed on me, not once. They made sound architectural decisions for the product as a whole - it's not some bloated Linux thing but it runs FreeRTOS and does only what it needs to. I have one of their push-button kinetic power light switches in my setup and I've forgotten that it isn't an old-school lighting setup most of the time. That's because of another good architectural decision - they had the sense to decide that simple RF code-sending to the base station was good enough for the switch, rather than trying to make the switch into some kind of Wi-Fi connected thing running a TCP/IP and web stack (did I mention the switch needs no battery or external power of any sort?). The system stays out of my way and just works when I want it to, while still allowing me to dig in and add-on cool automation where it's appropriate.
The thing I don't get with 'control everything with your smartphone!' is that people don't think about everyday use. It's like the people that design these products don't look at the actual, repeated use cases. Why would I want to pull my phone out of my pocket, unlock it, find the app I need, launch the app, wait for it to connect, hit the buttons I want....
(Even when I'm on Android and I can have an IoT control widget on my homescreen, that's still pulling the phone out, switching it on, unlocking it with my fingerprint, finding the page, hitting the button.... oops I forgot to turn Wi-Fi back on, better do that....)
I think IoT is great, but to do a great job at it you need to design the product with that in mind to begin with. The whole architecture of the product has to fit (see again, Hue). Sure, picking an Android tablet is easy, but why would you architect all that complexity? Why not a touchscreen device with a really simple real-time OS that does only what it needs to do?
I'm confident that this will all be self-correcting in the end. Consumers and 'the market' are smarter than we give them credit for. Certainly it takes a long time for them to react, but I think that when enough of the public is jaded by 'bad IoT' and the fad phase has passed, the actually good IoT products will survive and those companies that really think about their designs as a whole will be rewarded.
I think it's because it's so prevalent. If your car had a faulty AC unit, you wouldn't swear off all cars, because most cars don't have that problem. But I feel like we're all still waiting for an Internet of Things Thing to show up that's actually done right. And it's been long enough that if nobody has done it right so far, it seems like a distinct possibility that nobody ever will.
>And it's been long enough that if nobody has done it right so far, it seems like a distinct possibility that nobody ever will.
But it hasn't been that long at all, and there are people doing it right.
The problem is that they are expensive and don't offer the same amount of features that some people want.
Take the "traditional" smarthome networks like z wave and friends.
I have a z wave light switch that works as a lightswitch 100% of the time. I actually installed the switches before i had a controller for them.
Add a controller and you have a "smarthome".
Connect that controller to your wifi and you have the ability to control these things safely from within your own network using anything from a bash script to shitty iphone apps.
Connect that network to the internet through a firewall and an authentication system and you now can control all of that stuff securely across the planet.
If any one of those breaks, functionality is reduced. Internet is down, i can't control it outside the house. Controller goes down, i can't control them as groups or from within the house but still "remotely". But it will literally always turn on/off the lights when i hit the switch. I don't need to worry about the security of a cheap chinese zwave knockoff thing because the controller is that gatekeeper.
That's IOT done right.
But people don't want to pay the money for that, they don't want to pay an electrician to come out and install them across the whole house, they don't care about security or what happens when the internet is down, they want a light they can control from their phone for as cheap as possible as fast as possible. And of course when people are asking for a product, manufacturers are going to make it.
Indeed, I'm quite happy with my INSTEON system. They're stylish, high quality in wall switches, they have a very reliable (though unfortunately proprietary) communications protocol. The serial and USB adapters for them are easy to code for and there's a variety of third party control programs available. I'm writing my own actually. They also now have a cloud hub for people who want that sort of thing.
If you connected fridge can brick itself in such a way that it stops refrigerating things then it wasn't worth buying in the first place, especially for things like this where you could end up accidentally poisoning someone the failsafe in case of software failure should be switching to an old school circuit that just keeps things at a fixed temperature.
Sure, I'll tag along. Problem is in a few years you may not have a choice because all fridges will be Internet-enabled by default. It's already happening with TVs where 70% of new sets are smart TVs. And you know, personally I don't mind because if it bothers me too much I'd just make sure that the damn thing never gets online access but I doubt the average consumer could go in such lengths. So instead of moaning and bitching about it perhaps we, as a community, ought to think about ways to solve security issues. Otherwise the industry will just go ahead and build them no matter what.
So we're back to a couple of comments above: suggesting that people actually upgrade firmware.
An opt-in switch is merely convenience for the incredibly thin % that bothers with this kind of thing. And that % will actually be informed enough to not opt in.
Come to think of it, that % will likely be informed enough not to buy this kind of device in the first place.
Tesla has a pretty vested interest in shit keeping working considering it's a pretty luxurious and high-profile product. The cut-price manufacturer of your $20 lightbulb or $300 fridge? Not so much.
The cheapest Chromebooks ship at $149 and have a pretty much unbrickable automated update flow that includes the firmware for the CPU and embedded controller(s).
It's not a matter of luxury, it's a matter of having people work on it who care.
Except when you're abroad on roaming cellular charges, and your three laptops decided that since your iPhone's personal hotspot is WiFi, it's time to download today's ChromeOS image version, because the one you had downloaded the night before was not good enough anymore.
Source: Chromebooks are awesome, and even with excesses like this, they're still the cheapest to operate by far.
Chrome OS tries to honor various DHCP server flags that state that the connection is metered. Unfortunately iOS doesn't seem to provide any such indication.
A comment in https://bugs.chromium.org/p/chromium/issues/detail?id=323010 claims that the BSSID is used for a "suspected" state, but that may not be enough to actually stop it from downloading updates, but I'm far from an expert in that domain.
In short, identifying tethering states with iOS seems to be hard.
You can determine whether the network is a Personal Hotspot heuristically. It is nice of them to have implemented private DHCP flags in Android, but if you routinely pull hundreds of megabytes without user interaction...
Then the opportunity is to convince customers why they should pay more for well-supported connected products. Easiest way is to make high-margin products.
That's the Tesla case. Or alternatively the Apple case. The vast majority of customers go with not that, and history shows you won't convince them the intangibles are worth it.
Opt-in just means nobody gets updates again. I realise this is more a techy audience but think of these things from the mainstream perspective. Especially when the tabloids and social network copypastes get the word out that hackers can turn your oven on or something if you enable updates
It is either possible to do something securely and won't really take significantly more time, or it's not possible to do it securely at all, and no future update is going to fix it.
There's a difference in security issues due to programming bug vs insecure design.
If an application was created without security in mind in worst case it might require complete rewrite. In other cases it might be a whack-a-mole game.
For example compare ssh vs application that simply opens port and starts bash as root. You can use both to control your server, but if you want to add security it would be a lot of work (you could incrementally add authentication, encryption, maybe restrict user what s/he can do but there will be million and one ways to escape).
After fixing one issue after another without seeing the end you'll realize it would be less work to just rewrite it from scratch with security in mind.
I think the parent post is talking about a design for security rather than fixing security bugs. A device or system designed without security in mind likely isn't going to get security as a priority at any point in its lifetime, or isn't going to be worked on by security minded folk. Any updates are likely going to be superficial, poorly implemented, or simply not a priority for the developers.
In regards to IoT devices, as the article is lamenting, many are designed with no security in mind and instead seem to be thrown together as quick as possible to achieve a function, without considering the implications that a security breach may have with said device. (e.g., IoT baby monitors, thermostats, home locking systems)
I worked for a startup and found cross site scripting vulnerabilities and other issues like GET urls for deleting things. I was told to leave it alone and not "waste my time" because we dont have a lot of users and we weren't popular. I cringe at the justification. Security should be a necessary skill. It shouldnt be something after the fact
I call this the "we don't do anything special" fallacy. They consider hackers to be something like in the movies where a team of slick black leather clad folks plan a digital heist, and why should a bunch of movie stars care about our little business.
In truth it's much much more like how Google just has computers trying to index every site on the internet that they can find. Most of the attacks these days are broad searching things, just testing every exploit they can against every site they can.
Also, seriously, Google will find and index those GET+DELETE non idempotent URLs and ruin their day.
Absolutely true! I have to tell people that many attacks just try every door to see if its unlocked. They are not movie plot-style targeted attacks. And such an attack can and do lead to data breaches!
This is why I absolutely believe and publicly talk about security being a matter of developer ethics. I have used my walk away power to get a company to do the security they needed in a similar, but not quite the same type of situation.
I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work), and get to them by X iteration". As long as you were really working on an MVP and not a version 1.x .
That's technical debt, and it's hard to fix. A prototype, sure, it can have flaws, it's a proof of concept of feature X, not feature X SECURED. But then the release has to be a rewrite. If it's not, those flaws are more likely to become permanent. And when they do begin work on repairing their codebase, they'll spend several times the money and time to fix than if they'd spent some time early on. They'll also likely introduce numerous other issues in the process.
Ok, I'll clarify: I think they were right as long as it was a throwaway prototype. And the GET delete operations are probably a bad idea even for a prototype. I was thinking of a rewrite for release 1.x.
I don't have enough knowledge of the stage the OP's startup was to have answered, so I stand corrected.
These days, this is the kind of thing I negotiate up front. When they ask me how long something will take, I explain that they can have a prototype quickly, but only if they promise to throw it away as soon as the experiment is done. I explain that they can have me build a movie set or a real house, but that there's nothing in between. [1] And then I leave the choice up to them, explaining that it's really about their business judgement.
Generally people keep their promises on this, although sometimes it takes a little reminding. When they do, the business benefits are substantial. A good product person really benefits from doing quick, cheap experiments. And they also benefit from having a solid platform of high-reliability code for production use. But they can only get the benefits of both if they're careful not to mix the two.
I'm old and have been in this industry a long time, and I'm genuinely surprised on those oh-so-rare occasions when what you describe doesn't happen.
Prototypes-become-products is a trope much like _The Mythical Man Month_. We all nod knowingly when it is mentioned, we all know how it will turn out, and then we (well, management dictates that we...) turn right around and do the opposite.
The problem is those things end up being forgotten or interfaced to in so many places that in the end they become un-fixable or won't be fixed to keep other stuff running.
I was thinking more of a throwaway prototype, but the answers on other threads convinced me it wasn't good advice, and I don't know what stage the OP's startup is.
I build stuff like that - my approach is to limit capabilities to the absolute minimum, and anything that is not needed for function but necessary for debug/diagnostics stays on the device rather than going across the network. This limits the devices a fair bit - firmware update across the network with no local interaction is not allowed, nor is accessing the local data store. Want to email me and talk about this?
Absolutely - and for a light switch it's appropriate. As an example of a thing that needs internet to function, consider a heater controller that has a high power and low power mode depending on momentary cost of electricity - it fetches price data across the network, and it's important to log things like temperature at various points of the device for diagnostics. Now, it's very tempting to send the diagnostic data across the network, but this leaks usage information. It's also tempting to allow things like remote configuration, firmware updates and reading device memory for debug, but that can leak network access credentials or make the device a beachhead for access to the internal network. This is why any feature like that is to be avoided and, if present, needs to be activated from the device itself, not remotely. If you NEED remote control, see if you can limit its scope of functionality to the bare minimum, and consider who needs access to it - in the case of the heater controller, the provider of the pricing data doesn't need to know or control the state of the device, so there's no need to allow that on that connection. Where possible, make the device a CLIENT rather than a SERVER - have the device itself initiate connections, to an address that is entered by local interaction, rather than accept connections from anywhere. If you MUST break those rules and accept connections from anywhere, that's when you really need to spend a fuckton of effort securing every aspect of your device, client applications, and protocol.
I wonder if the competition wouldn't just skip the security, then beat you on the price because you are paying lots of money for security experts. Most customers don't care about/understand security and your company fails.
Find a way to demonstrate the flaws in various products, aim for non-consumer markets. Businesses that have an actual motivation to have secure devices like the hotel in the article would be more inclined to spend the extra money, especially if it at least eliminated a trivially hackable configuration like, again, in the article.
The difference between you and the dunces building things like this hotel light system is that you know that there's a problem and will work to fix it. As the market matures, security will become more important. But the only companies with the chance to fix it will be the ones with substantial market share. And the people who will fix it best will be the ones, like you, thinking about security from the beginning. But that can only happen if people like you get in early and lay down the infrastructure in a way where security will at least be possible.
Android/iOS is an interesting idea for a business.
They already have secure app distribution. A private channel in the Google play store or via app store adhoc.
Communication between the devices via a server should be possible at least using HTTPS but also private/public key encryption. Doesn't have to be an actual server just one of the devices in server mode.
Good point, seems like places get sold products that are smoke and mirrors. If they knew what was going on in the background they would be shocked. Best plan is to build up a big customer base with a smoke and mirror product and then sell out and hope you don't get sued.
Yes, I'm sure that the only thing standing between you and untold riches is your resistance to lax security measures in app-controlled sous vide machines.
The security risk in an app-controlled sous vide machine includes starting a fire that burns your house down.
- Sous vide normally uses a water bath at a controlled low temperature over a long period of time.
- Hike the temperature up past the boiling point, and the water is evaporated, allowing you to hike the temperature up to ignition points.
- Or, cycle the electronics fast enough to overload the power supply. If it isn't designed well, either the wall circuit blows or the power supply bursts into flame.
- In any case, the expectation of a long unattended cooking process means that human observers might not be in the loop.
It seems unlikely that the device received a UL certification without a simple thermal cutoff switch that is common even in low-end cooking appliances.
Even without deliberate hackers, the device needs to contend with software errors, running without water, or a stuck relay that could leave it boiling dry and overheating.
You just need to look at Therac-25 for a device which lacked hardware interlocks/cut-offs, had flawed/buggy software interlocks, and still received certification.
You mean I only need to look back 35 years to a professional medical device built when computer control was still very new and that wasn't intended to be operated by unskilled consumers, and wasn't certified by to be safe for home use?
Therac's often used as the "canonical" example, but there are more recent issues that stem from a lack of a physical interlock:
- VW's dieselgate (although that was intentional)
- Virgin Galactic VSS Enterprise crash
(yes, designed for a skilled operator, but still: no interlock on the brake)
- Pyranha Moulding's industrial oven [1]
- Hotpoint tumble-dryers catching fire [2]
Even without network connectivity, household products still get recalled for issues such as fire risk, because they lack things like thermal cutoffs, or the cutoff is in some way inadequate.
Perhaps 35 years ago computer control was still very new, but right now, IoT is very new, so there's a whole new world of mistakes to learn from, and the evidence is very clear: serious mistakes are being made.
I am coming to the conclusion that these devices should be treated like every other URL on the web. It should have TLs with a proper cert, a global domain name, wifi, and access controlled by something well known like Openid/oauth. With native apps and CORS firewall traversal is solvable without special protocols and adaptors.
