What’s Not Being Mentioned For Google Glass 2.0 Signals a Bigger Disconnect

Google is at it again, and you don’t have to look very hard to find press coverage on the “coming soon!” next edition of Google Glass. Here’s one to orient you in case you’re not caught up yet. Beyond “Enterprise Edition”, I’m also seeing it referred to as “For Work”, and even 2.0. Let’s see which one sticks… With the words “enterprise” and “for work” being associated with the new version, I’m here to tell you that trouble may be brewing for the WLAN industry, for clients, and for those who run wireless networks. I hope I’m wrong on this. But regardless, there’s a big fat stinky elephant in the room.

Let’s zoom in on some of what’s getting people all excited about New Glass. This screen scrape comes from the above-linked article:
Glass 2

That the new unit has dual-band support (2.4 GHz and 5 GHz) on Wi-Fi is indeed a step forward. But of the dozen of so articles I looked at on New Glass, I see no mention whatsoever that this model will support enterprise wireless security (based on 802.1X). The first one did not, which brings us to a number of points of concern:

  • The fact that “IT journalists” can look right past wireless security when they get all gushy about new devices is troubling. I’ve ready cheesy articles about Original Glass being a wonder tool in the operating room (kind of like the worshiper/journalist who declared Chromecast as being perfect for enterprise board rooms far and wide). Evidently if the product is COOL, wireless security is irrelevant to many writers.
  • The once-great Wi-Fi Alliance HAS been security-focused in the past. They came out with pre-802.11i security measures to plug holes in early 802.11 standards, and did wonders for the industry by advancing the message that WLAN very much can be as secure as wired networks if designed and implemented right. But somewhere the Alliance backed off, and became an advertising agency for it’s members rather than a steward of secure WLAN. Rather than beating the drum for clients that can work at home AND in the enterprise setting where many migrate to, the recent message is basically “wireless is good, buy more wireless.” Ugh. We need cheer-leading for SECURE wireless, not just wireless, now more than ever.
  • When Glass 2.0 hits, it will have a line of wannabe users stretching out the door, from all professions. It’ll spark as many “wouldn’t it be cool to use it like THIS…” ideas just as the original did. Users then didn’t care about WLAN security, and they won’t with 2.0 either. That should be Google’s responsibility- if the powerhouse company wants it used At Work, the device needs to be made to fit into Work Wireless. It can’t demand that we all change our business WLAN environments or build one MAC-bypass portal after another because WLAN security was left out. Where Enterprise WLAN admins can’t easily put one-offs on the WLAN (and original Glass was very much a one-off), users get pissed off. This many years into the wireless thing, the industry ought to be past the fragmented state of client device capabilities.
  •  Those of us in the business of secure wireless are trained that security counts (read CWNP’s Certified Wireless Security Professional course materials for reference). One common mantra is “if clients can’t do enterprise security, replace them with ones that can”. But we’re getting barraged with clients that can’t do enterprise security anymore. One side of the industry is not talking to the other, and the current dichotomy is not sustainable.
  • If there is a delineation between “consumer” and “enterprise” anymore from the client device perspective, it’s getting harder to find. Whether it’s the Amazon Echo, Google Glass, Apple TV, Chromecast, wireless weather stations, or printers and projectors, devices used at home 100% will find their way to work. In the current fragmented client space, we frequently have to violate our own policies to dumb down network security to accommodate the devices that were built on the lazy/cheap. Again, this is unsustainable.

Back to the new Google Glass. I don’t know that it won’t support enterprise security. But I really don’t expect it to. If that’s how Google plays it, well then shame on them. But one fact prevails- you can’t have low-security devices on high-importance networks and not have eventual breaches as a result. I’d love to see Google draw a line in the sand here, and say “Glass 2.0 is 802.1X capable!” and then play that up big-time to educate the masses on why that’s important.

And, I want a pony.

 

4 thoughts on “What’s Not Being Mentioned For Google Glass 2.0 Signals a Bigger Disconnect

  1. Jussi Kiviniemi (@JussiKiviniemi)

    Great write-up, thank you! Totally would’ve missed Glass 2 if it wasn’t for your blog.

    I agree 100% that support for 802.1X is very, very important for enterprise Wi-Fi.

    AFAIK, the downside of supporting 802.1X on small-sized mobile devices with little room for battery is that .1X hurts the precious battery life a lot. This might be one of the reasons it’s being left out from a lot of mobile devices – laziness perhaps being the other 😉

    Getting .1x truly battery life friendly – now there’s something for the standards bodies to scratch their heads over.

    BTW, love the whole Glass for Work thing. This just might be an innovation that starts at the workplace and becomes consumer-ready years later. Kind of like the personal computer did.

    Reply
    1. wirednot Post author

      Thanks for reading, and the comments, Jussi. I respect the battery point as valid, but I can’t feel good about pushing a product that puts battery life over security into production WLAN environments (if that’s what ends up happening). Should be interesting!

      Reply
  2. Frank Sweetser

    I think you’re 100% dead on, but also that you don’t quite go far enough. More specifically, I would say that while proper 1X support is absolutely essential, it’s not sufficient – we also need to have good on-boarding support. My own personal vision for “good” in this case would be a client/server network based API.

    On the server side, it should be able to generate an on-demand configuration file for the client – something rather like the MacOS mobileconfig format. It should include everything the client needs to connect, including crypto settings, and any required certificates. It should also support call-backs to an IPAM system for capturing device and owner information there.

    On the client side, it should require that all OS’s take the same configuration file. The responsibility for deciding how the UI should look and behave should fall completely on the client, as it will know better than the server what idioms work best on it’s particular platform.

    Basically, it would end up looking an awful lot like Cloudpath or Aruba Clearpass Onboard, but with consistent client behavior on all current *and future* devices, and without vendors having to dump tons of resources into continually tracking the quirks, eccentricities, and outright bugs of the entire field of required clients. Maybe then adding 1X support on the client side will be doable enough that every wireless glasses, watch, and toothbrush will support it.

    Reply

Tell me what YOU think.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s