Cisco and the Internet of Everything

John Chambers, CEO of Cisco, just published a good blog entry about the potential for change caused by universal connectivity, not just of our mobile gadgets, but of pretty much everything. Much has been made of late of the so-called “Internet of Things (IoT)”, to which Cisco is upping the scope and going so far as to make a bold estimate that 99.4% of objects still remain unconnected. This of course is great fodder for late night talk show hosts. I’ll leave this softball to them, and focus instead on some of the more interesting points in Chamber’s post and the accompanying white paper.

It strikes me that there might be more to Cisco’s Internet of Everything (#I0E) neologism than just a vendor’s attempt to brand what still may be a technology maverick. Internet of Everything sounds so much better than the common alternative when you append Economy on the end, and this is how it first appears in Chamber’s post. And that’s actually important, because adding economy in the same breath is an acknowledgement that this isn’t just marketing opportunism as much as a recognition that like mobility, the IoE is a potentially great catalyst for independent innovation. In fact, Cisco’s paper really isn’t about technology at all, but instead an analysis of market potential represented in each emerging sector, from smart factories to college education.

It is exactly this potential for innovation—a new economy—that is exciting. The combination of Mobile+APIs was so explosive precisely because it combined a technology with enormous creative potential (APIs) with a irresistible business impetus (access to information outside the enterprise network). The geeks love enabling tools, and APIs are nothing if not enabling; mobile just gives them something to build.

I0E of course is the ultimate business driver—and leveraging APIs as the enabler, it equals opportunity of staggering proportion. Like mobile before it—and indeed, social web integration before this—IoE will come about precisely because the foundation of APIs already exists.

It is here where I disagree with some IoT pundits who advocate specialized protocols to optimize performance. No thank you; it isn’t 1990 and opaque binary protocols no longer work for us except when streaming of large data sets (I’m looking at you, video).

Security in the IoE will be a huge issue, and on this topic Cisco has this to say:

IoE security will be addressed through network-powered technology: devices connecting to the network will take advantage of the inherent security that the network provides (rather than trying to ensure security at the device level).

I agree with this, because security coding is still just too hard and too easy to implement wrong. One of the key lessons of mobile development is that we need to make it easy for developers to enable secure communications automatically. Take security out of the hands of developers, put it in the hands of dedicated security professionals, and trust me, the developers will thank you.

As IoE extends to increasingly resource-constrained devices, the simpler we can make secure development, the better. Let application developers focus on creating great apps, and a new economy will follow.

CES 2013 Panel: Privacy and Security in the Cloud

The Consumer Electronics Show (CES) 2013 is starting next week and cloud computing is on the agenda. You can be sure that a technology has moved out of the hype cycle and into everyday use when it shows up at a show like CES, known more for the latest TVs and phones than computing infrastructure. People don’t really need to talk about cloud any more; it’s just there, and we are using it.

Of course there will always be a place for a little more talk, and I’ll be doing some of this myself as part of the CES panel “Privacy and Security in the Cloud”. This discussion takes place Monday Jan 7 11:00am-12:00, in LVCC, North Hall N259. The panel is chaired by my good friend Jeremy Geelan, founder of Cloud Computing Expo, who honed his considerable moderation skills at the BBC.

I’m planning on exploring the intersection between the cloud and our increasingly ubiquitous consumer devices. We will highlight the opportunities created by this technological convergence, but we will also consider the implications this has for our personal privacy.

I hope you can join us.

Do You Agree To The Terms and Conditions? Mobile Devices And The Tipping Point of Informed Consent.

handshakeSometimes I wonder if anyone, in the entire history of computing, has every bothered to read and consider the contents of a typical End User License Agreement (EULA). Some Product Manager, I suppose (though truthfully, I’m not even sure of this one).

The EULA, however, is important. It’s the foundation of an important consent ceremony that ends with only one effective choice: pressing OK. This much-maligned step in every software installation is the only real binding between an end user and a provider of software. Out of this agreement emerges a contract between these two parties, and it is this contact that serves as a legal framework for interpretation should any issues arise in the relationship.

Therein lies the rub, as the emphasis in a EULA—as in so much of contract law—is on legal formalism at the expense of end user understanding. These priorities are not necessarily mutually exclusive, but as any lawyer will tell you, it’s a lot more work to make them co-exist on more of less equal footing.

Mobile devices, however, may provide the forcing function that brings change into this otherwise moribund corner of the software industry. Mobility is hot right now, and its demanding that we rethink process and technology all over business. These new demands are going to extend to the traditional EULA, and the result could be good for everyone.

Case in point: the New York Times reported recently on a study conducted by the FTC examining privacy in mobile apps for children. The researchers found that parents were not being adequately informed about what private information was being collected and the extent to which it could be shared. Furthermore, many mobile app developers are channeling data into just a few commercial analytics vendors. While this may not sound like too big a deal, it turns out that in some cases these data are tagged with unique device identifiers. This means that providers can potentially track behavior across multiple apps, giving them unprecedented visibility into the online habits of our children.

Kid and privacy are a lightening rod for controversy, but the study really speaks to a much greater problem in the mobile app industry. Just the previous week, the State of California launched a suit against Delta Airlines alleging the company failed to include a privacy policy in its mobile app, placing it in violation of that state’s 2004 privacy law.

You could argue that there is nothing new about this problem. Desktop applications have the same capacity for collecting information and so pose similar threats to our privacy. The difference is mostly the devil we know. After years of reading about the appalling threats to our privacy on the Internet, we have come to expect these shenanigans and approach the conventional web guarded and wary. Or we don’t care (see Facebook).

But the phone, well the phone is just… different.  A desktop—or even our mobile laptop—just isn’t as ubiquitous a part of our lives as our phone. The phone goes with us everywhere, which makes it both a triumph of technology and a tremendous potential threat to our privacy.

The problem with the phone is that it is the consumer device that isn’t. Apple crossed a chasm with the iPhone, taking the mobile device from constrained (like a blender) to extensible (like a Lego set) without breaking the consumer-orientation of the device. This was a real tour de force—but one with repercussions both good and bad.

The good stuff we live every day—we get to carefully curate our apps to make the phone our own. I can’t imagine traveling without my phone in my pocket. The bad part is we haven’t necessarily recognized the privacy implications of our own actions. Nobody expects to be betrayed by their constant companion, but it is this constant companion that poses the greatest threat to our security.

The good news is that the very characteristics that make mobile so popular also promise to bring much needed transparency to the user/app/provider relationship. Consumer-orientation plus small form factor equal a revolution in privacy and security.

Mobile devices tap into a market so vast it dwarfs the one addressed by the humble PC. And this is the group for which consumer protection laws were designed. And as we’ve seen in the Delta Airlines case above, the state’s have a lever, and apparently they aren’t afraid to use it.

But legislation is only part of the answer to reconcile the dueling priorities of privacy and consent. The other element working in favour of change is size, and small is definitely better here. The multi-page contract just isn’t going to play well on the 4″ screen. What consumer’s need is a message that is simple, clear, and understandable. Fortunately, we can look to the web for inspiration on how to do this right.

One of the reasons I get excited about the rise of OAuth is because it represents much more than yet another security token (God knows we have enough of those already). OAuth is really about granting consent. It doesn’t try to say anything about the nature of that consent; but it does put in the framework to make consent practical.

Coincident with the rise of OAuth on the Web is a movement to make the terms of consent more transparent. This needs to continue as the process moves to the restricted form factor of the mobile phone. I have no doubt that left to their own devices, most developers would take the easy route out and reduce mobile consent to a hyperlink pointing to pages of boilerplate legalese and an OK button. But add in some regulatory expectations of reasonable disclosure, and I can see a better future of clear and simple agreements that flourish first on mobile devices, but extend to all software.

Here at Layer 7 we are deeply interested in technologies like OAuth, and the role these play in a changing computer landscape. We are also spending lots of time working on mobile, because more than anything mobile solutions are driving uptake around APIs. When we built our mobile application gateway, we made sure this solution made OAuth simple to deploy, and simple to customize. This way, important steps like consent ceremonies can be made clear, unambiguous, and most important, compliant with the law.

(ISC)2 Webinar – Identity is the New Perimeter: Identity and BYOD

Join me and Tyson Whitten from CA Technologies as we deliver a webinar about security in the BYOD world. The title of our talk is Identity and BYOD, and we are honored to be presenting as part of the International Information Systems Security Certification Consortium (ISC)² security series.

This webinar will take place on Oct 25, 2012 at 1pm ET/10am PT. We will delve deeply into the issues created by the Bring Your Own Device (BYOD) movement in the enterprise, and discuss what you can do to manage the associated risk.

You can sign up on the (ISC)² website.

The iPad Mini is for Cars

Yesterday, Apple launched the iPad mini. Apple events in the fall of 2012 may no longer command the social anticipation of only a few years ago, but they remain flash points for technology reporting. This release brought on more than its share of speculation that the mini is simply an overdue acknowledgement that Amazon got something right with Kindle, and that Apple has quietly slipped into following mode. Some pundits have seized on the angle that Apple’s new tablet appeared to contradict Job’s famous trashing of the 7″ form factor. But in all of the hullabaloo one observation seems to be missing. That is, a tablet of this size is tailor-made for inclusion into the dashboard of your car.

Nothing dates a car like its electronics. And nothing is more tragic that the UX of pretty much every single in-car navigation and music system. The luxury car segment can do Corinthian leather and wood grain appointments like no industry on earth. They can build a magnificent driving machine that powers through rain and snow like it was a sunny day in LA. But ask them to do a screen-based app and you get something that looks like it was designed on a TRS-80.

I didn’t renew the trial SiriusXM in my 4Runner because I couldn’t stand its programming compared with what I could stream from my iPhone using Bluetooth. Every time I rent a car I use my phone-based Navigon app over any provided GPS because my app is just better. I’m hooked on Waze despite how few people use it up here in Vancouver (you should sign up—the more people who use it, the better the traffic data is). The apps on my phone are always up-to-date and I replace the hardware every couple of years for the latest model (which is good enough for me; after all, it’s only a phone).

All cars need is a standard, lockable frame where you can plug in the device of your choice, plus a standardized connector. Then let free market competition and innovation prevail over Apps. Tomorrow’s gear heads aren’t going to be like the hot rodders of my Dad’s generation or the tuner kids of a decade ago. They are going to be geeks with Apps using APIs.

That’s what the iPad mini is for.

(It’s interesting to note that the wifi-only mini has no GPS, but the cellular version does…)

Why I Still Like OAuth

That sound of a door slamming last week was Eran Hammer storming out of the OAuth standardization process, declaring once and for all that the technology was dead, and that he would no longer be a part of it. Tantrums and controversy make great social media copy, so it didn’t take long before everyone seemed to be talking about this one. In some quarters, you’d hardly know the London Olympics had begun.

So what are we to really make of all this? Is OAuth dead, or at least on the road to Hell as Eran now famously put it? Certainly my inbox is full of emails from people asking me if they should stop building their security architecture around such a tainted specification.

I think Tim Bray, who has vast experience with the relative ups and downs of technology standardization, offered the best answer in his own blog:

It’s done. Stick a fork in it. Ship the RFCs.

Which is to say sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy; but it’s needed, and it’s needed now, so let’s all forget the personality politics and just get it done. And hopefully right across the street from me here in Vancouver, where the IETF is holding it’s meetings all this week, this is what will happen.

In the end, OAuth is something we all need, and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.

In the past we’ve been shackled by the centralization of control around identity and entitlements (a fancy term which really just describes the set of actions your identity is allowed, such as writing to a particular file system). This has led to a status quo in nearly every organization that is maintained first because it is hard to do otherwise, but also because this equals power, which is something that is rarely surrender without a fight.

The problem is that centralized identity admin can never effectively scale, at least from an administrative perspective. With OAuth, we can finally scale authentication and authorization by leveraging the user population itself, and this is the one thing that stands a chance to shatter the monopoly on central Identity and Access Management (IAM). OAuth undermined the castle, and the real noise we are hearing isn’t infighting on the spec but the enterprise walls falling down.

Here is the important insight of OAuth 2.0: delegated authorization also solves that basic security sessioning problem of all apps running over stateless protocols like HTTP. Think about this for a minute. The basic web architecture provides for complete authentication on every transaction. This is dumb, so we have come up with all sorts of security context tracking mechanisms, using cookies, proprietary tokens, etc. The problem with many of these is that they don’t constrain entitlements at all; a cookie is as good as a password, because really it just linearly maps back to an original act of authentication.

OAuth formalizes this process but adds in the idea of constraint with informed user consent. And this, ladies and gentlemen, is why OAuth matters. In OAuth you exchange a password (or other primary security token) for a time-bound access token with a limited set of capabilities to which you have explicitly agreed. In other words, the token expires fast and is good for one thing only. So you can pass it off to something else (like Twitter) and reduce your risk profile, or—and this is the key insight of OAuth 2.0—you can just use it yourself as a better security session tracker.

The problem with OAuth 2.0 is it’s surprisingly hard to get to this simple idea from the explosion of protocol in OAuth 1.0a. Both specs too quickly reduce to an exercise in swim lane diagram detail which ironically run counter to the current movement around simple and accessible that drives the modern web. And therein lies the rub. OAuth is more a victim of poor marketing than bad specsman-ship. I have yet to see a good, simple explanation of why, followed by how. (I don’t think OAuth 1.0 was well served by the valet key analogy, which distracts from too many important insights.) As it stands today, OAuth 2.0 makes Kerberos specs seem like grade school primer material.

It doesn’t have to be this way. OAuth is actually deceptively simple; it is the mechanics that remain potentially complex (particularly those of the classic 1.0a, three-legged scenario). But the same can be said of SSL/TLS, which we all use daily with few problems. What OAuth needs are a set of dead simple (but nonetheless solid) libraries on the client side, and equally simple and scalable support on the server. This is a tractable problem and it is coming. It also needs much better interpretation so that people can understand it fast.

Personally, I agree in part with Eran Hammer’s wish buried in the conclusion of his blog entry:

I’m hoping someone will take 2.0 and produce a 10 page profile that’s useful for the vast majority of web providers, ignoring the enterprise.

OAuth absolutely does need simple profiling for interop. But don’t ignore the enterprise. The enterprise really needs the profile too, because the enterprise badly needs OAuth.

Hey Twitter: API Management = Developer Management

Quick question for you: What matters most, the client or the server?

Answer: Neither—they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame, and a server without a client is simply unrealized potential. Bring them together though, and you have something of lasting value. So neither matters more, and in fact each matters a lot less than half.

In the API world, this is an easy point to miss. The server-side always wields disproportionate power by virtue of controlling the API to its services, and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something which is genuinely exciting), can be found a restatement of an early warning to developers:

“developers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage it’s own API. Stifling competition by leveraging your the API power card can only alienate developers—and by extension the public who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green in Programmable Web. Green acknowledges that API change is inevitable, but points out that this is something that can be managed effectively—which is not what Twitter is doing right now.

The irony of the whole thing is that in the past, by exercising its power position Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API management isn’t technical but social. Win the community over and they will move mountains. Piss them off, and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy—and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Simplicity and low barrier to entry counts for everything because it means you can get on with building real apps.

Now I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community—well, that is where the real work begins, and in the end, it is all a lot less deterministic than we technologists like to admit. People are hard to manage, but communities are even harder.

If there is a lesson here, it is that APIs are really about potential, and that potential can be only realized when you have two sides—client and server—fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.