Mozilla announces an open gateway for the internet of things
techcrunch.com
techcrunch.com
1. The problem isn't the transport layer, it's the application layer. The transport layer is mostly solved via MQTT, COAP, Thread, etc. Sure, we can improve there, but the real problem is the application layer. So I applaud Mozilla's attempt to bring something into this space.
2. Bootstrapping this will require a substantial number of hardware vendors to sign on, both at the edge and at the hub layers. IMHO this is why Google Weave [1] never took off in it's original incarnation. Bootstrapping this like they did with web stuff isn't enough, because this isn't the web.
3. Devices are only part of the problem: We need a software services layer, too. Think time services, IFTTT-like orchestrators, media services, etc.
4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse.
5. Request-Response isn't the right pattern for most use cases.
6. The Property/Action/Event concept is a solid start.
7. For the love of everything holy, add versioning!
[1] http://internetofthingsagenda.techtarget.com/feature/Google-...
Edit: Grammar.
Our company does Device integration stuff but most of the big guys are using older automation systems (typically a bms)
We have not seen any significant adoption of iot so far. Maybe our market is just different.
* Industrial IoT - If I had to guess, most of the projects are 95% analytics, 5% command and control (i.e., configure machines and/or centrally control them) - PLCs make this suck, but as that moves to SBCs we're seeing that improve. Energy management, too. Get a lot of questions about Industry 4.0, too.
* Transportation - Mostly telematics (GPS, listening off the CAN Bus for events, etc.)
* Healthcare - RTLS, some basic analytics. C&C is unlikely due to security and use cases.
* Retail - Restock tracking, footfall traffic, etc. Ordering by voice. ("Alexa, I'd like to order 5 cases of carrots")
* Consumer IoT - Voice, energy management (Europe has some great use cases here), some analytics. C&C is big in this this space. "Alexa, set my Jenn-Air oven to 350 degrees for 25 minutes" was a recent project.
* Insurance - The 5 five all have innovation groups very intent on IoT, but I haven't see a really great use case yet.
* Smart City - Energy management, parking. We weren't involved too much, but our city's snowmelt system is another example: https://runengine.com/vroom/58-smart-city-snowmelt-monitor (The guy with the beard is one of my SAs)
https://www.hackster.io/kayakpete/snowmelt-system-monitor-be...
One last thought: I've noticed is that IoT really screws with the traditional "Enterprise Architecture" patterns. Startups are going to kill it once they figure that out, because traditional enterprise architects are lost in that space.
I imagine the "Enterprise service bus" architecture is probably a good fit, but maybe I'm missing something.
I've seen someone have intimate contact with Beckhoff PLCs and the upgrade story isn't great, plus using git with it tends to be painful, and writing modular code seems so too. It would be great to learn about an alternative that's more hackable.
Thanks!
Data Science & Data Engineering don't require an EE background
> 4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse.
ASN.1?
https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
> ASN.1 is similar in purpose and use to protocol buffers and Apache Thrift, which are also interface description languages for cross-platform data serialization. Like those languages, it has a schema (in ASN.1, called a "module"), and a set of encodings, typically type-length-value encodings. However, ASN.1, defined in 1984, predates them by many years. It also includes a wider variety of basic data types, some of which are obsolete, and has more options for extensibility. A single ASN.1 message can include data from multiple modules defined in multiple standards, even standards defined years apart.
[0] https://capnproto.org/news/2013-12-12-capnproto-0.4-time-tra...
There's also "lite mode", which #ifdef's out all the dynamic stuff:
./configure --disable-reflection
https://github.com/capnproto/capnproto/issues/634
There is also a C implementation of capnp which I believe is designed for small footprint, FWIW.
It’d be useful to be able to just use the serialization protocol. Currently I’m using MsgPack which works decently well to get data from embedded cores but I’d prefer typed structures. Thanks for the feedback!
Although KJ style prefers exceptions, the library is carefully written (and tested) to work with -fno-exceptions. KJ_ASSERT/KJ_REQUIRE invocations (which normally throw exceptions) can define a fallback path to use in the case that exceptions are disabled, usually involving returning some sort of dummy value. You can also register a per-thread exception callback which will be called on all exceptions before the fallback starts (or before aborting, if there is no fallback).
from https://essr.esa.int/project/asn1scc-asn-1-space-certifiable... :
> ASN1SCC is an ASN.1 compiler that was developed for ESA to cover all data modelling needs of space applications.
> The compiler is targeting safe systems and generate either Spark/Ada or C code. Runtime library is minimalistic and open-source. The tool handles custom binary encoding layouts, is fully customizable through a code templating engine, generates ICDs and automatic test cases.
https://github.com/ttsiodras/asn1scc
> This repository contains the complete source code and tests of the ASN1SCC compiler ; an ASN.1 compiler that targets C and Ada, while placing specific emphasis on embedded systems: no black-box run-time library, portable code able to run under any OS (embedded or otherwise), no dynamic memory used anywhere, etc.
See also blog post about it: https://ttsiodras.github.io/asn1.html
There are plenty of more modern binary formats that would be a good alternative. CBOR, MessagePack, Protobufs, etc.
Maybe a web implementation with all it's built in protections really is the most pragmatic solution even if it isn't light weight.
I think a safe language like SML/ocaml, erlang, or rust (each with various performance/productivity tradeoffs) is a better solution if we can get a secure framework on top.
Client certificates can cover the client auth side although there are gotchas:
(1) dealing with revocation is more difficult as devices can more easily become compromised (physical access = extracting keys from flash/RAM.)
(2) assume a vendor issues a unique client cert on every device, and the chain reaches a CA. For multi-tenant cloud vendors, you still need to figure out which e.g. Philips Hue bulb is Bob's when Bob logs into his cloud portal. So there's a pairing issue that usually requires a one-time-pad or similar. Right now everyone does that differently.
To put it another way: Mozilla proposal needs to work with _multiple_ security models. They won't get there overnight.
To me the big news here is not the gateway, it is the "Web Thing API" that you can read at https://iot.mozilla.org/wot/
This is a W3C draft about something that is badly missing currently: a common language that devices can speak.
"This document describes a common data model and API for the Web of Things. The Web Thing Description provides a vocabulary for describing physical devices connected to the World Wide Web in a machine readable format with a default JSON encoding. The Web Thing REST API and Web Thing WebSocket API allow a web client to access the properties of devices, request the execution of actions and subscribe to events representing a change in state. "
This is meaningful work that can impact you in a big way. Don't dismiss it too quickly.
As I see it the problem with IoT isn't features, it's the absolutely abysmal security record. I mean, it's abysmal in home ADSL routers, what are expecting of companies just churning out one-off IoT things?
Maybe they should start out by mandating an update policy[1]? ... but then of course nobody would join, so what to do...?
[1] I'm not talking about a concrete schedule, just a documented human-readable policy of what their usual schedule would be (if any), and how severity levels work (for them), etc.
-------------------------------------
EDIT: HN won't let me post again "too soon", so here's my reply to "st3fan":
> Ok, what does this actually mandate and how many actual devices adhere to this standard? What is the motivation for any particular device manufacturer to adhere to this "standard"? (etc. I'm sure you can come up with your own questions.) Also, shouldn't this other standard at least be mentioned in the IoT standard and match the key word "security"? This whole IoT thing is an omnishambles.
Open API would allow the open source home automation systems like Home Assistant to have integrate with the services. Or make easier for Google Home and Alexa to control the open source systems. Or apps that control devices and gateways from different companies.
It takes more than two decades for browser implementers to recognize the need to follow specs as much as possible. The only way to replicate that without the two-decade mistake again would be a compelling toolsets available. Docker got people interested in containers, so Docker has the influence in driving the standard, although I am not really sure how many implementers will participate and willing to bend.
In general, the dominant one has to be willing to let go of its "pride" so others will "follow" to beat the dominant one. Otherwise everyone will be busy beating everyone and forget about consumers (which includes developers).
As far as I can tell Mozilla is one of the only institutions with the resources and incentive to do all of this. I'm not altogether convinced they won't fuck it up though - the way they handled firefox OS was not encouraging. They might spend all of their time stroking their beards and deliberating over where to put the comma in their specs rather than getting their hands dirty with no-brand Chinese hardware manufacturers and figuring out all of the subtle problems that can arise building a network of devices and the not so obvious use cases.
If I were running mozilla I'd put the office for this venture in Shenzhen and make sure that the employees visit often and work closely with OEMs because if you keep these people away from actual manufacturers then the result is going to be pretty poor.
- It's mostly done by companies that use hardware as a delivery platform for their cloud services, trying to vendor-lock you, in delusion that they'll be The Next Platform. This results in an extremely user-hostile ecosystems.
- Said companies develop IoT devices with little or no regard to security and protection of user data.
- The business strategy of tying everything into my butt means things are not interoperable by design. I don't see much incentive for IoT vendors to accept standard protocols that go against the core of their business.
- Now W3C wants to tie IoT into the web. The web is a total clusterfuck. JavaScript is not a language suited for this task, and its ecosystem is doubly not suited to working on this.
Maybe I'm just grumpy, old (by web standards; I'll be 30 this year) programmer who desperately tries to turn an unstoppable tide. One who believes IoT should stand for Intranet of Things. I can believe this is "work that can impact me in a big way". I'm not convinced this impact will be in any way positive.
It'd be nice if there was one standard, and you could buy devices that use your local server or phone home (but not both), but for all the reasons you stated, I don't see that happening. The average consumer just don't care enough.
what...
Do you, by chance, have a browser extension that automatically modifies instances of "the cloud" into "my butt"?
Isn't that the point of this? We've got AWS IoT, Artik, Xively, Google Cloud IoT.. I've looked at a few and they basically all do the same thing in a slightly different, incompatible way. If we get something that enough people agree is "the standard" then maybe you can define a single device schema and connect to any of those services interchangeably.
> I don't see much incentive for IoT vendors to accept standard protocols
But we see already this is not the case. Cloud providers give MySQL/ Postgres compatible storage, Docker deployments... Consider that customers are already faced with "do I want to tie my product to this cloud backend" when it could be "oh good Artik supports the ""IoT standard"" let's go." There's still tons of incentive to stick with one platform.
> Now W3C wants to tie IoT into the web. ... JavaScript is not a language suited for this task
Not sure what you mean about JavaScript, they use JSON to represent the schema, and WebSockets as the transport but presumably you could use a websocket library written in any language.
Personally I did hope to see MQTT bindings and/or weight thrown behind CoAP but maybe those will come along later.
I think the name of this technology may be leading to some confusion here. From a quick read-through of the API description (https://iot.mozilla.org/wot/), it doesn't seem to have anything to do with JavaScript except that there is a small amount of example code showing how to open a WebSocket. (But you can open a WebSocket from other languages, of course.)
This whole technology seems to center around using RESTful HTTP and WebSocket to discover and manipulate IoT devices. It doesn't seem to have anything to do with using a browser as the client. A more-accurate name might be "HTTP/WebSocket of Things", but that's a mouthful.
At any rate, the API document just describes using GET/PUT/POST and so on to do things like discover actions, read sensors, and actuate things.
The web is better of if we can somehow shake it off a bit, removing all the cruft we've accumulated and stopping making shit websites---and stop wars and cure hunger worldwide while at it, I know what I'm saying is pipe dreams. I'd be glad if Mozilla wouldn't implement this, and was a bit more opinionated in general. It sometimes stinks of yet another SV startup but in disguise of freedom fighters. I'm looking forward to nEXT browser, where at least I can presumably stop WebKit from doing silly things via some lisp here and there (I'll reach the good times where I run Emacs and nEXT on GuixSD, turtles all the way down!).
<hat type=cynical> Like SNMP, but Invented Here. </hat>
en.wikipedia.org/wiki/Simple_Network_Management_Protocol
Most of HN mistakenly assumes IoT == putting cameras and microphones on televisions with no security (eg, super stoopidity), when in fact IoT is a powerful way for businesses to monitor/diagnose/control remote devices (like jet engines, vending machines, stop lights,...)
But I don’t see what Mozilla has to do with that, nor why we need some kind of “gateway” or json spec when it’s just yet another internet device.
Actually of course it’s about collecting data for predictive maintenance and to help in making design improvements.
[1] OK, maybe not full control over the engine because that's not how it works, but it has full control over the embedded monitoring system, which is still pretty bad.
IoT means different devices connecting to internet and/or each other. A jet engine is part of a closed system, there is no need to use a standard protocol to communicate to it. You don't just pick one and plug into a multi-million-dollar plane. Vending machines need no special protocols to connect to other things, because why would they? And stop lights. These things may connect to some server or maybe each other, but no standard protocol is needed, if a traffic light isn't supposed to talk to a random device passing by (and it isn't supposed to).
A gateway to block all those devices, that could be useful.
These don't necessarily need to be the same system, only one might need interactivity, but there's certainly a case to be made that both devices could reasonably want to communicate with passers-by.
Mozilla has a) no track record of doing small embedded systems b) a very negative track record of failed projects, so it very much makes sense to be very skeptical.
Keep your cancerous web trash off my metal!
https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-fu...
If Persona counts, then so should Rust.
So I would assume this announcement is the fruits of that side project.
A couple of members of the small team (5 people) who built this gateway were indeed former FxOS/CD staff.
That surely was a fuckup. Lessons learned can be read here[0].
> ...and there was a partnering I read of with a German web company.
Think of it as a default search engine that's applied to 1% of new German installs. Other 99% remained on the Google(Yahoo) deal(s) (which apply to Germany). My opinion is that it was blown way out of proportions. That company also purchased Ghostery, Mozilla invested some money in it[1] before they did this, and is also making its own private browser (Cliqz).
> Then also there's the case with Pocket where it was (and if I'm not mmistaken still is) installed by default.
Pocket started as a Firefox extension in 2007, raised 7.5 million of investments in 2011 and 2012, got bundled with Firefox by default in 2015, and then the whole startup became a subsidiary of the Mozilla Corporation in 2017.
The Pocket button itself never did anything unless you click it. Extensions are now open sourced[2], apps are on their way (I think, I thought their code was online already), and I don't know about the server code. I am not familiar with what happened with the data between 2015 and 2017, but I presume that the data didn't get shared outside modern-day Mozilla Corporation (to confirm that, one would need to chase down Pocket's previous Terms of Service).
[0] https://blog.mozilla.org/firefox/retrospective-looking-glass...
[1] https://blog.mozilla.org/press-uk/2016/08/23/mozilla-makes-s...
DISCLAIMER: Affiliated with the Mozilla Foundation, not the Corporation (therefore, not affiliated with Pocket nor Firefox, other than being a happy user of both).
Burda is mostly known for its tabloids (e.g. the clickbait magazine Focus that loves spreading conspiracy theories) and for its malware-serving ad and tracking networks.
That’s the company that Mozilla, by default, sent the autocomplete data of 1% of German users to.
That’s sure to inspire trust^H^H^H^H^H
I don’t know how many vendors use this IoT flavor of XMPP but my guess would be not many. Implementing it on a micro controller would not be fun.
Besides that, bandwidth and code complexity is a very real concern. MQTT, a lightweight message passing protocol, has become the de facto default.
I laugh to myself when some business people think their IOT widget is the best thing ever. Then I tell them why it's freaking insane or stupid. They look at me like I am a luddite. Thankfully, that is minority of my interactions. Still there are enough of them that it's far from a non-existent issue.
Just connecting something to the internet does not make it better or you just want to monetize with software activated features. A lot IOT devices provides no additional value. A lot of times it decreases the objects value. It makes vulnerable to hacking, and has more possible points of failure, and potential more overhead for the end user to maintain it.
I am not saying all internet connected devices are a bad idea. I just see a lot business people basically taking the latest hype Koolaid and mixing it with existing things. Then they think it's the greatest idea since sliced bread, and that everything will be connected to the the internet. It's one thing to throw many things at the wall to see what sticks for some people that is one way of discovering what works. However, I hate how pervasive some of the IOT hype is getting. I was talking with someone the other day that literally thought that any device that could not connect to the internet was useless for today's society...
Any ways I am sick of hearing about IOT. The fact Mozzila is even trying to get in on this madness is disheartening.
I share a lot of your reservations about IoT. But at the same time, for those things that are going to become successful, I'd really like there to be a unified and open integration for them, rather than each one being their own little walled island.
So from that point of view, I'm actually glad about Mozilla (or any other party) building an open infrastructure for IoT, rather than leaving it to others to build proprietary solutions.
Some things, especially automation-control things, benefit greatly from being IoT.
There are things that can benefit from remote monitoring and control.
However, what's the point of an internet connected blender? There is so much hype that I would almost avoid using the term unless you want to taint your product with such associations.
What's more likely? A brushless motor fails, or my wifi password changes when I replace my router, I move my router and its out of range for the pool pump, the pool pump pushes out a bad update, the pool pump company goes out of business, some IoT specific electrical component fails before the actual pump fails, or something of that nature.
But do you really, truly believe that the world 100 years from now will not consist of massively connected devices? Can you admit, honestly, to yourself that the preferred method to turning on lights in 2118 won't be a voice command?
I don't mind voice command, but I don't like the privacy implications of an internet connected system that's always listening in my own home.
2024: IoT voting machines are deployed to a majority of US polling places. Peter Thiel is elected President in a stunning upset.
2025: Tavis Ormandy dies in a tragic IoT jetski accident.
2030: All new cars are required to have fully autonomous and connected control.
2040: Cars produced before 2030 are taxed at 50% of their initial purchase value per year.
2045: North Korea deploys its long-held stockpile of cyber-weapons against the perceived EuroAmeriUnion threat, causing mass fatalities in IoT cars. Since North Korea's vehicles were all produced before 2030, the EAU is forced to fall back to a nuclear response. In its last, desperate act of retaliation, NK's leadership releases its cyber arsenal on the public internet.
2046: In the ensuing nuclear winter, hacker gangs desperately rampage through the Internet of Things in search of food and fuel. Only those with non-connected possessions are unaffected.
I'll be dead either way, but it's not hard to imagine the IoT turning ugly.
Can you think of any good reasons?
MQTT isn't a web protocol and the goal here is to give things URLs on the web. But I'm aware of some Web of Things implementations using MQTT over WebSockets to benefit from the QoS features.
Is the RPi gateway capable of local speech recognition that can compete with Siri, Alexa, Google? That seems unlikely, unless it has a dedicated processor for that purpose.
Personally, I'm not one for using Pis as computers, because I have always running computers at home anyways. I'm quite confident my computer can handle adequate voice recognition, though most companies today have avoided developing solutions that run locally.
EDIT: Fixed typo
If nothing else, you could probably just hook up the AIY voice kit to it. If the software for the AIY voice kit runs on that OS image, it's pretty trivial to do it. There're multiple tutorials about how to make that happen.
We were doing local speech recognition and full voice dictation back in the 90's through products like this (https://en.wikipedia.org/wiki/Dragon_NaturallySpeaking). Back then your typical computer had a 100Mhz processor and would be lucky to have 32MB of RAM. So yes, with 20 years of progress the much more powerful rasberry pi should be able to handle it just fine.
Make no mistake, siri, alexa and google are spyware, they send your information to themselves because they want to, not because they have to.
I have worked with several speech recognition softwares, and the ones which can run on a low-powered device in real-time today are not the ones reaching 95% accuracy.
Dragon was trained for me, google is trained for some mythical "everyone".
> These systems typically use deep convolutional neural network (CNN) architectures ... driving the word error rate on the benchmark Switchboard corpus down from its mid-2000s plateau of around 15% to well below 10%.
https://hacks.mozilla.org/2018/02/how-to-build-your-own-priv...
The web of things started in 2007, somehow it does not gain any traction, is this gateway using the same conception: https://iot.mozilla.org/wot/
Both are referring web-of-things and nodejs/json etc
> Do you think Rust is not going to "survive for any length of time" (the OP's quote)?
That was not a quote of the OP, which was "survived" in the past tense. Hence, my comment.
You are talking about the future of how long you believe Rust will last, not about how long other technologies have failed to last.
Please, drop this. It is becoming nonsensical.
The Internet wasn't built to improve peoples' lives either, but once in the hands of people, can be used to do that.
Certainly some IoT device will improve peoples' lives, and some IoT device (or many) may make them worse.
If you figure out how to make IoT improve peoples' lives, you may be able to make some money though :)
There is definitely something magical about leaving your house and having your lights shut off and your door lock automatically, then coming home after a long day and having your door unlock and lights come back on.
It's not such a drastic improvement or change, but it feels like attention to detail. IMO, reducing the number of things I have to think about on a daily basis to live my life is an improvement.
I call this “life UX,” and you’re exactly right about the way these small, subtle changes add up to surprisingly significant improvements.
People once groused about the complexity of fuel injection, too.
One way or the other, for example, automated cars are coming. We can say "but trolleycar problem!" Sure, we need to worry about that! But, no matter how hard we gripe about all the problems and scary things about the new tech, it is coming. It will happen, because there is profit to be had there and it is more efficient than having humans drive and a million other reasons that more than overcome the obstacles.
So, an IoT lightswitch may not be as inevitable as self-driving cars, but IoT valve meters sure as heck are, or IoT lightswitches for an oil rig, or IoT smoke detectors... in fact, some of these might become legally required, once they get robust enough! (similar arguments have been made that it may become illegal to drive a non-autonomous car without lots of training/licensing)
So, people like you and me, that prefer zippos and straight razors and automatic watches over quartz watches and fountain pens and manual-transmission cars, we'll still be able to have our mechanical switches, we just won't live in a world where everyone wants those things.
If you find manually managing those things easier than the occasional firmware update and making sure you buy things from companies that are reasonably reputable and have decent security practice, then by all means stick with regular options.
People have an annoyance. They think, "I know, I'll add more technology to my life." Now they have two annoyances.
Wait, in this scenario am I blind & deaf or something? Because I can see my lights turn off when I leave and turn on when I arrive. I can hear and see the lock close when I leave and hear and see it open when I return.
I'm definitely not saying IoT is perfect, but this argument is idiotic. I can also leave my lights on and forget to lock my house with a manual setup, both things I have done before as I'm sure we all have.
Honestly, for a community of users that is entirely focused on tech startups, this is a ludicrous amount of FUD.
I'd like houses to have something like central locking, like cars have had for ages. I just don't want it to depend on the Internet, except if I deliberately choose to connect it somehow.
I'd also like to be able to read my gas meter without having to change my clothes afterwards having fought my way through dense vegetation and spiders' webs and knelt down in the mud. But I don't want a "smart" meter connected to the Internet. I just want a local radio link to my own hardware.
Any chance I could have these things without having to build them myself?
80% of the comments in this entire thread are about the woes of connecting everything to the internet which is a fair concern but it's not like non internet connected equivalents haven't been available for decades.
Of course you don't. You'd have to be an idiot to believe that. So my main point, that technology makes shit more complicated with more failure potential, stands.
I can see how it would feel that way if one didn't know too much. Google home devices were caught with their microphones stuck open constantly uploading within weeks of release.
What makes you think you won't get a doorlock that gets stuck in an open/close loop and just oscillates, allowing a burglar to just stick their shoulder against the door and wait for the bolt to retract? Are you going to remember to check after every firmware update? Are you even going to know if a firmware update is issued?
Will it still be magical if you get declared a legacy customer[1] and your door is programmed to unlock and stay unlocked? Will you even follow IoT news close enough to be confident that this hasn't happened to you?
Myself, I'd prefer a door lock that locks only when locked, and unlocks only when the correct key is inserted into it. I've /certainly/ seen one too many crazy software errors to believe in a stove that has the ability to turn itself on and off.
[1] https://www.theinquirer.net/inquirer/news/2453441/revolv-use...
The door refused to open. It said, “Five cents, please.”
He searched his pockets. No more coins; nothing. “I'll pay you tomorrow,” he told the door. Again he tried the knob. Again it remained locked tight. “What I pay you,” he informed it, “is in the nature of a gratuity; I don't have to pay you.”
“I think otherwise,” the door said. “Look in the purchase contract you signed when you bought this conapt.”
In his desk drawer he found the contract; since signing it he had found it necessary to refer to the document many times. Sure enough; payment to his door for opening and shutting constituted a mandatory fee. Not a tip.
“You discover I'm right,” the door said. It sounded smug.
From the drawer beside the sink Joe Chip got a stainless steel knife; with it he began systematically to unscrew the bolt assembly of his apt's money-gulping door.
“I'll sue you,” the door said as the first screw fell out.
— from Ubik, Philip K Dick, 1969
(Dick failed to foresee the convenient ability to have everything automatically debited from your Alexoori account. That, and the annual applobe variation so you can't unscrew your door with a knife.)
Door locks are security theater anyways. If someone really wants to rob you, it's not difficult to get into a house.
> Are you going to remember to check after every firmware update? Are you even going to know if a firmware update is issued?
No, for the same reason I don't check if my computer requires my specific password every time I log in. I'm not that paranoid.'
> Will it still be magical if you get declared a legacy customer and your door is programmed to unlock and stay unlocked?
That has never happened. Even in the example you cite, they caved and offered users a full refund.
> Myself, I'd prefer a door lock that locks only when locked, and unlocks only when the correct key is inserted into it. I've /certainly/ seen one too many crazy software errors to believe in a stove that has the ability to turn itself on and off.
Go for it. While you're at it, make sure you don't get a car that has a remote start or an unlocking keyfob, or a safe that unlocks with a code. Wouldn't want that scary technology near your locks.
That doesn't compute. If that's the case, then why pay for a smart doorlock? Just stop locking your door.
>That has never happened. Even in the example you cite, they caved and offered users a full refund.
They caved in and offered a full refund /for the hub/, which is the minority cost. No refunds on the compatible bulbs, thermostats, etc that it was made to work with.
>While you're at it, make sure you don't get a car that has a remote start or an unlocking keyfob, or a safe that unlocks with a code.
You're trying to be sarcastic and paint me as a luddite, but you don't know the domain you're opining about. You really /don't/ want a car with a remote start mate, they're already well broken and have been for years: https://www.nytimes.com/2015/04/16/style/keeping-your-car-sa...
Your insurance company might feel otherwise. Security theatre serves a purpose, but acting like a deadbolt is some amazing security measure is ridiculous.
> They caved in and offered a full refund /for the hub/, which is the minority cost. No refunds on the compatible bulbs, thermostats, etc that it was made to work with.
Which is why standards are good. Buy ZigBee bulbs and compatible items. Lack of standardization is common in all new industries. Taking one token example and using it to paint the entire concept as bad is also ridiculous.
> You're trying to be sarcastic and paint me as a luddite, but you don't know the domain you're opining about. You really /don't/ want a car with a remote start mate, they're already well broken and have been for years.
I'm well familiar with the issues with remote start. I'm also familiar with the ability that spark plug has to thwart a traditional key.
Once again, if you want to steal a car it's not hard. This is what I'm talking about. For some reason people insist on holding digital locks to this ridiculous standard, when we all know that 99% of consumer locks are intended to "keep honest people honest" and not to actually thwart a real criminal.
Digital/IoT locks meet and exceed that standard IMO. You're letting perfect be the enemy of good, and it does come off as luddite FUD. "I'm scared of this change and what it could do, so better to just stick with the devil I know."
Here are some things that have been improved for me:
- being able to set my thermostat to vacation mode while at the æroport (via an Internet-connected thermostat)
- easily playing TV & music (via Chromecasts)
Neither of those is nothing, and I'm really glad for the ability.
...Which should be enough of an answer if you have ever lived in Chicago, but suffice to say, temperature here ranges between -10 and 110, and has the incredible ability to swing 50 or 60 degrees in one day. And my favorite situation can happen where my house is too warm but it's too cold outside to safely operate the air conditioner...
Anyways, fire and forget doesn't really work for my thermostat, I need one I can monitor and control, especially if the weather changes unpredictably here. One of my pets in particular is extremely sensitive to temperature, and I actually have a secondary thermostat monitoring the temperature by my pets, which can swing a good 6-8 degrees from the temperature at my master control.
Today I had a power outage at home. I got notifications, the computer controlling my home (and my router and modem) are on UPS, and remained online. I was able to remote in and verify that after the outage my thermostat was where it was supposed to be and doing what it was supposed to.
I also have had a computer light on fire before, so I'm pretty wary of fire concerns. My computer monitors my home's smoke and carbon monoxide alarms and notifies me as well. While there's no chance my pets might still be alive by the time an outside party notices something wrong in my home, there's a reasonable chance I could call the fire department and they could intervene before all of my pets perished.
A close relation is a firefighter, the one thing that sets him apart from everybody else that I know is that he religiously powers down (as in: unplugged) all consumer electronics before leaving the house. Now, obviously, that is a job related thing, he's seen more than anybody else that isn't in the firefighting business what causes home fires. But if I had had a computer light on fire in my house I probably would switch it off when I'm leaving, and you are making me wonder if that wouldn't be worth it for my home system (which is normally on for years on end).
I do spend a lot of time keeping the power supply and the airways dust free, that's one reason computers overheat.
My PC fire specifically happened due to a melting Molex to SATA adapter, I learned the "Molex to SATA, lose your data" adage after this incident, and I've actually purged any such adapters from any of my builds. (They're cheaply made, as the case is.)
I was super lucky, it happened while I was nearby, and I was able to shut off the PC before it became more than a purely electrical fire. (And the computer it happened in still works!)
You can see the damage here: https://twitter.com/ocdtrekkie/status/684565735197163520
It was super lucky: I had already gone to bed, but got up again for just a minute when I discovered the fire. Counted my blessings that day for sure.
I fail to see this as I get older as well. And my parents failed to see it with smart phones as they got older. And their parents with early-day PCs and so on.
I got smartphones, but tablets eluded me.
Now all women I know use them every day and I even made an app for the iPad.
I personally would not install any IoT devices that require access to anything outside of my home network and even then only if I see no other solution.
So far no devices have crossed that threshold.
For different people the advantages are going to be different, but for some people there's a lot of anxiety involved in whether they did or didn't do something at home before they left. You could argue IOT can reduce their anxiety and therefore it gives them a higher quality of life. But possibly they just find other things to be anxious about :)
We do IOT for farmers, it allows them to manage their crops far more effectively, saves them money.
Care to elaborate?
Easily solved with separate networks or vlans etc...
Are you saying that for the most trusted servers TLS is needed, but less trusted servers can be spoken to with less security?
You've got a fighting chance in a corporate network where you can deploy and manage the Root CA via Active Directory/Group Policy, but managing it at home with consumer-grade devices... not gonna be a good day.
Maybe not the perfect solution for most users though.
Personally I've been running my own domain + wildcard for a few years, it'll be nice to remove the cost of the wildcard from the setup.
1. https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
I'm assuming they're still going to need to get refreshed on a regular basis, but this is a great step in the right direction!
"This story was produced with support from the Mozilla Foundation as part of its mission to educate individuals about their security and privacy on the internet."
Considering the timing of both the announcement & Gizmodo piece, suddenly the line "story was produced with support from the mozilla foundation" sounds just like another ad. I wish Gizmodo / Mozilla would be clear of what Mozilla contributed. Especially because Mozilla positions itself by accepting donations.
¹ https://gizmodo.com/the-house-that-spied-on-me-1822429852?re...
Also, there can be different protocols for talking to devices and for talking between computers, gateways, and services. Most home automation devices don't speak Internet protocols and need a gateway as bridge and implement more complicated controls. Devices need to worry about low power, bandwidth, and limited processing power. Might be good idea for security if devices aren't available on Internet routed protocols.