Headworx

There is a fairly common misconception about security (in IoT systems) that it is all about encryption. Security is about protecting secrets, right? Not quite... In most systems what really matters is authentication. I am a door lock. You are sending me an "Open" command. Does it have to be encrypted? Not really. It is like in the analog world you would want to hide the fact you are opening the door. Even if the "unlock" command can be heard by my neighbors... so what? The key part is authentication. I, as a lock, have to trust the command is legitimate and it comes from a legitimate authority. I have to be able to cryptographically verify nobody altered the command. And who is the originator. If it is a verified command coming from a verified trusted source, I accept it, and open. It does not matter the neighbors around can hear it. They also see me standing at my door. So it is rather obvious I am commanding the door lock to open. I don't need to hid...

It has been a bin unexpected start of the Smart Home Year 2016. Greg Burns moved from Qualcomm to Intel. And now in an unusual style both companies are shaking hands together merging Allseen/Alljoyn with OIC. What comes out is the Open Connectivity Foundation (OCF), backed by both eternal enemies, as well as some other industry heavy weights: Microsoft, Cisco, IBM, Honeywell, Samsung and a bunch of others. And if you did not follow the news, the entire UPnP is there already. Only Google and Apple are missing. But having Intel and Qualcomm joining forces, and especially Qualcomm accepting the defeat of Alljoyn, is both unexpected and positive. This may really hint for reduced technology fragmentation in Smart Homes. Fragmentation that has been the key reason this market is still far from the full potential. So it suddenly looks like we are down to three Smart Home platforms: OCF, Google/Weave and Apple/Homekit. Apple will probably not be able to pull it off, as they are still con...

It looks like the Apple iBeacon standard has just got a serious competitor: Google Eddystone. Not that Eddystone is this week's breaking news. It was released some time ago and even before the Google beacon format had been promoted as the Physical Web. But the big news is Google Chrome, version 49. Available in beta now. It natively supports Eddystone URL-broadcasting beacons. What is the big deal here? Beacons no longer require an app or any Cloud platform. Here is how it works. A Bluetooth Smart radio (which can be a standalone product or can already sit in another product like a lamp) broadcasts a URL. A good, old, well known URL. A phone with the Chrome browser installed (pretty much 90% of phones today) picks up the broadcasted URL and pops a system notification. A user - if interested - clicks on the notification and opens the URL. The URL can point to anything. A bus stop may point to the timetable URL. A painting in a museum may point to the web page with more info...

There has been a lot of noise around beacons for the last couple of years but they still do not seem to be nearing a mass scale market adoption. There are two reasons for that. One is the technology fragmentation. We have the two competing standards: the Apple iBeacon and Google Eddystone. But that would not pose too much of a challenge, as it is relatively easy to build beacons that interleave both message formats. Second is the DRM problem. Which is much more difficult to solve. Say United installs a network of beacons that guides United passengers to the gates using the United App. As passengers are guided to gates, the competitor's App picks the same Beacon signals and offers cheaper flights next time. This is certainly not what United would like to see. Which makes them scratching their heads whether they should be installing beacons in the first place. The second problem really comes down to the issue of how do we allow the legitimate app to receive beacon signals whi...