[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
|
Really? The reason X-10's failure was protocol? Respectfully disagree. It's because it was for hobbyists and tinkerers, not the mainstream public...
I think the reason that instrumenting home appliances hasn't taken off is that the value/cost ratio isn't there yet (read: no appliance mfg is going to add production cost without good reason), nor are there enough compelling reasons for the consumer to be willing to pay extra for this capability, beyond those same early adopters who grabbed onto stuff like X10, etc....
-----Original Message-----
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of T-Rob
Sent: Monday, March 18, 2013 1:22 PM
To: m2m Industry Working Group
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
Hi Fabien,
I agree with everything you wrote up to "this issue is solving itself already." Despite being in sync on the supporting statements, somehow we came to opposite conclusions.
We've had X-10 for quite some time now and it never took off. Issues with bridging circuits at the breaker box were solved and it didn't help adoption. The main issue has been that the devices either emitted or received commands but do not respond to state inquiry. However, all their communication is designed to be local.
Now there's a big experiment to go the other way. The devices have considerably more functionality. Not only do they respond to state inquiry, but they often have sensor platforms built in so that a switch, for example, might also report temp, humidity, ambient light and proximity. However the new generation of devices are primarily designed to *not* talk locally and consumer response is predictably unenthusiastic.
The Association of Home Appliance Manufacturers can't figure out why consumers haven't responded. According to the chair of their task force, "We're asking all those questions and inviting people to comment. We need to determine the barriers to getting through. Is it technical? Is it regulatory?" I say, no, it's topology and data openness.
It's not as though consumers aren't interested or that their interest isn't measurable. Vendors aren't giving them what they want, so consumers are simply routing around the vendors and a host of new devices and start-up manufacturers is beginning to emerge. The availability of platforms like DigiSpark or Pinoccio mean that consumer interest in devices with non-local data will only decline over time. They'll either wait for the vendor to get it right or buy a cheap, dumb appliance and upgrade it themselves. The objection I often hear to this prediction is that advanced hobbyists doing custom upgrades aren't going to disrupt the market. My counter to that objection is the availability of services to customize cell phones. Hacking a phone was once a hobbyist activity but with sufficient demand it became a business, and a big one at that. If appliance vendors don't get their act together soon, someone will think to build a wiring harness that interfaces Pinoccio into the most common washers & dryers, then sell that kit to independent service technicians.
What vendors fail to realize is that solving the retrofit problem also solves the new appliance problem. Consumers won't need the vendor version of "smart" device when for the price of a service call and $150 per appliance they can add a whole houseful of "dumb" devices to the local network and be guaranteed compatibility and full access to all of them.
So, no, I don't believe the issue is solving itself already. Or at least if it is, it is doing so without participation of industry.
-- T.Rob
From: Fabien Fleutot <fleutot@xxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>,
Date: 03/14/2013 08:20 AM
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA
presentation)
Sent by: m2m-iwg-bounces@xxxxxxxxxxx
I agree that currently M2M relies too much on physical security, and that the model of the single company owning all of the devices and servers will limit applicability to other domains.
However, when developers depend on a technology they aren't very comfortable with (databases for web applications yesterday, embedded software tomorrow for IoT), they want to put the scary technology in a little sandbox that makes it look, from outside, like the things they're already familiar with. That's the raison d'etre of the many DB abstraction contraptions, of SSL/TLS which exposes a TCP-like or HTTP-like API, etc.
My guess is, they'll want something which abstracts them away from embedded matters as fast as possible: "make it look like my on-field data comes from a regular always-on, dependable, cheap AWS instance, through the usual JSON-over-HTTP interface".
So the "device -> first aggregation server" protocol will probably not be the same as "first server -> other servers". Data ownership issues will be a delicate matter on both sides, but will probably take a different form on each side. How should it be articulated between these two universes, I don't know and it's a very interesting discussion matter indeed.
As for people's concern for privacy and cryptographically-safe ownership of their data, I'm consistently dismayed by how little they care about it.
I would, personally, pay for such a service, but I would certainly not bet money on the fact that other people would. If people cared about this, Facebook, Google, Microsoft and Apple would all be broke, which hardly is the case. A possible consequence might be that they'll trust the entity which takes care of the device -> first server data transfer, and let it operate with very coarse granularity.
For companies, there's a different internal dynamics to take into account:
IT departments want to take and keep responsibility for business-critical data, even if they're less skilles, less safe and more expansive than a specialized operator. But there's no resisting to the move towards the
cloud: this issue is solving itself already.
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
