IoT Anxieties in McKinsey-GSA Study | Hacker News Reader

IoT Anxieties in McKinsey-GSA Study

eetimes.com

23 pointsmtuncer22 comments

Annnnd here we go into the Trough of Disillusionment:

http://en.wikipedia.org/wiki/Hype_cycle

I'm doing a lot of IoT work in the B2B area, where I think these things are going to pick up a lot of traction before the consumer stuff really takes off.

Part of the problem I see is that the chipmakers, at least the ones still standing after Apple and Samsung took the application processor market away from them, are trying to reassure their investors that IoT is a the new revenue stream they all need to look forward to. Looks like they're finally getting that reality check they needed.

The problem is that IoT isn't just a part in a BOM. It's an entire infrastructure that needs to be in place to support it. Even on the B2B side, I can put a wifi chip into a backend technology demonstration and convince the customer they need it...until I ask them what their plans are to host the data and develop the front-ends. Complete blank stares. There are too many parties involved to design this stuff front to back. Perhaps the first company to sell the chip AND the hosting service as one unified package will make headway here.

This still will mature and prosper...in time. Just not yet.

That's actually been happening for a while. Not at the chip level, but businesses providing hosting, analytics services and hardware modules (i.e., a "box" with some I/O and WiFi) as a one-stop shop. Besides Bosch (who entered the business by an acquisition), I can't think of names off the top of my head, but they are out there. Axeda was a big player in the hosting for remote monitoring arena about 10 years ago, but I don't think they ever sold hardware.

More interesting is that I'm already hearing about the companies that are dropping offerings: no longer selling hardware, but just doing hosting and analytics. I don't know if this is due to the hype dying off (doubt it) or just discovering it's more profitable to not have to inventory & support hardware.

And I am also seriously considering exactly this. Have the experience, have (most of) the skillset. Just need to figure out who the customers will be.

I haven't read the article, since the page fails for some reason (getting a contact support message).

Despite that, I'm personally quite excited about IoT. It doesn't just have huge potential in bigger manufactoring processes and places where monitoring and decision making can be automated to a large degree, but also personal value in home automation.

I'm currently writing my thesis which focuses on reactive events, in the sense that devices can subscribe to specific events and they also post their own.

For example: the light in the entrance of your house is connected and will transmit the event,

    {device: 'Light', location: 'Entrance', value: 'On'}

which your thermostat in your living room has subscribed to. It will then receive this event and based on the value, in this instance 'On', change the room temperature by either raising or decreasing it.

I'm very fond of automating things on my computer, so bringing stuff like this into the real world, in an easy way is one of the goals. After my thesis is done I will open-source it, and it'll hopefully be something that people can actually use.

It's funny to me when people try to predict where either the success or failure of a whole concept will come from and when it is supposed to happen. Nobody really knows what IoT is yet.

The exact same thing happened in the early days of the web. People thought search wasn't a big deal; they thought people would buy ice online; they thought that the web should be completely overhauled and replaced with binary executables that we could all browse. When it all collapsed the first time, a lot of people thought that the promise of the web was over.

IoT is in roughly the same place that the web was in the early 90s. I'm hesitant to say this is a trough of disappointment, because I don't think that enough of the key technologies have emerged yet that are going to make connected things an actual convenience to people.

I think the problems that skeptics see actually could be problems, but it really is to early too tell. The problems they see could be problems or they could simply be gaps that haven't been filled yet.

""As the McKinsey-GSA report points out, a major challenge is the security and privacy of user data.""

That, I think, is the heart of the issue. I am working on a new book ("Power Java", with a similar version "Power Clojure") that has a section on IoT. I mention security as a problem, but don't much address the security issues.

The problem is that the model for IoT is discovery of nearby services. If a user has to stop and manually authenticate, it spoils things. Perhaps devices could have unique security tokens and you could verify other devices once.

funny when people with clearly no idea about standardization reurgitate some points from a high-level business consultancy who has also no idea about technology standardizations. In all my years sitting in WG's at ETSI and ITU-T I have not once met a delegate from McKinsey so how do people find them a credible source of info and authority to speak on the subject?

For a start ETSI deleivered a pretty complete standard on M2M: http://www.etsi.org/deliver/etsi_ts/102600_102699/102690/02....

yes this is work in progress but so is anything the W3C does.

If that is not enough then below some further reading if you think standardization is still incomplete. IMO this article along with the original report is utter bullcrap because it confuses lack of standards with "unwillingness to play by these standards" (mostly zigbee):

[1] ETSI TS 102 921: "Machine-to-Machine communications (M2M); mIa, dIa and mId interfaces".

[2] IETF RFC 6267: "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)".

[3] IETF RFC Draft: "An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange". [4] IETF RFC Draft: "IBAKE: Identity-Based Authenticated Key Exchange".

[5] ETSI TS 124 109: "Universal Mobile Telecommunications System (UMTS); LTE; Bootstrapping interface (Ub) and network application function interface (Ua); Protocol details (3GPP TS 24.109)".

[6] OMA-AD-DM-V1-3: "Device Management Architecture", Version 1.3.

[7] OMA-TS-DM-Notification-V1-3: "OMA Device Management Notification Initiated Session", Version 1.3.

[8] OMA-TS-DM-Protocol-V1-3: "OMA Device Management Protocol", Version 1.3.

[9] OMA-TS-DM-Sessionless-V1-3: "OMA Device Management Sessionless Message", Version 1.3.

[10] Broadband Forum TR-069: "CPE WAN Management Protocol" Version 1.3, Issue: 1 Amendment 4. Issue Date: July 2011. NOTE: Available at http://www.broadband-forum.org/technical/download/TR-069_Ame...

[11] OMA-TS-MLP-V3-3-20110719-A: "Mobile Location Protocol", Version 3.3.

[12] ETSI TS 123 271: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Functional stage 2 description of Location Services (LCS) (3GPP TS 23.271)".

[13] OMA-TS-DM-StdObj-V1-3-20101207-C: "OMA Device Management Standardized Objects", Draft Version 1.3.

[14] Broadband Forum TR-106: "Data Model Template for TR-069-Enabled Devices", Issue: 1 Amendment 6".

[15] OMA-TS-DM-TND-V1-3: "OMA Device Management Tree and Description", Version 1.3.

[16] OMA-TS-DCMO-V1-0: "Device Capability Management Object", Version 1.0.

[17] Broadband Forum TR-157: "Component Objects for CWMP, Issue: 1 Amendment 6".

[18] OMA-TS-DiagMonFunctions-1-0: "DiagMon Functions Supplemental Specification", Version 1.0.

[19] Broadband Forum TR-181: "Device Data Model for TR-069", Issue 2 Amendment 4.

[20] OMA-TS-LAWMO-V1-0: "Lock and Wipe Management Object", Version 1.0.

[21] OMA-TS-DiagMonTrapMOFrame-V1-2: "Diagnostics and Monitoring Trap Framework Management Object", Version 1.2.

[22] OMA-TS-DiagMonTrapEvents-V1-2: "Diagnostics and Monitoring Trap Events Specifications", Version 1.2.

[23] OMA-TS-DiagMonMO-V1-0: "Diagnostics and Monitoring Management Object", Version 1.0.

[24] OMA-TS-DM-FUMO-V1-0: "Firmware Update Management Object", Version 1.0.

[25] OMA-TS-DM-SCOMO-V1-0: "Software Component Management Object", Version 1.0.

[26] OMA-TS-GwMO-V1-0: "Gateway Management Object Technical Specification", Version 1.0.

[27] ETSI TS 102 671 (V9.0.0): "Smart Cards; Machine to Machine UICC; Physical and logical characteristics (Release 9)".

[28] ETSI TS 102 310 (V9.0.0): "Smart Cards; Extensible Authentication Protocol support in the UICC (Release 8)".

[29] ETSI TS 133 220: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) (3GPP TS 33.220)".

[30] ETSI TS 187 003 (V2.3.2): "Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); NGN Security; Security Architecture".

[31] ETSI TS 102 484: "Smart Cards; Secure channel between a UICC and an end-point terminal (Release 9)".

[32] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types".

[33] IETF RFC 2560: "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP".

[34] IETF RFC 2663: "IP Network Address Translator (NAT) Terminology and Considerations".

[35] IETF RFC 2716: "PPP EAP TLS Authentication Protocol".

[36] IETF RFC 4366: "Transport Layer Security (TLS) Extensions".

[37] IETF RFC 3748: "Extensible Authentication Protocol (EAP)".

[38] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".

[39] IETF RFC 4186: "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)".

[40] IETF RFC 4187: "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)".

[41] IETF RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".

[42] IETF RFC 5216: "The EAP-TLS Authentication Protocol".

[43] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".

[44] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".

I don't want my Things to be on the Internet. I am so adamant about that that I won't even apply to IoT jobs.

While the common concern is that they have poor security, that's not my concern. What I don't want is for my refrigerator to let my grocery store know that I'm out of milk.

When I'm out of milk, I'll go to the grocery store to pick some up myself - then pay cash.

The problem you described sounds as "whom the device can talk to"

Seems like Stalmans' model is the only viable solution: As long as the user don't control the device, the manufacturers will be allowed to make the device talk to whoever and whenever they want to

On the other hand, I would very much like to be able to see what I have in my refrigerator without physically checking it. It doesn't have to automatically order things, it could just generate a shopping list, based on preferences.

I believe that Samsung has sold such a refrigerator in South Korea for a number of years. This actually came up at breakfast with friends this morning. My friends wife wanted to know why it was not sold in the US.

Then don't by a "smart refrigerator" or connect your refrigerator to the internet. IoT isn't being forced on people, people are embracing IoT.

Were you not around for the Samsung smart TV outrage? People certainly weren't embracing it then, but complaining about how hard it was to find non-"smart" TVs.

You basically can't buy a TV these days and NOT connect it to the Internet, as the buggy firmware isn't fixed until long after is sold. Granted, you can use a usb stick and patch it yourself every now and then, much like your car is updated at service (but how long until cars are updated, and hacked, remotely?)

Easy solution: don't configure wifi on the TV.

That is harder that it sounds in many places, because you don't get to (easily) control the radio signals that cross your house. Windows set a (very bad) precedent a long time ago that devices auto-connect to new networks, so your TV could be using your neighbor's wifi automatically.

That's just the short term problem while 802.11 chips are the cheap device preferred by hardware manufacturers. This will get a lot harder to block when the LTE/WiMAX/HSPA/etc chips become cheaper and the device manufacturers start negotiating deals with the network owners for cheap low-priority batch-job rates. Your TV can store what you've been watching as long as necessary, and upload whenever the cellular network is quiet. Precedent for embedding a cellular radio already exists with "onstar".

I seriously doubt anybody checks that their electronic devices aren't uploading personal data at 3:27AM once or twice a week.

How long will that be an option? There's a lot of benefits to the refrigerator makers to include IoT access, and cross-marketing opportunities with various brands out there.

Just look at the current TV market for how pervasive these things can get.

manufacturers are just steps away to place some internal 3g-like connection inside the device, so they will not need to rely on the user's connection -- while the tech is there, it's not cost effective (yet)

once there, we are doom

This is happening already: Kindles come with 3G (though still optional) and many new cars are now sold with a 3G connection.

I'm confused. Have you never ordered pizza online? Using an app?

The problem with this comparison is that ordering pizza using some sort of webpage or client-side app is still fundamentally the same interaction as simply calling up the restaurant and ordering the traditional way. The same information needs to be exchanged.

Some devices (e.g. a phone or pizza ordering app) require a network connection because that is fundamentally what the device is intended to do: giving you access to a telecommunication network. A phone or pizza ordering app without immediate network access is generally useless.

On the other hand, a TV only needs to receive a video signal to function properly. If you take away the network, the TV is still useful (it can show traditional broadcast-only video, it can show locally-generated stuff (dvd/video game console), or whatever. You might be able to add additional utility to the TV with a network (automatic guide downloads, for example). Adding the network also brings with it the usual risks associated with being on the internet.

Some may find that trading risk for features is useful. A cell phone can have a lot of utility. The problem is when people start adding network chips to products as part of this "internet of things", without considering if the utility outweighs the risks. Unfortunately, there is moral hazard in this assessment: what is good for the end user ("not being spied upon") is in conflict with the business that sees profit in data mining what used to be the end user's private activities.

things get messy if pizza shows up on the door because some "device" decided you should have pizza

>things get messy if pizza shows up on the door because some "device" decided you should have pizza

it will happen anywhere, even if you wouldn't have any "devices" in your home, the "devices" present around, outside of your control, will learn enough about you, and the Big Pizza will buy those predictions to make sure that once you decide to have pizza it is already at your doorsteps waiting. Of course, the same machinery will be used to place police officer right where and when you decide to speed a bit over the limit. They will know you better than you know yourself.

Reply on news.ycombinator.com