Google Glass 2: Allow us to turn it off

As I mentioned in my post yesterday regarding the potential "evil" implications of "rooted" or "jailbroken" Glass headsets in the wild, there will almost certainly be licensed implementations of the device's basic reference design, which will be improved upon by OEMs.

This would be akin to the reference designs for Android smartphones created by Google, which companies like Samsung, HTC, and LG use to make their own licensed products today.

Executives at Google have indicated that Glass will ship to consumers sometime in 2014. Presumably, this is to debug aspects of the system and make improvements so that the market doesn't end up with a half-baked product with a limited application ecosystem at launch, like the first T-Mobile G1 Android handset did back in October 2008.

There are many ways in which an initial Glass consumer product can be improved over the existing "Explorer" edition that is now shipping to developers and first adopters. For starters, there's the issue of battery life.

Currently, according to most reviews of the product published to date, the device only has about a five-hour battery life, and this is reduced to about 20 minutes of total recording time under battery power if the front-facing camera is used for 720p video capture.

Unlike smartphones and tablets, which can use as much as 80 percent of their surface area for battery compartments, Glass faces a number of challenges, essentially because it's a smartphone without a screen, with virtually no surface area to speak of.

The right side of the device holds a small casing that contains the SoC (system on a chip) as well as the 640x360 prism-mounted color display, the forward-facing 5MP CMOS sensor, the microphone, the bone conduction audio system, flash storage, and the support electronics for wireless networking and Bluetooth.

And oh, yes, the battery. All of which has to be packed into an extremely tight area.

So clearly, for Glass to evolve as a usable system, the art of miniaturization has to go a bit beyond what we expect from smartphones. The battery chemistry may need to be more exotic (and thus, probably more expensive) than what exists currently in smartphones, and the SoC design has to be lower power than anything that has been used on a smartphone to date.

Currently, Glass is able to do many tasks autonomously, provided that it has a wi-fi or Bluetooth connection to the internet. Because the SoC used now is of the "complex" and general-purpose variety that is similar to what is used in a smartphone, has a lot of onboard memory (like a smartphone), and runs a fully programmable OS (like a smartphone), it also consumes battery power in large amounts ... like a smartphone.

An alternative approach would be to make the next generation of Glass "dumb", essentially a thin client for the purposes of presenting application telemetry data from a remotely connected smartphone.

With a "dumb" Glass, one could use a very low-power "microcontroller" or ASIC (Application Specific Integrated Circuit) of a custom design that is optimized specifically to do the tasks that Glass needs to do, and thus would consume far less battery power.

Glass 2.0 should have a JeOS, possibly even a hardened, non-Linux kernel, with only a minimal amount of memory onboard, so that the tethered smartphone and the cloud it needs to talk to via wi-fi or Bluetooth is in fact doing the heavy lifting in terms of storage and compute.

Should Google choose to continue to use Android as the base OS for Glass, I would make it a design objective to use a secure boot and image validation technology, such has been developed by General Dynamics for its "GD Protected" suite, which includes numerous other security enhancements that should be considered not only for Glass, but for all Android smartphones.

By making Glass "dumb", there would be other advantages besides battery life. As I noted in my previous piece, Glass currently has no security controls that would prevent it from being hijacked and the data on it stolen.

Android and iOS embedded systems expert Jay Freeman, aka "Saurik", who recently published an account of how to root compromise a Glass device, suggested that Google implement a pin code procedure or a voiceprint to unlock the unit when it is not being used.

"Antiglass" would be a signal or trigger that disrupts the lifelogging capabilities of augmented reality devices. It's the Glass kill switch.

But I would go even further with this. Because of the large amounts of onboard storage, there's a lot of data that could be forensically retrieved from the unit, and since Glass currently runs on a sophisticated SoC on Linux rather than a simple microcontroller running on a rudimentary OS, the potential for compromise is significant even if a voiceprint or pin code is used to unlock the system.

In an ideal world, Glass would simply be a Bluetooth headset on steroids. It would only need a small cache to interact with its host smartphone for the card apps to function, and it would make sense to wipe the cache and disconnect from the network tether every time it is removed from the wearer's head.

There's another feature that I think, beyond everything else I've talked about, is paramount in order to get this technology accepted into the mainstream, and that is "Antiglass".

I talked a little about Antiglass in an earlier piece, about how social norms may need to change once Glass becomes popular.

In short, "Antiglass" would be a signal or trigger that disrupts the lifelogging capabilities of augmented reality devices. It's the Glass kill switch.

How this would actually get implemented might be tricky, but I've given some additional thought to this one.

I suspect that this might be possible through the use of RFID ARAT (Active Reader Active Tag) transmitters and tagging, provided that the ARAT tags were hard wired to the camera, and audio pickup electronics in Glass and were not accessible directly via the OS.

There would be many advantages to using this approach. First, it's a fairly "keep it simple, stupid" (KISS) solution, and RFID tagging is a mature and highly proven technology.

And at manufacturing scale, it should be fairly inexpensive for businesses and private individuals to install these Antiglass RFID transmitters in their buildings and homes.

Personal RFID ARAT transmitters could be incorporated into smartphones for those people who want to disrupt Glass and other lifelogging devices for a short distance (10'-100') and could be marketed as a value-added feature of new handsets.

Prosumer units intended for protecting small and medium-sized businesses with higher ranges (100'-200') may only cost a few hundred dollars to bring to market. Medium-range versions (200'-500') could be sold to organizations with larger areas to disrupt, whereas wide-cast, 2,000' versions could be used by federal, state, and local governments to "De-Glass" large public areas.

I feel strongly enough about the potential for Glass to be abused in the future that at bare minimum, an Antiglass initiative should be on the forefront of proposed telecommunications legislation in this country, requiring lifelogging augmented-reality device manufacturers such as Google to use this technology before the genie of personal lifelogging devices is let out of the bottle.

Do we need "Antiglass" technology as part of all lifelogging and augmented reality systems? Talk back and let me know.