Clearing out the old noggin

Time to write stuff down that clogs up my head; Hardware, Software, Twitter, Apple, Google and random stuff.

[justtimw]

Why don’t podcast have more personalized advertising?

Just catching up with the latest mini-series of the wonderful Startup podcast (find it here) and as I’m listening we arrive at the expected advertising break. I’m fine with this and prefer these NPR-style advertising slots to other forms. But it struck me, as it always does at this point, that the advertising is not well targeted. Because a podcast is,essentially a radio show, the ads you hear are the same for everyone; they’re neither personalized nor current. There seems to be a mismatch between the value of the content and the value of the ad-space within it. Ideally that ad-space should be sold for the current listener at the moment they’re listening; making it both personal and up-to-date. For now this cannot happen due to the limitations in the podcasting infrastructure; it still thinks it’s playing radio shows. But in the future? I assume something will come along and make this better ... unless it already did?

[justtimw]

#MFi and #HomeKit

Amazon dropped off my Elgato Eve door sensor on Friday. I don’t really need a door sensor, at least not to sense the door, but I did want a Bluetooth HomeKit device to take apart. This one is the cheapest I could find.

The device itself is unsurprising: a Bluetooth CPU/Radio combo, reset switch, magnetic sensor, led, power management, and the MFi chip. The MFi chip has been the subject of some speculation for HomeKit, and its supposed late addition to the spec the reason for product delays. But from what I can see (and based on its part number), this chip is just the same Apple’s MFi chip found in iPhone cables and adaptors. It’s not HomeKit specific. It certainly isn’t responsible the securing the communication between the device and iPhone; it just does what MFi chips always do; secure the relationship between the manufacturer and Apple.

For more information on these chips, DuckDuckGo is your friend; just search for “ipod authentication coprocessor 2.0c”.

[justtimw]

Peak Twitter?

Twitter’s quarter was horribly expected. Yes they made money; they even claim a profile if you ignore some pesky expenses. But growth has stopped, daily users are down, and the forecast is worse to come (translated Noto-speak). Have we reached peak Twitter?

[justtimw]

Open Source, #HomeKit and Forbes

There’s been a couple more write-ups on the Forbes piece on HomeKit (see here and here). In the general scheme of things it doesn’t really matter, but it strikes me that if Apple were a little more open with their specs there would be less room for these claims which are basically wrong. Alternatively, how about open sourcing a reference implementation? The value here is in the products, not the technology.

[justtimw]

Forbes and HomeKit

Very odd piece by Forbes on delays to Bluetooth HomeKit devices. You can read it here. Having spent rather too much time on this recently, I can safely say that the numbers quoted are ridiculously wrong on almost every point. Odd.

[justtimw]

Single Family WLTM Home Automator for LTR

Hi - we’ve tried Craigslist and we’ve tried OKAutomator, so this is really our last attempt to find a match. We know you must be out there somewhere, but so far no luck. 

I mean, the automators we’ve met always seem nice at first. They promising us the world - they’ll bring magic into our lives by turning on the outside lights at dusk when we come home - but after a while it’s always the same; they’re just not into all of us, they just want that special one. But we’re a happy group as we are - we just want to add one extra. I know people might think it’s strange, but in today’s world, is that really so much to ask? 

Sure, they say they like us all, but then when they’re off with their “favorite”, the others are left high and dry and nothing works. Often the heating insists we’re not even here! Or sometimes, when they come home, everything acts like it’s the lord of the manor returning. I’m sorry - but we’re a package deal - treat us all equally or sling your hook.

Look, there are plenty of single people out there, looking for the Automator of their dreams, so maybe you’ll have a simpler time with them. But we’re a family of four, and just wanting to hang out with one of us isn’t helping anyone. Maybe you think you can get away with caring about only one of us; but if you want to be here you need to work with everyone, not just your favorite.

So ... last ditch attempt ... calling all Automators who want to come stay with us. You need to remember there’s more than one of us living here, that we all have our different lives and routines, and that everyone wants you to play well with everyone else. If you can’t handle that, then you’re not for us. In fact, who are you really for?

[justtimw]

Thread

I missed this, but looks like the Thread Group published it’s Zigbee alternative. Find more information here.

[justtimw]

Single points of failure

I’ve been spending a lot of time with Apple’s HomeKit recently (resulting in this Open Source Bluetooth HomeKit implementation) and it’s becoming obvious that it’s a very centralized system. In iOS9 you can virtual wire a switch to a light; when you push the switch the light goes on ... but the command to make this happen travels though your iPhone. Which begs the question - what happens if your iPhone is off? Does the light not come on? That seems ridiculous, yet nothing I’ve read so far suggests otherwise.

There are a few options here. One is that this code also runs on iCloud; but quite how that is suppose to happen is unclear. This virtual wiring is code on your iPhone and not some configuration file akin to IFTTT. And even if it were, it’s not great to have your light fail because Comcast happens to be down again.

A second option is that the code is running on your AppleTV box. Much has been made of Apple TVs ability to bridge you HomeKit network to your iPhone when you’re not at home. Perhaps a new Apple TV will do more and also run your HomeKit code? Somehow?

So I prefer the third option ... that it simply won’t work. There are no APIs that suggest it will work and no platforms it can obviously run on. I don’t think we should imagine there’s a cunning plan to fix this; at least not before iOS10.

[justtimw]

HomeKit Incompatible

Remember that slide from WWDC’14 showing which devices would work with HomeKit? It turns out, nothing you could buy at the time could ever work. This came as a bit of a disappointment as I survey my Philips Hue bulbs, Netatmo weather station, Withings scale and Kwikset door lock.

Out of curiosity I though I’d go through the list again to see if these companies have any products you can buy (today or very shortly) that are compatible:

iDevices: They website lists a switch, but you cannot buy it nor do they say when you will be able to.

iHome: They also list a switch, also with no release date.

OSRAM: No products listed.

TI: No products listed.

Cree: No products listed.

Chamberlain: No products listed.

Marvell: Lists a few chipsets, including one used by the unreleased iHome product.

Skybell: No products listed.

August: No products listed.

Honeywell: No products listed.

Haier: No products listed.

Schlage: The Scalage Sense is listed, but unreleased.

Philips: No products are available, but Philips have promised support for Hue in the fall. How this will be achieved has not been specified but given the MFi requirements, it will probably involve buying new hardware.

Kwikset: No products listed.

Boardcom: They announced the first certified HomeKit chipsets.

Netatmo: No products listed.

Withings: No products listed.

So there you are. Of the partners displayed at WWDC’14, not a single one sold a consumer product at the time which could become HomeKit compatible, and none of them currently sell a product which is. Maybe disappointing isn’t a strong enough word.

[justtimw]

Worldly wisdom teaches that it is better for reputation to fail conventionally than to succeed unconventionally

John Maynard Keynes

Apply to your favorite technology company. 

[justtimw]

Twitter’s Dick Move

July 1st was Dick’s last day as CEO of Twitter. I’ve always liked Dick. He was one of those CEO who made the employees feel important. When Twitter was still under 1000 people he knew the name of every one of us. This was quite disconcerting when he’d greet you by name in the corridor; making you feel that perhaps you’d just done something very wrong. I also learn to only talk to him when he’s standing up. When he’s standing up he’s in a good mood. When he’s sat down he’s in a bad mood. If he’s slumped in a chair, run away immediately because whatever you have to say can most definitely wait.

That said, it’s been clear that Twitter needed a new CEO for a long time; the IPO just brought better scrutiny to the problem. Internally Twitter has always been short term focused and after Dick replaced his entire management team, this didn’t change. Dick set the tone. After the IPO there was an internal joke that Twitter had a shorter attention span than Wall Street. I wish that was only funny.

Now there are three schools of thought on Twitter’s future. In one, the company is sold to Google or Facebook or, god forbid, Yahoo. That takes the pressure off the quarterly numbers, but doesn’t necessarily fix anything since that was always a symptom. Presumably, the acquirer would disband the current management team and that would probably help. Alternatively they bring in a new guy. My money would be on Mike McCue via a Flipboard acquisition. I’m not entirely sure why Twitter’s board is enamored by Flipboard (not a product I associate with continued success) but it is and always has been. But perhaps Mike and his team can fix Twitter. Finally there’s Jack, but you probably want someone who puts Twitter first even while he’s interim-CEO.

The real worry has to be - why now? There’s no transition plan, Twitter is in trouble, and the current CEO is part time with other priorities. One does wonder what the next quarterly numbers are going to be; difficult to imagine Dick went out the door on July 1st because there were good.

[justtimw]

HomeKit and HealthKit

Another week in the Land of Things, and we finally see some HomeKit products launched. With WWDC next week, some other pieces will probably fall into place. Unfortunately this isn't going to make my home any less fragmented because it’s clear that Apple’s requirements exclude many Things already in my home. I’m sure they, just like others, justify this because it makes everything simple for the consumers; unless the consumer bought or buys the “wrong” thing, in which case it just makes it impossible. Why HomeKit isn’t more like HealthKit I don’t know.

[justtimw]

The cut of the cloth

Finally had chance to catch up on the 8 minute Google I/O segment on Weave. It’s a bit premature and there’s not much detail. I like the idea of using JSON schemes and events to define devices; but then my own Sense project does exactly that, and I’ve written about the need for this before (see this old post). As much as I like the principle, it won’t solve any problems if no ones uses it. Google, Apple and Samsung agreeing is probably out of the question.

From a technical perspective, I’m particularly interested in how their schemas will work. My own experience is that many things look like switches, and many things can be switched; make things too specific and it’s harder to link everything together. For example, is opening a garage door “switching it on” and closing it “switching it off”? If it is, then linking and on/off event from a wall switch to the garage door is trivial. But if the door is operated by an “open” or “close” event then it just got a little harder to connect because wall switches don’t send those. For now, we’ll have to wait and see.

I suppose it’s called Weave because they have a communications protocol called Threads. At some point they’ll beat the metaphor to death and invent something called Cloth.

[justtimw]

Securing the Bluetooth Mesh

BLEMP, my Bluetooth Mesh Network, needs to be secure. As a proof of concept, there’s little harm in it being open. If I want to use it serious, and have others use it, it needs a better security story than “hope”. Thankfully, Bluetooth has its own set of security protocols. Over the years various security vulnerabilities have been found, and each iteration of the spec has attempted to fix them. A few interesting papers on this are here, here and here. 

Simplistic security overview

From the literature we can conclude that once a connection is established, information is exchanged securely. However, vulnerabilites exist in setting up such a connection. This setup using a shared secret; usually a 6-digit pin code, or sometimes just pushing a pairing button (effectively the pin code 000000). Obviously a brute force attack on such a trivial secret takes no time, but requires the attacker to captures this initiation process. That may be unlikely, especially as devices have to be put into “pairing” mode to allow this to happen. This mitigates attempts to hack devices without physical access. Once setup is completed, each Bluetooth device holds a common 128-bit key which is used as the basis for all future communications. For all practical purposes, this key cannot be cracked.

BLEMP poses a number of additional problems in its attempt to use the security mechanisms already present in Bluetooth. First, it may have hundreds of nodes which may speak to dozens of neighboring nodes. Second, these neighbors will change over time. And third, we want authorized external parties (i.e. Phones) to be able to talk to any part of the Mesh. Bluetooth’s security is designed to secure a single point-to-point connection and not a mesh. How might we do this?

Out-of-band pairing

Fortunately, bluetooth has an additional pin code mechanism for pairing. Rather than restrict the pin code to a six digits, a 128-bit key may be used. Such a value, generate randomly, is large enough to make the pairing process unhackable, and is referred to as out-of-band pairing (OOB). If each node in the mesh knows this secret, it will be able to pair with any other node in the network, at any time, and securely communicate.

There remains the issue of how each node is given this shared secret, but I’ll leave key management for another post. In the prototype the value is simply defined in the code.

Long Term Keys

The OOB key lets nodes in the network securely communicate. However, no common client devices (e.g. iOS or Android) support out-of-band pairing - even if they knew the out-of-band key, they would be unable to access the network. Instead we have to use 6-digit pin code pairing, understand that it has limitations, and attempt to mitigate them. But pin code pairing only works for a single phone-to-node connection; if we wanted to talk to a different node (as we might in a mesh network) we would have to pair with that node as well. For hundreds of node this would be impractical.

When pairing with a device, Bluetooth has the option to “bond” with it. This establishes a 128-bit long-term key (LTK), shared between the phone and node, which can be used later for secure communication without pairing again (forcing the user to re-enter a pin code). If this key is known by all the nodes in the network, then in theory, any device which knows the key will be able to security communicate with any node. Essentially the LTK acts like the OOB secret but for phone-to-node security.

The LTK is not predefined, but is generate and stored on the node during the pairing process. Once generated then, we must securely distribute it to all the other nodes in the network. Fortunately, we have already secure the mesh using the OOB key, so we can use the mesh to do this.

Now we must persuade the phone to select the correct LTK when talking to a mesh node. Normally the phone selects the appropriate LTK based on the address of the mesh node. To force it to select the same key we would have to force every mesh node have the same address. This is obviously unworkable. Fortunately Bluetooth contains one final security trick we can use; the Resolvable Private Address.

Resolvable Private Addresses and Identity Resolving Keys

To make Bluetooth devices difficult to track, each device may change its address as often as it likes. Because of this, addresses are no longer the identity of the devices therefore Bluetooth defines a new identity; the Identity Resolving Key (IRK). This key is also exchanged during bonding. When a device reconnects to a node, it uses the resolvable device address and the IRK to select the LTK to use to encrypt communications; and the same LTK is always used with the same IRK.

So, practically speaking, the same LTK will be used to communicate with any device which has the same IRK, regardless of the address of the device. If all the mesh nodes have the same IRK, but different resolvable private addresses, they will appear as individually addressable nodes, but any phone which is bonded with one will have bonded with all. The IRK does not have to be secret (knowing the IRK without the associated LTK does not grant access) and is currently defined in the code.

Summary

By defining two 128-bit values, the OOB and the IRK, we can construct a Bluetooth mesh network which is internally and externally secure. All this is done using standard Bluetooth mechanisms. The next step is key management; how to securely associated these keys with a new mesh node.

[justtimw]

One day you sober up and you’re Yahoo

Go and read this by Chris Sacca. It’s quite long ... that’s fine ... I’ll wait.

http://lowercasecapital.com/2015/06/03/what-twitter-can-be-2/

Now a few comments:

Twitter has failed to tell its story: I worked at Twitter for three years (I left a while ago) and that’s as true now as it was then. If it still can’t tell a story, you have to wonder why.

Pinning blame is unproductive: We live in a culture where there’s always someone to blame, usually someone else. I would agree that exerting all energy on blame isn’t productive, but if people fail again and again I think you’re abnegating your own responsibility if you don’t, eventually, hold them accountable.

Shipping innovation: Innovation is easier to ship when you’re revenue and user growth are rocketing. When neither is happening you’ll find management being very conservative. Shipping anything which might effect the next quarters numbers becomes impossible. This mentality led me to spend the last year at Twitter working in emerging markets (by far the best thing I ever did) because there I found a space with massive upside, almost no downside, and so no one worried that I’d hurt growth. If I helped it, well great. This flip side was that no one cared; people only cared about you hurting growth which should tell you a lot.

Bold vision for the future: If you admit that Twitter can’t tell a story, then it certainly can’t present a vision for the future; or not one that’ll last until the next quarter.

Buying Periscope: I’m sorry, but that acquisition not risky; it was obvious and maybe essential. If you spent anytime on Twitter during the Ferguson protests last year, you should understand what a missing piece Periscope is. If Twitter is to remain the go-to place for things happening right now, they had no choice.

Twitter can afford to build the wrong thing: Yes it can, but not in the Twitter app and, last I checked, that’s all they had (no, not Vine). If you want to understand why not, then see Shipping Innovation above. I’d like to see Twitter shipping multiple apps as places for innovation. The fiddly, tweaky, experiments done today isn’t going to move any needles.

Recent Tweets/Best Tweets: The problem here is that you bump into the VITs. VITs - Very Important Tweeters - are the superusers of Twitter. Unlike Facebook which, at its core, is a peer network of family and friends, Twitter is broadcast medium from the VITs to the average user. Best Tweets puts more VIT tweets in front of more users and that’s good for them. But it also effects the “Democracy of Tweets” giving undue weight to VITs tweets over average users. That means even less tweets by users are seen. So while you might show users better content, you make it more likely they’ll have a bad experience if they interact with it. And a bad experience makes them go spend time elsewhere.

Live: I forget how many Live/Event like products Twitter has built over the years. I was involved in a couple what actually launched, and I’ve lost track of the number that didn’t. I’m fairly sure Live was the future of Twitter; at least it was that quarter. But Live is really hard. Curating enough quality content isn’t early. Filtering poor content isn’t simple. Allowing the audience to interact with it in a meaningful way isn’t obvious. How to find unschedule events (e.g. natural disasters) is unclear. Licensing restrictions on some live events make them impractical. I’ve seen an experiment for exactly the Live product described, and the fact that you’re not seeing it today should tell you something about how hard it is to make that succeed. Which doesn’t mean if can’t be done; only that the investment and risk shouldn't be underestimated.

Channels: There are a couple of attempts at this that I know of. The new logged-out web has a Channel like front page offering a selection of categories you can dig into. A similar new user experiment was tried in India on Android devices; again to show what Twitter could offer. But at this point in Twitter life, this is putting the cart before the horse. Twitter brand recognition around the world is phenomenal. The problem with that is people think they know what Twitter is, and have already formed their opinion: they like it or they don’t. What Twitter actually is doesn’t matter as much. All new features in Twitter have to deal with the bias of what non-users think Twitter is, and what old users expect Twitter to be. New features don’t help either group.

Separate Apps: If you want separate apps in Twitter you’re going to have to take it up with the Boss. But even though I would love Twitter to have many apps, what you really need is for Twitter to embrace the third party eco system again. If you want to see innovation on Twitter content, you’re going to need to look for entrepreneurs who want to build something amazing rather than those worrying about their next performance review and promotion. Unfortunately no developer will trust Twitter again. Twitter has a terrible record of screwing its third party developers; no third party clients, limited API access, no firehose licensing; user number restrictions, strict tweet formatting rules, etc. Building a business on someone else’s content is always risky, but to do it on Twitter’s is just committing suicide. It didn’t have to be that way.

Nudges et al.: This has been proposed many times before, but it’s unclear how bugging someone to Tweet will make Twitter better if those Tweets aren’t seen and aren’t engaged with. Tweeting can seem hard, but it get’s harder and demoralizing if nothing happens when you do it.

Favorites, Hearts and Acknowledgements: I would argue that Twitter already has too many forms of actions (Favorite, Retweet and Reply) and that adding more is going to make things more confusing instead of better. Everyone observes that they get little interaction on Twitter compared to the same content on Facebook, but I’ve yet to see anyone prove a hypothesis about why this is. Maybe it’s the culture of the platform, or maybe the different networks of people who use it? And while it’s good to get feedback for your actions, impersonal, canned feedback (e.g. a thank you form letter tweet) probably won’t help.

More Periscope: It’s a pity they sold to Twitter. Periscope, or something like it, could easy be the next Facebook. I think products based around realtime, mobile streaming, are going to be very interesting in the next few years (I will definitely use Meerkat the next time I see the police hassling someone downtown). If Periscope had raised a ton of money and gone big without Twitter ... well ... the acquisition might have been in reverse in a few years time. Now it’s inside Twitter - good luck!

In summary; reading Chris’s piece was interesting but there’s nothing really new, which is a pity. Many of his ideas have been proposed and some tried. There are lots of reason why the product doesn’t have them; even if not all those reasons are good. Many of the choices Twitter made years ago were all about going public. I’m glad they achieved that. But the consequence of those choices have long term implications from which it is now suffers. It’s like making more money by cluttering the home page with ads - great for a few quarters, but one day you sober up and you’re Yahoo rather than Google.

[justtimw]

Bluetooth Mesh and Security

Currently head down in the world of Bluetooth security. Like most people who use Bluetooth, I know that when you pair two devices, there’s this shared 6 digit pin you enter, and then the devices are securely connected forever; and that’s about all I knew when I started into this. Lots to learn.

This current research is driven by the need to secure access in BLEMP, my Bluetooth Mesh protocol. There are a couple of ways to look at security for something like this; we’ll call them the REST way and the WS-MUMBLE way. 

REST is simple protocol running over HTTP which lets apps interact with web services. It secures itself by riding on top of SSL (HTTPS) which already existed on the Web. WS-MUMBLE, a hopefully long forgotten set of complex standards, is transport agnostic, assuming any sort of connection, so built its own security models.

REST won the web services war. It was simple to understand and built on things that already existed. I like that approach and am planning to go the REST route - build my Mesh security using the mechanisms already available in Bluetooth. Fingers crossed.

[justtimw]

Home Disaggregating

About a year ago I disconnected the light switch which controls the porch light, from the actual porch light. Now, rather than using wires, these two things connect using software. When I did this, one of my first discoveries was that my wife is an amazing tolerant person. After all, there is now only the vaguest relationship between what the switch does and what the light does. Together they were great, but apart there is a distinct Garfunkelness about it all.

Over the year things have improved, although there was a marked decrease in reliability when the Amazon Echo was recently thrown into the mix. While it’s cute to ask Alexa to turn on the outside lights, it totally confused everything else which wasn’t expecting some new persona to come barging in changing stuff.  At this point my humble porch light can be operated from Alexa, from a phone, from a Raspberry Pi (running my home brew automation software), or ... if you must ... a switch by the door. If Apple ever gets its shit together with HomeKit I will throw that in too.

The other thing this experiment has shown me is that we are about to enter a world of “Home Disaggregation” where we separate the switches from what they control. Right now that light switch on your wall is probably connected, using wire, to the light above your head. In the future, that won’t be the case. There will still be a light, and there will still be a switch, but their connection will be described by software, not the hardware running through the walls. This goes for everything else in you home, be it the furnace, garage door, hot water heater, yard sprinkler, security camera, door lock, electric outlet, ceiling fan, and all those wall switches that use to connect to things.

And while the easy option is to use software to wire everything back together again, the interesting things will happen when we work out what the software should be doing instead.