Re: [m2m-iwg] Consumer device security (was: M3DA presentation)

[T-Rob <t.rob.wyatt@xxxxxxxxxx>]

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