Thursday, December 2, 2010

Motorola Buys 4Home...a Sign of Things to Come in #SmartGrid?

Yesterday, Motorola announced that they're acquiring 4Home, one of the industry's leading software solutions for the connected home. In addition to being really good guys, the 4Home team has done a great job building out a very cool platform for a number of home applications, including energy management.

At first pass, I said "A cell phone company is acquiring a team that does set-top and embedded device work? What the heck?" Then I quickly remembered that Motorola bought GI about a jillion years ago. I still can't get used to saying "Motorola" when talking about GI, nor do I readily say "Cisco" when I actually mean "Scientific Atlanta". Then again, Motorola's lost enough brand equity in cell phones that I've regressed to thinking of them as a military radio purveyor, but hey.

Anyway...

I love this deal. While I'm skeptical based on Motorola's stock performance the last three years as to whether this was a good deal for 4Home (although in this market, any exit is a good exit), this could be the lever that really gets Smart Grid platforms rolling, particularly for those operators under the CableLabs umbrella. Motorola/GI and Cisco/SA have at least a hundred million set-top boxes installed in the U.S. alone...which could be one helluva Trojan horse. If Motorola can demonstrate to their operator customers that they've integrated a lightweight software platform from 4Home, you could see a very rapid ramp-up of managed service provider offerings for energy management and home security & automation.

Why? Well, the math is pretty compelling for a third party service provider (let's say Comcast) to offer me a home energy management system (HEMS) based on a set-top box which is already in my home. If I take that set-top box and bridge it into my home network (either via my cable modem or via a built-in comms port like MoCA or Ethernet), I can now readily view and control the energy consumption of the devices in my home, all via my TV or a smart phone application--with no new hardware cost for me as a customer, or for my service provider. Simply by downloading new software onto my existing set-top, I'd end up with a form of consumer Energy Services Interface (ESI), functioning as the heart of my HEMS.

Would it be perfect? Unlikely. My Comcast EPG sucks, and the fact that my dual-tuner box can't do picture-in-picture in 2010 is mind-boggling (particularly since my UltimateTV box designed in 1997 did so, with a fantastic UI to boot), but I'll take the good with the bad. Frankly, it's also likely that a significant number of those hundreds of millions of set-top boxes would be resource-constrained, unable to run the 4Home software stack, no matter how light that software load might be.

Regardless, the pay-TV and telecommunications markets have talked about convergence for many years. Yesterday, one of the world's biggest players in the set-top box space took a significant step towards hastening convergence between consumers, communication, control, and energy.

Your move, Cisco.

Wednesday, December 1, 2010

Is Your Thermostat Watching You? Device Fingerprinting Enters the Mainstream

(This post originally appeared on the ThinkSmartGrid blog)

Interesting article in this morning's Wall Street Journal on the topic of device fingerprinting, a discipline the NIST Smart Grid Cyber Security Privacy Team has spent quite a bit of time discussing. In a nutshell, an Australian company called BlueCava has developed technology to provide a unique digital fingerprint of individual cell phones, computers, and set-top boxes.

What's cool about this from a targeted marketing standpoint is that advertisers can now further increase the granularity of their ads, resulting in a dramatic increase in CPMs beyond what cookie-based technologies can provide. If I'm an advertiser, I'm stoked about the fact that now I can in effect unicast my ads, rather than broadcasting to the masses or multicasting to an imperfectly granular demographic.

Of course, if I'm not an advertiser, this scares me to no end. I'm not exactly a privacy zealot, but I will say that I'm concerned about privacy--and I'm not the only one. The Federal Trade Commission and the Department of Commerce are both working on reports on data privacy and behavioral tracking; the FTC's report might even be out this week. The big challenge is, what kind of teeth will these reports actually have? Recommendations are great, but without an enforcement mechanism, any kind of do-not-track tools are going to be left up to software & services providers, and to users themselves. I can certainly see a case where users are encouraged to download do-not-track tools from websites set up solely to embed tracking mechanisms in their do-not track tools.

Crazy? Not so much--we've seen this exact type of behavior from supposed free virus checkers and spyware removal tools. So, don't be surprised if the FTC makes recommendations which enable users to potentially better protect their personally identifiable information (PII), but that nothing substantive actually happens to make it compulsory for software and service providers to enable such protection.

Why are we talking about this here?

Well, device fingerprinting isn't only for consumer electronics devices--white goods, HVAC, and plug load components are all capable of being fingerprinted, too. While this discipline is newer than fingerprinting consumer goods, startups and established firms are racing to enable their energy management systems (EMS) to automagically discover devices to enable easier management. I'm aware of at least one company which has taken unique fingerprints on tens of thousands of unique devices in the home--washers, dryers, dishwashers, lamps, fans, and more. The whole point is to enable an energy management system to automagically discover and display devices in the EMS.

Why? Whoever makes the EMS easiest to use has a great shot at winning the home energy management war, a war worth many billions of dollars worldwide. Part of making the home EMS (HEMS) easy is to perform automatic discovery of as many devices as possible. Protocols like UPnP, Bonjour, and SNMP have performed these tasks in the information technology world for years. However, no such analog exists (yet) in the energy management world.

Think about how great it would be to go to your local big box store, buy a home energy management system (likely consisting of an energy services interface, which you can consider generically to look like your home router today; one or more intelligent power strips; and perhaps an in-home display, although the iPad and smart phones have pretty much put the IHD camp out to pasture), bring it home and plug it in, and have the system discover all the devices in your home which draw power.

The nuance here is that the IT-focused protocols I mentioned earlier use network protocols to perform discovery; in the HEMS case, discovery is performed over the powerline network (with wireless protocols serving as an adjunct), using either network protocols or the actual power signature of the device.

What's that, you say? The power signature of the device?

Yep.

A Whirlpool washing machine will put out a different power signature than will a Samsung washing machine. In fact, different models of washing machines from the same vendor will usually have unique power signatures. If the HEMS is able to perform this non-invasive load monitoring, then compare its results against a known database of device signatures, the end result is a rich visualization of the electrically-connected devices in the home. The better view of and the more intelligence about the connected devices, the more control the consumer gains over analysis and power use--and ultimately, better control over monthly bills.

Like all things in life, there are tradeoffs, potentially privacy-impacting. Lacking a sufficient privacy policy, a HEMS device could feasibly collect the information about the devices in your home, then add that to the digital fingerprint created by the BlueCava folks, providing an even richer view of everything that goes on in your home. Some folks will say that's crazy.

It's not.

The reason it's not is that the HEMS is unlikely to have a database of every washer, dryer, and box fan in the world; instead, the system will be smart enough to perform the non-invasive load monitoring (the listening part), send the signature (likely to be in the form of a hash, digitally representing the analog signal) to the HEMS back-end database sitting in the cloud, then receive the device-specific information (including a pretty icon!) for use in the HEMS graphical display.

Sound crazy? Then you probably haven't used Shazam to identify a song.

I don't know what Shazam's privacy policy looks like (which is a fail on my part, I guess), but the odds are pretty good that even for free users, the Shazam folks know what my listening habits are based on the five free tags I get every month, although they're unlikely to be able to do much with that data without some form of PII. If I'm a registered, paying user, obviously they know exactly what my listening habits are, and could very well correlate that with an online music vendor to serve me very specific ads based on the type of music I listen to.

That's not all bad. In fact, that type of correlation can sometimes work out really well. If you use Pandora, you're well aware of the Music Genome project, and the benefits you derive as a Pandora listener. In exchange for the occasional in-stream advertisement, and for ads served in the Pandora player while each song plays, I get to listen to music based on the types of tunes I've identified that I like.

Thumbs up for that one.

The spot where the hammer hits the thumb in the energy management space is when utilities and third party service providers don't establish well-defined, easy-to-understand privacy policies concerning the use of ALL energy data, including dynamically discovered information. Your washing machine isn't going to opt into a query, so when the HEMS performs its discovery, it does so with a modicum of responsibility, whether the HEMS is reporting to a utility, service provider, or vendor.

Used responsibly, that data could be extremely beneficial--if your Brand A dishwasher is about to fail, its internal diagnostics systems could alert you, as well as Brand A's service department, in the nick of time before you end up with a huge puddle of water on the kitchen floor. Used irresponsibly, the HEMS could intercept that diagnostics failure-pending command and auction it to the highest bidder, in a form very similar to how Google AdWords works today. Would it be worth fifteen or twenty bucks for Brand B to know that my Brand A dishwasher is about to go kablammo? Absolutely, just as Big Box Store A and Big Box Store B would love that data, either to earn my business, or maintain my brand loyalty.

The net-net here is that just because you're not paranoid, doesn't mean they're not out to get you. In these early days of the Smart Grid, utilities, vendors, and third party service providers all must work diligently to build consumer trust, to ensure users that they're working with them, rather than against them. Just as it's taken years for telecom and pay-TV vendors to learn how to interact with customers (and not all of them have, obviously), so too will it take time for utilities to adapt their behavior. The traditional terms ratepayers or load points no longer have a place in a utility's vernacular. We've launched ThinkSmartGrid to help utilities and their suppliers develop and deliver on all aspects of the Smart Grid, with a particular focus on the consumer value proposition. While you'll see announcements from us over the coming weeks and months about our relationships with leaders in multiple sectors like automated demand response (OpenADR) and visualization, we'll never lose sight of the consumer, and the need to include that consumer in the conversation.

Speaking of conversation, we want to include you, too, so please feel free to comment on our posts. The ThinkSmartGrid team brings a unique perspective to the market. While we may not always have the right perspective in your eyes, we look forward to opening and maintaining dialog with you.

For now, I need to move out of my thermostat's line of sight...just in case I'm being watched.

Tuesday, September 28, 2010

Friday, September 24, 2010

Thursday, September 9, 2010

Samsung's Epic Fail, Part II

Lots of comments, calls, e-mail, and questions the past couple of days on my review of the Epic 4G. A number of reviews I've seen make me believe that most reviewers aren't using the phone as their sole mobile device; that, or I simply have a piece of totally crap hardware.

Before going to the virtual mailbag, let's take a look at the last couple of days' use...

Yesterday, the Epic made it five hours before dying. Usage was pretty basic--a solid half-hour of e-mail and web surfing on the train, a bit of note-taking during an hour-long meeting, another solid half-hour of e-mail and web surfing on the train, about 10 minutes of phone calls, then more random e-mail and web surfing until the unit died five hours from unplugging. Note that none of the bonus radios were on--4G, Wi-Fi, Bluetooth, and GPS were all off. Five hours of relatively light use like that on my BlackBerry Curve would've probably cost me about 20% of my battery.

Of course, yesterday was a dream compared to today. Yesterday was like living in a corridor. Today was more like living in a paper bag in a septic tank.

I undocked the Epic at 6:45 a.m.; after an 80-minute bus/L commute where I did nothing but e-mail and web surfing, I was down to 55% of battery. Seriously. An hour-twenty, and I'd gone through nearly half my battery. As was the case yesterday, this was as battery-saving a commute as one could possibly hope for--4G, Wi-Fi, Bluetooth, and GPS all turned off. I can say good things about Sprint's 3G coverage and speeds here in Chicago; as I noted in my initial review, there's a ton of other stuff I'd like to test, but the range anxiety makes doing so a tenuous proposition.

From 8:05 till about 8:25, I used the phone for a couple of e-mails, but it was in my pocket the rest of the time. At 8:25, I sat down with a couple of buddies, and we started talking about the phone. I showed them all the stuff I like about it (screen, OS responsiveness, apps, keyboard), while kvetching about the battery life, and all the wackiness about apps firing off in the background. At 8:35, I was down to 45% battery. Remember that number.

In an attempt to show my friends how apps initiated themselves with no rhyme, reason, or intervention whatsoever, I offered to turn off the phone, then power it back on. I've done this a number of times in hopes of getting some kind of handle on what's going on with the OS and the apps, so I expected to lose another percentage point or two of battery life in the power down/power up process.

At which point I moved into the paper bag in the septic tank.

15%. Fifteen percent. Fifteen freakin' percent of battery left after that reboot.

Seriously.

At this point, I was somewhere between incredulous and pissed.

Incredulous because, well, stuff like this just doesn't happen; while I'm not an engineer by degree, I do play one on TV, so my logical mind just can't process something like this. Pissed because, I can't understand how any reasonable kind of QA process from two top-notch companies like Samsung and Sprint could've let something like this out into the wild.

I wasn't near a power outlet, so I plugged into my Mac via the USB port to grab some juice at about 8:45. The MacBook isn't exactly its own utility substation, but I did manage to get enough juice to get back to 65% by 11:30 when my MacBook battery gave up. Thank God for my iPad.

Yesterday, five hours. Today, I might've made it two-and-a-half if I'd continued to use the phone. Brutal.

One comment from the mailbag mentioned that turning on the 4G radio for even two minutes can make for a 10% hit on the battery. Yep. Brutal. The same commenter mentioned that the mobile hotspot functionality is a two-hour feature on just about any phone. Agreed. Equally brutal.

Listen up Samsung, HTC, and whoever else is building 4G phones for Sprint, as well as Verizon, AT&T, and whoever will be building y'all's LTE phones...

Don't cram in features that people want just because the marketing research says it's a good idea. The Epic 4G has a killer feature set--but the only thing being killed right now is Samsung's reputation, either for initial build quality and QA, or for overall design (i.e., if they can't fix this with a hardware exchange or a new firmware/software download). The software has definite usability issues, some of which I mentioned in the initial review, some of which I'll get to shortly. But, shipping a phone that can only last a few hours when users merely use the features for which they've chosen to purchase this phone--the most expensive phone in the Sprint stable? Unacceptable, both from a customer satisfaction standpoint and from a corporate branding and reputation standpoint.

As I mentioned in the first review, my hope is that I just have a piece of bad hardware, a bad battery, and/or a bad software load. I haven't been able to get back to Sprint to pick up a new device, but am planning to do so over the weekend. But, if after going to a replacement device, the experience is no different, I'll only be able to conclude that Samsung and Sprint are going to end up with a whole lot of phones in landfills. Samsung's made an unbelievable move into the mobile device market over the last decade; they'd survive a black eye like this, but it sure wouldn't feel good.

Speaking of not feeling good, over the past couple of days three Evo owners shared their experiences with me, none of which I'd classify as being high quality experiences. My former colleague Keith Mahoney left an in-depth comment on the original post, concurring with my experience, and also believing that Android has some kind of weirdness going on with unwanted phantom app firing destroying battery life. As Keith noted, the HTC HD2 has the same screen as the Evo, so Sprint's blaming the size of the screen being a power-hungry beast doesn't fly--the HD2 runs Windows Mobile, and doesn't have battery life issues according to Keith.

Wait a sec...did I just throw a compliment to Windows Mobile? Where's my thermometer?

Keith also mentioned that Sprint suggested putting the Evo into standby mode when not in use; Matt Burns also mentioned that he's taken to putting the Evo into airplane mode to extend battery life. Realistically, all any of us want as customers is for our devices to offer some semblance of the value proposition upon which we based our purchasing decision.

If I wanted to own a phone where I had to turn off the radios to use it, I'd buy an iPod Touch, for God's sake.

One final point that Keith makes bears investigation--not all devices running Android are having this issue, so some combination of Sprint and Android is turning devices into power-hungry beasts. I'm not hearing battery life complaints about either Droid, so Android and CDMA seem to be getting along just fine on Verizon's network. And, the Epic's battery life is abysmal even with no radios on save for the regular 3G radio, so something funky is going on that can't be blamed on the 4G radio.

Ray Trygstad weighed in with his answer to the Evo's battery life problems--he pulled a spare battery out of his pocket. I'm willing to go that route, but a single spare battery isn't going to cut it for the Epic--I'd need a pocket full of kryptonite to reach what seems like the 4500-6000 milliamp hours I'd need to get through a day of regular-to-heavy use on the Epic.

I can't say this enough--I hope I just have a lemon. I hope I just have a lemon. I hope I just have a lemon.

Before wrapping things up for tonight, here's two more "features" for you to consider. In the initial review, I mentioned that the voice-activated Google Search doesn't work with Bluetooth--pretty stupid, since when I'm driving, I'd prefer to not have to deactivate Bluetooth (or pick up the phone and hold it next to my mouth) just to use voice-activate search. Well, I've identified at least one other case where the guys working on the Bluetooth stack missed the team meetings with the OS guys--voice mail. The Epic has a very cool voice mail app where you can see and act accordingly on each individual voice message--but God forbid you want to check voice mail while using Bluetooth.

You see, the voice mail app doesn't seem to understand that Bluetooth exists.

Seriously.

Want to check voice mail while your Bluetooth earpiece is in your ear? Hold the phone to your other ear.

One other UI issue that's continually bugging me is when I want to go to a contact in portrait mode. In landscape mode with the hard keyboard slid open, I can simply start typing the contact's name, and the contact manager quickly narrows down who I'm looking for. But, in portrait mode, there's no option to pop up the soft keyboard, meaning you have to touch the alphabet letter of your contact, then scroll down (or up, if you choose to go +1 on the letter and work backwards) to find your contact. If I'm on a train or a bus, or sitting in a meeting, it's no biggie to pop the hard keyboard. But, if I'm driving and need to look something up (and spare me the lecture on distracted driving...assume I'm at a red light), having to kick the device open is a total pain--not nearly as bad as the inability to dial from the calendar, but you get my gist.

So, a week in, and I still haven't come close to approximating a typical day's use on my old school BlackBerry Curve. Agreed, I'm cranking through a lot more web content, since the browser on BB OS 4.5 was all but unusable, but the range anxiety associated with the Epic makes me shy away from doing all the stuff one might want to do on a mobile device.

Like phone calls and e-mails, for instance.

I hope I just have a lemon, I hope I just have a lemon, I hope I just have a lemon...

Tuesday, September 7, 2010

Samsung's Epic Fail--the Samsung DOH!

(Let me preface this post by noting the possibility that I may have bad hardware, a bad battery, and/or a bad software load. I've checked for new software each day this week (to no avail), and continue to be hopeful that Samsung will have new software available in the coming days. That said, I'm extremely skeptical that the issues I'm having with battery life are solely software-related, so I'm also planning to return this hardware for a different unit, in hopes that a newer manufacturing run might address the issues I'm seeing. Everything I say in this review is predicated on the fact that the unit I currently have performs as Samsung designed it--and if that's the case, the entire design is a lemon. If I have bad hardware, an exchange for new hardware should resolve the battery life and 4G issues I'm seeing, hopefully; further, I'm hopeful that any software-related and lack of functionality issues will also be fixable in relatively short order.)

I tend to start reviews by focusing on the positive, then later mixing in whatever negative thoughts I may have. This is the rare review where I simply can't do so. The Samsung Epic 4G is awesome, in all respects--awesome screen, awesome capabilities, and awesomely bad battery life.

Here's the most succinct way for me to describe this...if you're in the target demographic for the Samsung Epic 4G, you simply won't be able to survive life with this phone. That's one hell of a paradox, but that's how bad battery life is. I'm not normally at a loss for words (and I know that some of you wish I was more often), but I had to turn to a thesaurus to grab a sufficiently broad range of adjectives to describe the Epic 4G's battery life...
  • abominable
  • appalling
  • atrocious
  • deplorable
  • ghastly
  • horrendous
  • shocking
Let's step back a week. Before picking up my Epic 4G, I thought back to the first phone I owned with a full keyboard--the T-Mobile Sidekick, which I purchased in mid-2002. Despite its shortcomings, the Sidekick had two radically compelling capabilities going for it--the landscape design made for a fantastic typing experience, while the cloud-based architecture meant that all your mail, contacts, and calendar could be stored (or lost, as Microsoft learned last year) on the network, independent of the device itself.

Since my Sidekick, I've owned a Palm Treo 650, a BlackBerry 8700 and 8320 (Curve), and now the Epic 4G. If you know me, you know that I tend to be a bleeding edge, first day guy on some technologies, like the new Apple TV (already on order) or the Jawbone II. However, over the years I've been a slow follower from a mobile device standpoint; with my mobile as my lifeline to the world, I've tended to be a bit conservative in making technology jumps. Plus, since I seem to write essays on my mobile, I've been unwilling to give up a hardware keyboard. For all the cool things that an iPhone 4 can do, there's two features it doesn't offer that I desired on my next phone--a hard keyboard and mobile hotspot capability. The Samsung Epic 4G offers both; combined with Android as an operating system, I've been eagerly awaiting the Epic's arrival.

So, aside from the battery (whose awesome brutalness I'll expound on more shortly), how is it?

First, a look at what's typically in my bag at any given time, at least as of last week...
  • T-Mobile BlackBerry Curve 8320
  • Jawbone II
  • 13" MacBook
  • 64 GB iPad 3G
  • Verizon MiFi
  • Clear 4G USB stick
  • A ridiculous array of cables to power and connect all of the above; look for me on wirelessmyass.com one of these days
In trying to simplify my world, I want to get down to just the Mac (and would buy a new MacBook Air the moment it came out if Apple were to ever introduce a new version, for crying out loud), the iPad, a Bluetooth earpiece which charges using micro-USB (rather than a proprietary connector), and a phone. Is the Epic 4G my answer?

As of now, no freakin' way, based solely on battery life. Sadly, there's a bunch of features that I can't even sufficiently test, as the battery's that bad--if I don't test at the beginning of the day, the phone's out of juice long before I get around to my typical late-night testing regimen; of course, the phone's already been plugged in for hours by that time, but hey. At least the Epic charges fairly quickly.

I'm less than a week in, but I'm already having the range anxiety typically associated with owning a plug-in electric vehicle. In fact, that'd be a recipe for an epic disaster--plugging an Epic into a Nissan Leaf would grind the car to a halt faster than driving it over a spike strip. At least now I know what it's like to own a plug-in electric vehicle without actually having to take the plunge.

What's to like about the Epic? A lot. What's to not like about the Epic? Not a ton, but of the stuff to dislike, the battery's such a dealbreaker that I've taken my eye off the ball on the other negatives.

The interwebs are full of out of box experience recaps of the Epic, so let's skip to what's important...

Keyboard: Really good, bordering on excellent. After more than six years on a portrait-shaped device, moving back to a landscape device is taking a little getting used to; and, while the device doesn't yet feel as comfortable as my Sidekick did, it feels good. On a scale of one to 10, I'll give it an eight, with possibility of a higher grade as I gain more comfort over time (assuming the Epic survives the 30-day money back guarantee, which it won't as of right now due to the battery issues). Love the cursor keys, too.

Screen: Awesome, except in outdoor light. Responsive, well-registered, and crisp. Unlike many reviewers, I don't find the Epic's AMOLED screen to be overly saturated to my eyes--but I'm also a guy that used to shoot Fuji Velvia 50, so yeah, I love contrast. Outdoors, the screen is challenging; in bright sunlight, it's worthless. I'm not sure how to state that more eloquently, but the best advice for trying to use the Epic in the sun is, don't. Go find some shade. I give it a nine for almost all uses, a three outdoors on a typical Beijing day, and a generous one on a San Diego summer day. Let's call it a seven, unless you live in a cave (with a 20 amp circuit, an Airvana femtocell, and a cable modem-attached Wi-Fi access point), in which case it's a nine.

Apps: While the Android Market is still well behind the iTunes app store in terms of number of applications, I'm pleasantly surprised at the depth and breadth of applications available on Android. In a side-by-side comparison with my iPad, I have quite a few apps which aren't available on Android. But, coming off of a BlackBerry, whose App World can most kindly be described as "crap", I'm not displeased with the currently available choices. Plus, in an open development environment and market like Android's, I expect that Android will continue to close the gap on Apple in terms of both quantity and quality of apps, particularly given the ability to sideload apps. I give it a six, with the expectation that over the next year, that grade will improve to an eight.

GPS: Solid, seemingly showing none of the flaws other Galaxy S GPS devices have shown at shipment. Both Sprint Navigation and Google Maps work extremely well. Turn-by-turn directions on Sprint Nav are a definite benefit. In 4G coverage areas, the GPS works great even when on a phone call; outside of 4G coverage areas, not so much. Seven.

Call quality: So far, so good, on handheld, speaker, and Bluetooth. Call completion is ridiculously quick; this is my first experience with Sprint as a carrier, and my first experience overall with CDMA for circuit-switched voice, so maybe this is a CDMA versus GSM benefit, but I'm pleasantly shocked at how quickly calls complete. Eight, maybe a nine.

4G: Sadly, not good at all. Over the last six months, my 4G stick has been pretty solid for me in much of the Chicago area. But, in places where I know I've had good Clear 4G reception with my USB stick, I'm getting zero 4G reception on the Epic--in many cases over the last week, when I've turned on the 4G radio, the status message has immediately informed me that 4G is disconnected. The Epic 4G without the 4G would be the Samsung Doh, as a 3G phone with lousy battery life would make me say little more than "DOH!" I intend to do some more testing over the next couple of weeks comparing the Epic 4G's reception with my USB stick's reception, as well as with my Verizon MiFi. While I understand design tradeoffs for packing antennas into mobile devices (something that Apple's learned a little bit about, too), my hunch is that the poor 4G reception is a firmware issue, not an antenna placement issue. Right now, I'll grade the 4G capability a two, until I'm able to do some more testing. Speaking of 4G and potential firmware/software issues...

Mobile Hotspot: Disappointing in two of the three cases where I've needed it; there've been other times when I've wanted it, but didn't want to take the battery hit (again, a range issue which is simply unacceptable). I still haven't been able to test the mobile hotspot with 4G coverage, owing to the coverage/reception issues I mention above. This demands much further testing. For now, I'll grade mobile hotspot as a three, based on the fact that the one time I've been able to successfully use the feature (albeit over 3G), the battery drained so quickly that the device was dead before I accomplished much.

Android OS: Wow, am I conflicted here. Seriously, there's a ton to like about the OS on this hardware. In particular, Google Apps users will LOVE the instant synchronization of contacts and calendars. The device is extremely responsive, the OS boots quickly, and all in all, I find the performance and usability of the OS to generally be quite good. But, note I said "generally". For now, I have to grade the OS as Incomplete, with a few items that are particularly mind-boggling...
  • On a calendar appointment, you can't click to dial a phone number. Seriously? Whiskey Tango Foxtrot? For a conference call I had earlier today, I had to dial in six times before I remembered the correct combination of phone number and passcode. This should be an A-1 priority fix for whoever's responsible for this calendar app, whether it's a Samsung app or an off-the-shelf Android app.
  • The built-in mail reader (not to be confused with the Gmail app, which is an external app with its own shortcomings, including the inability to view a combined inbox of multiple mail accounts) doesn't support push mail, at least that I've been able to determine. Worse, there doesn't seem to be a rhyme or reason to how the mail reader goes out and gets mail, if at all. In the combined view (which is great), you can see all your accounts in a single view. The key problem is, despite the fact that I have the reader set to pull e-mail in five minute intervals, I have to manually go out and refresh in order to receive new mail; worse, I can only do so from within each individual account, rather than from the combined inbox--meaning, if you have five mail accounts, you have to go to each inbox, then refresh within each. I can't possibly imagine that this would've been a design feature in a PRD--although I can't imagine that a ridiculously short battery life was a goal, either.
  • The Google Search box on the main screen takes a little getting used to, but is a reasonably beneficial way to access contacts, one which I could see myself getting used to with more use. However, there's a dealbreaker here--the fact that the voice-activated Google Search doesn't work with a Bluetooth headset attached. That's so entirely brain dead, it deserves its own bullet.
  • Voice-activated Google Search doesn't work with a Bluetooth headset attached. (See? I told you it deserved its own bullet). Let me paint a picture for you. You're driving and need to make a phone call. You tap the voice-activated Google Search icon, and say "Call Jimmy Carter". The device returns a "No speech heard" error, since for whatever cotton-pickin' (or peanut-pickin') reason, the inter-app communication between voice-activated Google Search and the Bluetooth stack doesn't seem to exist. I mean, I understand pressure to get products to market, but how the hell do you ship a device that almost requires a driver to cause an accident? Between the inability to dial from a calendar appointment and the requirement to either disable Bluetooth to search for a contact to call, or to spell out the contact's name on the virtual or physical keyboard, the Epic should come with both its own liability insurance policy and a stack of get-out-of-jail-free cards, which you'll need from continually messing around with the device while driving.
  • A number of other things are annoying--in addition to copy and paste functionality being limited, the main home screen doesn't rotate to landscape mode unless you slide open the physical keyboard, which is particularly annoying when you have the Epic in the battery dock--which you will, since you need to keep it plugged in every time you're near an outlet.
  • But, the single most annoying "feature" is apps firing off in the background with no rhyme nor reason whatsoever--which could be the single biggest battery-sucking issue on the entire device...
Since the introduction of the iPhone, we've all heard Steve Jobs loud and clear on the potential shortcomings of multitasking as a power drain on mobile devices. If the experience I've had over the last week is any indicator, he's 110% correct. But, let's not jump to conclusions. I can't possibly imagine that when Sprint and Samsung got together to write the MRD and PRD for the Epic, someone said "Hey, why don't we not only allow apps unlimited ability to initiate themselves in the background, but also allow them to trigger for no apparent reason? They don't even have to be apps that've ever been used."

Case in point--right now, after rebooting the phone, then killing all the running apps, the following apps have loaded themselves into memory within a couple of minutes...
  • Sprint Navigation
  • Sprint Hotspot
  • Messaging
  • Qik
  • Google Voice
  • Gmail
  • Voicemail
  • Voice Dialer
  • Gallery
  • Sprint Football Live
  • NASCAR
  • Sprint Zone
  • Email
  • Battery Monitor
  • Amazon MP3
Let's be crystal clear on something. This is not a case of the device launching my most frequently used applications. I've used Qik exactly once, to test it. Google Voice, I signed into the day I picked up my Epic. Sprint Zone is some kind of customer service dealio. The other Sprint apps also fired off on their own for no apparent reason. Yes, I've used each at various times, but haven't set them to auto-launch, ever. Amazon MP3 is an on-deck app that I can't get rid of, despite numerous attempts. If this damned thing loads on its own one more time, I swear I'm going to cancel my Amazon Prime membership. That, or start ordering anvils by the dozen, upgrading to overnight shipping for $3.99, then refusing delivery.

I'd heard that Advanced Task Killer was absolutely the most beneficial app I would download from the Android Market; to each of you (Ward, you were first) who told me that, thank you, thank you, thank you. Plus, ATK could almost serve as a pseudo-random number generator--every time I go into ATK, there's a different and unique combo of self-launched apps running in the background, spitting battery life onto the floor.

So, after a week, where are we?

With a bit of a crazy week heading into the Labor Day weekend, I didn't get a chance to use the device in anything approximating a normal day's use. Today, I did, and it ain't pretty.

4:15.

That's right--four hours and fifteen minutes from a full charge to flat-out flatlined. That's beyond brutal.

That sucks. And that's putting it kindly.

I mean, not only does that suck, but that makes me say there's no possible way that this could've been within the design envelope for this device, and that I absolutely must have some kind of a hardware problem.

Let's break this down a little. While I didn't have a pen and paper with me (which I regret, since that's the sole mechanism to successfully dial into a conference call from a calendar appointment), I have a pretty good idea of what my usage looked like.

(By the way, to those of you who might suggest that I need to be more diligent in turning off radios that aren't in active in use--I did. I read all the Evo reviews, so I know all about turning off radios to extend battery life. In this case, we're talking about trying to treat a punctured femoral artery with a piece of scotch tape and a slide rule.)

I pulled the Epic out of its desktop dock and immediately jumped onto a conference call--or tried to, as I had to dial in six times before I remembered/guessed the proper phone number and password combo; at this point, the Bluetooth and CDMA radios were the only two in use, with 4G, GPS, and Wi-Fi turned off. About five minutes in, I turned on the 4G radio and ran a speed test; 3.5 mb/s down and 500 kb/s up during a phone call is pretty awesome performance. A couple of minutes later, I turned on the GPS, and punched in the address of my destination, which was about 20 minutes from where I was at that point. Due to the spotty 4G reception, it took a while before I could actually get directions and maps, but once I had them, navigation was a cinch.

When my conference call ended after 67 minutes, I jumped on another call, but not before checking my battery life remaining. I was at 60% of battery left, after little more than an hour undocked from the cradle.

Epic!

I spent a little less than a half-hour on the second call, still with the GPS and 4G radios on so I could navigate to my next destination. Once I arrived there, I jumped on another call which took about 20-25 minutes; I turned off the GPS during that call, but left 4G on, as I wanted to be able to get e-mail while on the phone. I spent the next 45-50 minutes or so doing other stuff that allowed the Epic to drain battery on its own, rather than with my direct intervention. I then turned on the mobile hotspot, which connected over 3G (but not 4G). I had my iPad attached to the mobile hotspot for about 10 minutes--just long enough to do a couple of speed tests spaced out a few minutes apart. I then checked e-mail a few times, before the phone finally croaked at the four hour and fifteen minute mark.

Epic!

As I sit here shaking my head at the device's paucity of power, the only word that comes to mind is "incredulous". I just don't understand how a product, particularly one from a top-notch consumer electronics leader like Samsung, could come to market with such a woefully inadequate usage experience.

I mean, the Kin had a longer battery life than this.

Let's tie this up with a neat little bow. The Epic 4G is the first 4G phone with a slide-out keyboard, and has mobile hotspot capability, a gorgeous screen, a pretty darned good camera, and a whole bunch of other compellingly interesting features. Just don't try to use them all at once, for any period of time.

And that, my friends, may be the single biggest shortcoming of this entire experiment. Samsung has delivered a device that's world class in many aspects, but in the most important aspect--actual usage--the device is nearly worthless. Two hours of phone calls, a couple hours of the GPS and 4G radios turned on, and a bit of hotspot usage, and the Epic isn't.

Here's an analogy for you. Boeing is going to eventually ship the 787 one of these years. While the Dreamliner's testing hasn't quite gone according to plan, at least they're testing it. I have serious doubt that Samsung (or their contract manufacturer) did much real-world testing, at least to any level of depth. If the Epic was an airplane, its cruise height would be 7,000 feet, with a ceiling of 11,000 feet. Loading the airplane with actual passengers would lower cruise and ceiling by another couple thousand feet each; allowing those passengers to use any amenities (lavatories, air vents) would chop off another few hundred feet. Ultimately, the plane would only be allowed to fly mail stop routes, cruising at 4,000 feet, ensuring that when the engines flamed out the Epic could dead-stick its way to its next stop a few miles down the road.

I mentioned earlier the paradox that if you're in the crosshairs as a potential user of this phone, it's the wrong phone for you. As of right now, that's absolutely the case--Sprint's most expensive phone is laden with features, albeit ones you may not be able to use for any period of time if at all. If you can justify spending (after rebate) $250 on this phone, it's highly likely that you're a person who has a need for speed, for functionality, for business e-mail and calendar integration, and for ease of use. The Epic does some of those things well, some more than others. But, until I receive a unit with stable hardware (a category in which my current Epic doesn't qualify, as I gotta believe there's something wrong) and stable software (where my current Epic also doesn't qualify, as unattended app initiation is to me a showstopper bug), I can't recommend the phone to anyone, unless you have money to fritter away. If you do, buy a couple of spare batteries and a couple extra chargers, as you're going to need them.

In the meantime, I'm going to return my Epic to the Sprint store tomorrow and pick up a different one--one which I hope has come from a different manufacturing batch. I want to love this phone. I need to love this phone, purely from a capabilities standpoint. But the only way I'm gonna get some love from this phone is a decent user experience, which a ridiculously short battery life totally ruins. Right now, I feel a little like Charlie Brown in his relationship with the little red-haired girl.

Unrequited.

Thursday, September 2, 2010

Not Exactly The Onion: DLNA Responds to Apple TV

Moments after Steve Jobs announced the new Apple TV yesterday, I sent out a status update that said…

"Time to pre-order the new Apple TV. DLNA needs to worry, right freakin' now. And I'm a HUGE DLNA fan."

I made it nearly an entire minute before my phone rang; that call was shortly interrupted by another, followed by a slew of e-mails, tweets, and Facebook comments.

Pretty much everyone wanted to know, what the heck did I mean? The more I thought about it, the more I decided that the best response DLNA could make is in the form of a press release. So, here we go--the release *I* might write if I were in a position to do so…

DLNA Welcomes Apple to the Living Room


Congratulates Apple on Decision to Enable Content Enjoyment in a Social Setting


Portland, OR -- September 2, 2010 -- The Digital Living Network Alliance (DLNA) today welcomes the Apple ecosystem to the digital living room. By the end of September 2010, Apple users will be able to enjoy their photos, video, and music in a social setting, on the ideal display for social interaction--the television, rather than the small screen setting of iPhones, iPads, and iPods.


Steve, we know you've been busy, but what took you so long?


Since its founding in 2003, more than 7,500 products have been DLNA Certified®, giving consumers the interoperability they need within a full range of products including digital cameras, PCs and laptops, printers and televisions. Such a wide range of products means that by 2012, more than a billion DLNA devices will have shipped, according to ABI Research. Apple's recognition that consumers enjoy content in a twelve foot setting is an important milestone for our industry. The current two-foot user interface where Apple users typically consume content is ideal for touch screen devices, particularly when sharing photos of grandchildren with fellow airplane travelers, blaring music at inappropriate volume on trains, and nodding one's head at a visual voice mail message.

However, the explosion in social networking enabled by high-powered mobile platforms such as the iPhone has created the dichotomy that in a world of oversharing, the actual consumption of content has never been more solitary. When silver halide still played a part in preserving memories, doing so meant to capture, to share, and to enjoy--together. Unfortunately, as first-world economies have morphed into always-on, all-digital lifestyles, the actual act of enjoying shared memories in a social environment has gone the way of Jarts and the Oldsmobile.

Today, content is most often consumed by individuals on mobile devices; DLNA members Nokia, Samsung, LG, Motorola and Sony Ericsson shipped a combined 1.21 billion mobile phones worldwide in 2009, so we understand that mobile is a huge market for capture and consumption. But, one of the big challenges the entire consumer electronics industry continues to face is how to keep people truly connected in an ever-more-connected world, a world where a family of five can sit around a dinner table and avoid face-to-face conversation, courtesy of the very devices that our members ship in tremendous volumes.

We're certainly not against shared virtual enjoyment of content--Facebook has revolutionized the lives of technology users in a manner not seen since Google, and before that, well, Apple. But, there's more to life than photos that spend their lives locked up in a Facebook account, even if tens of millions of the cameras taking those photos are produced by our members. When we started DLNA in 2003, we believed that the right way to enable consumers to enjoy their content was in a connected environment; that's even more true today. Technologies like high-speed wireless, network-attached storage, and high-resolution HD video cameras one can shove in a pocket largely didn't exist seven years ago; if they did, they were the exclusive domain of the earliest of early adopters, at price points out of reach for all but the ultra-affluent, and at a technology integration cost only a geek could love.

We set out to change that, to get ahead of the technology curve, to standardize in a multi-vendor environment all the things that made this type of content sharing a five- or six-figure investment. In 2003, a number of us got together and chose to think different. What that's meant over the last seven years is a lot of heavy lifting, an enormous amount of time and investment, to ensure that consumers are able to connect and enjoy their content in a multi-vendor environment, one where content can be captured, stored, shipped, and consumed. Consumers buying DLNA Certified® devices can be confident they're purchasing solutions that work together and can be networked, regardless of manufacturer. That's why more than 200 companies have joined DLNA, and continue to collaborate to ensure that our products will work together to deliver content sharing which our users can enjoy.

That type of shared, truly shared, content enjoyment was challenging for Apple users until yesterday's announcement. As Apple mentioned, Apple TV has been little more than a hobby since its introduction in 2006. The new Apple TV offers a compelling value proposition, one which we're confident will motivate the entire industry to develop and deliver products which interoperate even better, at even lower cost, delivering even more value. Ultimately, in doing so, we all stand to benefit, particularly as we get people back in front of the big screen, together. Maybe, just maybe, the new Apple TV will promote a few more families to gather around the television to enjoy a shared content experience together, to set aside their iPhones, iPods, and iPads for a few minutes or a few hours. Whether viewing a high budget movie from a major studio delivered over a high-speed Internet link, or simply enjoying family photos served off of a personal computer in the home, we think there's real benefit for those families and friends gathering to connect and enjoy; that's the motivation for all of us to keep at it, to keep delivering products our customers want, at a range of price points, in a truly multi-vendor environment.

We've learned a lot about the art and science of content sharing over the last seven years. One of the most important things we've learned is that this race is a marathon, not a sprint. We'd like to take this opportunity to welcome Apple to the race.

See you on the couch.

I'll clarify a few more of my thoughts over the coming days, and try to answer a number of questions that've already come in from some of you. The point is, Apple's entry to the market is a huge challenge to DLNA, a challenge to move beyond the vernacular of DMPs, DMCs, and DMRs, to deliver a clearer message to the average consumer. DLNA's value proposition has always been solid; the challenge has been, how to get an alliance of more than 200 members to agree on a single message, one which resonates with the average consumer. Apple's entry into this market now gives them an end-to-end solution that looks suspiciously like a DLNA architecture--iTunes as the digital media server (DMS); the new Apple TV as the digital media player (DMP); and the iPhone, iPod, and iPad as digital media renderers (DMRs) or digital media controllers (DMCs).

DLNA's always had the architecture right; now it's time to get the message right. Ironically, Apple's announcement may've been the best possible kick in the pants for DLNA and its members. Personally, I have a foot in both camps; I ordered the new Apple TV today, which will be the DMP in an all-Mac content flow (Mac Mini as DMS, iPad as DMC/DMR, Apple TV as DMP). But, I also firmly believe in DLNA; today I picked up the Samsung Epic 4G, which serves as a DLNA DMC/DMR, to go with my Promise DLNA NAS (DMS). I think I have a DLNA DMP floating around here somewhere, but that'll have to wait...

Tuesday, July 20, 2010

More from the Clean Energy Ministerial

Random snippets and quotes from the Clean Energy Ministerial...

Governments around the world have already committed $56 billion in stimulus funding for energy efficiency.

Over the next 40 years, more than $270 trillion (that's right...with a TR) is expected to be invested in clean energy worldwide.

A consistent theme here (as it was at the ARPA-E conference at National Harbor a few months ago) is the need for a price on carbon, as well as a consistent policy on energy efficiency at the national and state levels, as well as worldwide.

India is spending more on feed-in tariffs as a percentage of per capita income than anything we have on the table here in the U.S.

From Secretary Chu's talk...
Standards stimulate technology, a great example of which is dramatically improved refrigerator efficiency, despite predictions of gloom and doom from the refrigerator industry at the time that tougher regulatory policies were introduced (which is also a common occurrence in Energy Star, and I'm guessing in other ecolabels like Blaue Engel and Nordic Swan--Coop).

The role of technological innovation is constantly underestimated in its ability to lower costs.

Since buildings consume 40% of energy in the United States, we need a new way of designing and constructing buildings. Computer-Aided Design (CAD) has been around for years, but incorporating embedded energy in the build equation is a foreign concept in the construction industry. When Boeing designs a new airplane, every change in design has a dependent change in materials required and energy consumed. We need to design buildings in a similar vein, enabling calculation of not just the materials used, but their resultant impact on all aspects of the building's energy footprint. DoE is preparing guidelines to enable these measurements, leading to enhanced comfort, energy, and cost savings.

LEED ratings are based on design performance, not actual performance...that needs to evolve.

One of ARPA-E's many goals is to cut cooling energy consumption by 25-40%.

Retrofitting urban roofs and pavements with solar reflective materials (i.e., white roofs) would be the equivalent of taking all cars off the road for 11 years emissions-wise.

John Holdren, Assistant to the President for Science and Technology Policy: Between 1970 and 2005, energy efficiency increased roughly two percent per year; over 35 years, that equals a 50% increase in efficiency. Stated more compellingly, the energy required to create a point of GDP has been cut in half.

Montek Singh Ahluwalia gave some interesting numbers on India's national campaign to move from incandescent bulbs to compact fluorescent lights. Last year, India migrated 200 million bulbs to CFLs; this year, they expect to migrate twice as many, with the goal of having moved fully to CFLs by the end of next year. The energy savings is pretty mind-boggling--migrating from incandescents (at 10 lumens per watt) to CFLs (at 70 lumens per watt) is hugely compelling, with a further move to LED lighting (at 100 lumens per watt) being even more compelling, although LED lighting prices obviously need to come way down.

RK Pachauri gave a great example of entrepreneurship and energy, speaking about training a woman to set up a solar panel to charge lanterns during the day that she could then rent out during the evening. At inception three years ago, such a system cost 4000 rupees; now, a new system is about to be announced that costs 1000 rupees, or about $21. That's progress.

More thoughts to follow...

Clean Energy Ministerial...Great Stuff!

Today I'm at the Clean Energy Ministerial in Washington, D.C. The array of energy talent here from around the world is mind-boggling...I'm extremely proud that the U.S. as a country was able to pull together an initial conference like this; UAE and the U.K. will have a high bar to meet as they host the next two years.

Secretary Chu kicked things off this morning with a number of announcements, two of which are near and dear to my heart. First is the Super-Efficient Equipment and Appliance Deployment (SEAD) Initiative, working to pull super-efficient appliances into the market. Having spent the last year leading the EPA/IEEE 1680.3 Television Energy Conservation effort, I've seen first-hand how challenging it can be to strike a suitable balance for all stakeholders in the discussion. Gaining worldwide government support for these types of efforts in a coordinated fashion is vital to incenting manufacturers to comply. Two of SEAD's high priorities are to increase energy efficiency of TVs and lighting, which combined make up for about 15% of household electricity use. Since TVs and lighting are pretty similar around the world, this is a logical place to start. SEAD believes that globally-coordinated energy incentive programs focused on lighting, TVs, refrigerators, air conditioners, and electronics could eliminate the need for 300 mid-sized power plants by 2030.

THAT'S pretty cool.

The second very cool announcement is the formation of the International Smart Grid Action Network (ISGAN). A theme that those of us in the Smart Grid standards world have been hearing over the last year is the high level of interest from the international community in what we're doing with Smart Grid standards here in the U.S. ISGAN government participants include Australia, Belgium, Canada, China, the EC, France, India, Italy, Japan, Korea, Mexico, Norway, Sweden, the U.K., and the U.S. Coordination of Smart Grid standards internationally will enable a more efficient market for manufacturers, better economies of scale for energy consumers of all sizes, and ultimately a better environment for everybody on the planet.

That's pretty cool, too...

Monday, May 24, 2010

See You at Connectivity Week!

Hope to see some of you at Connectivity Week this week. For those of you attending, hopefully I'll bump into you on either/both of the two panels I'm on...
If you'd like to attend Connectivity Week, feel free to take advantage of the Smart Grid Council of Silicon Valley discount. Click here to register; use discount code CW2010SGC to receive a 10% discount on your registration.

Wardriving 2010: Google, Your Data, and You. Say "Cheese!"

I've been following the recent hubbub about Google's collection of data from unsecured Wi-Fi networks with great interest. Why?

Been there, done that. Even got the t-shirt, along with news articles and local TV.



In early 2002, I went to work for a security software company called Cranite Systems; our claim to fame was that we were the first company to deliver a software-only solution which allowed Department of Defense stakeholders to use then-nascent Wi-Fi technology in a manner secure enough to sufficiently placate security folks. Mind you, these were the days prior to officially published DoD policy on Wi-Fi network use--at that point, the policy consisted of a bunch of interim guidance that said "DON'T".

When we started calling on potential DoD customers (i.e., uniformed stakeholders and others under the Pentagon umbrella), we learned that three approaches were in vogue...
  • Physically remove the Mini PCI Wi-Fi card from the expansion port on the bottom of the laptop--a money and time-waster, but a reasonably effective way to guarantee that "well-intended" personnel wouldn't be able to easily attach to Wi-Fi networks, accidentally or otherwise
  • Stand up Wi-Fi networks in the DMZ and require the use of a VPN to reach the base/post/enterprise network--which required punching holes in firewalls to allow access to a crippled subset of the network, while still allowing a range of layer two attacks like ARP poisoning
  • Simply say "DON'T", and hope like hell that users would listen--which they didn't
Even today, wireless networks are like a potential radon threat in your home--tough to quantify, and containing potentially deadly invisible radiation, either in terms of information leakage or in terms of lung damage.

To help folks visualize the penetration and concentration of Wi-Fi networks (and, let's face it, to drum up business), I started wardriving, which is a method of wireless network discovery using a data collection device and a GPS. Not long after starting at Cranite, by sheer coincidence I bumped into the father of wardriving, Peter Shipley, whom I had met a couple of times in the late '90s when we were trying to build a sports book wagering platform on top of WebTV. Peter was one of the folks who received a lot of airtime very early on, as the industry began to grok more and more that Wired Equivalent Privacy (WEP) was a misnomer. Peter was one of a number of folks who was very helpful to me as I tried to determine the best methods to discover, classify, and illustrate the increasing number of (largely unsecured) Wi-Fi access points and networks.

Based on input from a number of wardrivers, I'd soon kitted myself out with an 802.11 iPaq with a one-card expansion pack and a GPS. Less than a year later, I'd graduated to the newest iPaq with a two-slot sled, a sweeter GPS, a Japan-sourced high-power Buffalo Wi-Fi card, and a magnetic roof-mounted external 7 dBi gain antenna. Lemme tell ya, driving around DoD facilities (and right down Pennsylvania Avenue) in a Crown Vic with a big antenna on the roof was at once empowering and a little bit scary.

In these early days (2002-2003), many wardrivers were content with surveying their neighborhoods. I went a little OCD, taking my wardriving rig everywhere I went; by the middle of 2003, I'd identified and GPS-mapped more than 20,000 Wi-Fi access points worldwide. By then, I'd kind of proven my point--that Wi-Fi had begun to grow up, evolving from an expensive niche-y device for geeks to a more mainstream solution, one which seven years later is now taken for granted as a part of our daily lives. As you might expect, the maps which I generated initiated quite a bit of discussion at various locales in and around the Beltway, at both Defense and civilian agencies. In mid-2003, my wardriving rig was stolen from a locked rental car, which was a pretty good sign to me that I should find a new hobby.

By today's standards, the maps that I and other wardrivers put together were crude--but when you consider that "mash-up" is a term that's only been around for a few years, and that Google Maps didn't even exist until 2005, you'd realize how ahead of the curve we were, using MiniStumbler (PocketPC) or NetStumbler (PC) on our rigs to collect data, our own Excel scripts and macros or Stumbverter to cleanse the data, and Microsoft MapPoint to generate the maps. Each wardriver used his or her maps for a given purpose; many of us used them to illustrate to potential customers and to the media the pervasiveness of wireless networks (even in the 2002-2003 timeframe). Lots of folks didn't believe that wireless security was an issue, even when initial reports of WEP's weakness surfaced; the worldwide wardriving community augmented the work of the information assurance community to show that not only did wireless networks have vulnerabilities, but that access points had already begun their march towards broad market penetration.

I mention this not because it's a stroll down memory lane (which it is), but because the recent Google issue is nothing more than wardriving, redux--and that I believe that certain interests are blowing this well out of proportion to suit their own agendas.

Earlier, I mentioned that yes, I've been there. My iPaq wardriving rig was a pretty sweet setup, but like many wardrivers, I also occasionally used my laptop to do network reconnaissance. While NetStumbler was the software tool of choice, I also occasionally used Ethereal (long since morphed into WireShark), which was one of a range of free, often open source products designed for packet analysis and network monitoring. Like many of these tools, Ethereal allowed users to capture packets for later analysis. The challenge is that sometimes I'd leave Ethereal running while wardriving. You know what I ended up with?

Packets. Lots of 'em.

Since Ethereal was running in the background capturing all the packets in radio range while I was driving around, I'd end up with a capture file containing snippets of snippets of conversations. Were these packets interesting? I have no clue--I never bothered to look at them. Could they have potentially been interesting? Well, sure, I guess. But, lacking motivation to dig into these packets to turn them into meaningful information, I chose not to.

Similarly, from the sound of it, Google made the mistake of leaving a packet capture application running in the background while the Google Maps fleet was driving around, performing its 2010 version of wireless reconnaissance. I don't think that a lot of folks realize that the Google Maps cars actually perform three functions (well, four, but unintended packet capture likely wasn't in the PRD). In addition to taking GPS-tagged photos for use in Google Street View, and using lasers to collect three dimensional building imagery, the cars also GPS tag each Wi-Fi access point they see--Contemporary Wardriving, if you will. And, just as wardrivers circa 2003 were geolocating access points to drum up business, so is Google. In this case, Google's database of GPS-tagged access points enables better granularity for location-aware applications, enabling better customer targeting, and thus more valuable pay-per-click rates. Money...the root of all...

Here's an example. I carry a BlackBerry Curve 8320 as my primary mobile device. Yep, old school. The 8320 has a GSM radio and a Wi-Fi radio, but lacks a GPS. If I ask Google Maps to determine my location using only my GSM radio, resolution is often in the 1000 meter (or worse) range--meaning, Google can only figure out a general location for me, since it's tough to resolve exact location from three or four cell towers.

However, if I turn on my Wi-Fi radio, Google Maps will query not just the cell network (to figure out my location based on input from multiple cell towers), but will query Google's own database of Wi-Fi access points (put together by the Google Maps fleet) to augment the cell network information, providing much better granularity as to my actual location. Note that I do not need to be associated with and authenticated on a given access point for this type of location-based service to function; Google Maps simply needs to report back (via the GSM network) which access points it sees, and how strong the signals are. Google servers figure out where I am based on the relative power of each of the Wi-Fi access points Google Maps tells it about; when used in aggregated form, received signal strength indication (RSSI) can provide GPS-quality resolution, without the need for a GPS. Combined with cell tower information, I've seen Google Maps as accurate as 100 meters without a GPS, which is pretty freakin' cool.

Anyway, what happened in this particular case? Somehow, Google screwed up and wrote their application to not only record and tag images and access points, but to also slurp data off of the access points their vehicles passed. That's where they ran into trouble. Compounding the issue is that when the German privacy regulator asked to see the hard drives, Google wouldn't comply, then began erasing the collected information.

Hmmm.

For those of you who haven't been following along at home, let's recap.

In late April, Google said "Hey, we're just collecting the locations of access points while we're out driving around, taking those pictures you don't particularly want us to be taking". The German data protection administrator said "Knock it off". The head of data protection in Hamburg (where Google Germany is based) then said "I'm coming in to check it out".

The next week, Herr Caspar shows up at the office to see a Google Street View car, and asks to see one of their hard drives while he's there. Google says "Unh-unh."

And that, my friends, is where the proverbial shit hit the proverbial fan.

Google's refusal to produce the hard drive/s in question at Caspar's request is not only stupid, it might even be criminal, depending on the prevailing laws of the jurisdiction in question--subpoenas, discovery, destruction of evidence, yadda, yadda, yadda.

That's bad PR, and certainly doesn't follow the "Don't Be Evil" mantra. But wait...stick with me as the story goes from silly to absurd.

When push came to shove, Google admitted, "Well, yeah, we've actually been doing this since 2006, but we didn't really mean it. No harm, no foul. Tea?"

Actually, that's not what they said...they used weaselly PR phrases like "mistakenly collecting samples of payload data". Which is a little like saying, "I'm going to accidentally shoot you in the foot, but I'm going to use a small caliber weapon." They're data packets, Google--you know that better than anyone. Heck, your Chief Internet Evangelist invented the Internet. For real, and without Al Gore's help.

Google played the mea culpa card, offering to erase all the data in question to ensure that said data wasn't used in an inappropriate fashion. In fact, Google rushed to erase the data to comply with a request from the Irish Data Protection Commissioner.

Which was a ridiculously stupid move--on the part of the Irish Data Protection Commissioner.

Let me get this straight. Google's standing on the Ha'penny Bridge with their drawers down, holding a smoking gun. The smoking gun is the hard drive/s containing the collected data in question. Even though they have no idea of the actual contents, data privacy officials across Europe (where they take a much harder line on privacy than we do here in the U.S.) are up in arms about what's been collected--rightly so, in accordance with their privacy laws. Threats are issued. Attorneys, officials, privacy advocates, bandwagoneers, and other hangers-on all pile on to be quoted, regardless of their level of relevant knowledge.

Yet, somehow, they all manage to turn a blind eye while Google is allowed, even encouraged, to erase the collected data.

Hello, McFly? Forensics 101, for Pete's sake? Ireland, in encouraging Google to erase the data in question, you've just allowed Google to pull up their pants while throwing the smoking gun in the Liffey. In rushing to judge Google, Ireland (and potentially other locales) has allowed Google to destroy the very evidence which could be used to prove that yes, Google did in fact commit a crime, or least acted in an egregious and careless manner. Perhaps the Irish investigators did in fact put good forensics techniques to use, and used a tool to perform an archival backup of the data in question, prior to executing the destruction of the data.

On the other hand, if the entire point was to erase the personal data due to unlawful collection, it's unlikely that a backup of the unlawfully-collected personal data was kept, since that probably wouldn't have been legal, meaning the forensics examiner would've been committing a crime by backing up somebody else's personal data to prove that it was collected unlawfully.

Does your head hurt yet? I feel like shooting myself in the foot, using LISP, no less.

What's the net-net here? Lots of folks making a mountain out of a molehill. Don't believe for a moment that I'm undermining international privacy laws--I've followed European privacy and censorship issues since the CompuServe lawsuit in 1997. Did Google screw up? Yeah, they did. I also find it tough to believe that they didn't realize for four years that they'd been performing packet capture while collecting geo-tagged images and access point information. But, I find the over-reaction from certain (by no means all) privacy officials to be alarmist. Google was absolutely, unequivocally wrong to not allow Hamburg's Caspar to inspect the hard drives from the Google Maps cars. Further, Eric Schmidt's continued speaking out of both sides of his mouth is absolutely going to bite him and his publicly-traded company in the ass, since everything he says in public is indexed by search engines.

Like, uh, Google.

Schmidt's quote of "No harm, no foul" reeks of irony, since he himself famously said "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place".

Indeed, Herr Schmidt. Indeed.

Again, let me get this straight...
  • Google has been accidentally (which I'm willing to believe...no need for air quotes) capturing packets as part of their wardriving exercises for the last four or so years
  • They receive an inquiry as to the exact type of data they've been collecting, which they claim is innocuous data that contains no personally identifiable information (PII)
  • In confirming that no PII data has been collected, Google experiences yet another "Oh, shit" moment
  • They execute a strategy that seems to be a mix of Curly Howard ("Look at the grouse! Look at the grouse!") and Bart Simpson ("I didn't do it, nobody saw me do it, you can't prove anything!")
  • Evidence in at least one of the affected jurisdictions is destroyed
  • Threats of lawsuits and investigations pour in from around the world
  • My head and my feet hurt
So, here's the deal.

Google, you screwed up, and you were duplicitous in your attempts to address and resolve the issues. Privacy officials, you've made your point, even though the vast majority of you have no idea what it's like to perform network reconnaissance or packet analysis, or how ridiculously tough it can be to extract meaningful data from packet captures. Yes, the world has advanced light years in the seven years since I stopped wardriving; state of the art tools like Flying Squirrel and UCSniff make it easier than ever for trained professionals and script kiddies alike to capture and analyze information.

But, the point that so many folks seem to be missing here is intent. Yes, I realize that the very act of receiving and/or possessing PII is a crime in some countries. And yes, I realize that on the topic of privacy, Google has put its collective foot in its collective mouth time and again--and will again, and again, and again. While Google hasn't necessarily intended to commit privacy breach after privacy breach, they have, and will continue to do so. When you control the world's information, every once in a while you're bound to forget to lock one of your doors or windows before bed.

Careless? Yep.

Criminal? Not so much.

If the privacy community can use this incident as a lever to open a productive multi-party dialog with Google on privacy, one which consists of more than just Boon walking through a crowd, this will have been more than just a meaningless exercise. Google continues to receive a relative pass on privacy, certainly in relation to Facebook, whose Mark Zuckerberg also seems hell-bent on shoving his own foot down his throat--occasionally while wearing a ski boot still attached to the binding.

Google continues to receive free passes on issues relating to privacy, as they have for years. Sooner or later, their luck's going to run out. Rather than waiting, Google can, should, and must step up and prove to the world that they're serious about privacy.

If they don't, they're not going to be smiling in their mug shot.

Cheese!

Tuesday, April 20, 2010

Free Smart Grid Seminar 4/21 in Sunnyvale

I'm speaking tomorrow night (4/21) at the Smart Grid Council of Silicon Valley's maiden event, being held at Detati Communications in Sunnyvale. I'll be addressing the state of Smart Grid in the consumer home area network (HAN) from a regulatory and standards standpoint; Yvan Castilloux from People Power will address consumer energy efficiency and awareness, as well as open source software for the HAN.

To learn more and to register for Empowering Consumers to Go Green, click here. Space is limited, so please register in advance; assuming we don't burst at the seams, we should be able to accommodate walk-ins, but registering in advance will help the organizers properly plan for refreshments.

Hope to see you!

I Seem to Have Lost a Quarter

No, not two bits. Like, nearly three months since my last post. What the heck? I know, I know...busy is no excuse.

What's new...lots of pounding on Clear's 4G network. In fact, I'm sitting in Santa Clara right now, enjoying a 10 mb/s downstream, 2 mb/s upstream link. Tons of stuff going on in Smart Grid, as you might expect, too--seeing some very innovative stuff in the home energy management system world. More on that soon, but more on the femtojack sooner...

Saturday, February 6, 2010

magicJack CEO Dan Borislow Interview Part II

Each year at CES, queues for taxis, coffee, and lunch always seem to take a month, particularly during the first two days of the show.

Pretend it’s still CES…it’s been a long month. You don’t read me for snippets, you read me for analysis. Maybe even insight, at least occasionally.

When we left off four weeks ago, I’d just broken the news that magicJack was stirring up the telecom market once again, with the announcement of their forthcoming femtocell, which I (and now most others) call the “femtojack”. After Dan’s team published their release on the femtojack, I was inundated with a ton of technical and regulatory questions. I’m not going to attempt to answer them here—not only is doing so magicJack’s job, but I’d rather focus on a topic I consider more compelling—customer service, particularly in the context of making things right.

What’s the secret to success for just about any company? Ideas. Innovation. Passion. Execution. The magicJackers are short on none of these. Borislow and his team exude passion, whether discussing hardware, software, networking, saving consumers money, or their competition. I have to laugh at some outlets taking Dan to task for swearing when describing a competitor. You know what? Good for him—this walking-on-eggshells, politically correct world in which we live today can be stifling. I enjoy hearing someone call it like it is. Precious few entrepreneurs are willing to publicly call out their competition, out of fear that doing so might hurt fundraising efforts. Less need to raise capital means less need to do or say the politically correct thing. Free the mind, and the mouth will follow. Or something like that. Exhibit A: Mark Cuban. He’s having fun.

(Speaking of having fun, just for goofing around sake, we conducted a fairly unique magicJack call—Dan’s laptop using a magicJack connected to the world via a Sprint 4G modem to my Mac using a magicJack connected to the world via my a Verizon MiFi. And it worked!)

While most people think “magicJack” (which is how I refer to them for simplicity’s sake) as the company itself, the actual parent company is named YMAX. YMAX owns magicJack, but they also own and operate a voice network, and own companies dedicated to software and hardware development, among other things. What makes this particularly cool is that Dan has assembled the entire end-to-end ecosystem to minimize risk in his business equation. While owning each component by no means ensures success, ownership enables integration on a scale all but impossible for the typical system developer—and rest assured, magicJack is a system, rather than a couple of best-effort Internet clients common in most VOIP offerings.

Case in point—magicJack’s silicon subsidiary has developed a chip integrating unheard-of capability for the cost. Don’t believe me? The femtojack’s core silicon contains technology for echo cancellation; serial flash; a CD-ROM emulator; controllers for GSM and the femtocell; audio codecs; and subscriber line (SLIC) and USB interfaces—and probably some other stuff I’m forgetting. When you do the math on the bill of materials to bring this type of device to market at a price of $40-$50, you begin to understand just how large-scale this integration actually is.

Right then. Back to customer service.

A year ago, I had no experience with magicJack. When I showed up at the It Won’t Stay in Vegas CES party, one of the pieces of swag was magicJack. I grabbed a couple, both for testing use in the lab and for use from overseas. During the sign-up process, I was dismayed to see a really lousy effort on privacy, with the user required to give up a bunch of personally identifiable information (PII) before even seeing magicJack’s privacy policy. That was bogus, and I called out magicJack, challenging them to resolve this.

Shortly after my post, I received e-mails from both magicJack’s PR person and from Borislow himself. I couldn’t quite figure out if I’d lightly struck a nerve or thoroughly pissed him off, but we ended up parrying in a conversation both on the blog and privately on e-mail. Dan stressed how much progress they’d made in improving their customer service ratings over the previous year, as well as their commitment to ongoing customer care. As most readers know, all too often this type of talk isn’t worth the paper it’s not written on—basically, it’s bullshit with a capital BULL.

Except, in this case, it wasn’t. Dan made the commitment that they were going to get better, and they did, going from an F from the Better Business Bureau to an A- today. That’s snatching victory from the jaws of defeat. Yow. You don’t make a transition like this overnight…so how did they do it?

Dan realized that he had a company-defining issue, one requiring an innovative solution that a typical call center couldn’t handle. As part of reinventing magicJack’s approach to customer service, he set some very aggressive goals—first and foremost, establishing customer communication in less than five seconds. How could a company with this type of growth rate achieve such a high customer satisfaction rate while keeping costs low enough to maintain margins and operational efficiency? Off-shoring.

But, not your typical off-shoring.

Most readers are familiar with the debacle so many companies have encountered when off-shoring technical support, leading to lost customers, negative press, and eventually re-on-shoring (perhaps coining a term…maybe “repatriating” would be better.). magicJack decided to offshore to countries with a wealth of competent English writers/readers—but to only offer support via online chat. Why? Economies of scale. An operator taking a voice call can address a single issue at a time. An operator conducting an online chat can handle up to five incidents simultaneously, maintaining the efficiency that magicJack must have to deliver quality service at a cut-rate price. Beyond that, the percentage of English-fluent readers/writers is (in Dan’s estimation) as much as ten times higher than the pool of English-fluent speakers—meaning, someone who has learned written English is a great tech support employee for magicJack, regardless of how well that person actually speaks English, or how strong a spoken accent might be. A bigger pool of applicants means better-qualified customer service agents, a more competitive internal support environment, and a better overall solution.

Dan had one of his team members walk me through their back-end support setup, allowing me to watch typed chat exchanges between real, live customers scattered across the globe. I must say, magicJack’s system is pretty sweet—efficient, effective, and extremely beneficial from a cost standpoint.

I mentioned that agents service multiple customer support chats simultaneously. Eavesdropping on the screen of an agent half a world away who’s conducting three, four, five simultaneous chats made me think of two things—instant messaging and intentional latency. Watching an agent move from chat window to chat window to chat window reminded me why I don’t use traditional IM clients, and why I only log into Skype when I actually need to chat with someone. If a bunch of chat windows were my job, I think I’d be great at it, but since it’s not, I’ll remain largely IM-free. “Intentional latency” may not be the exact term, but it’s a concept that’s stuck with me since taking a class from Jim Carlini at Northwestern two decades ago—the concept that an automated call distribution (ACD) system is as valuable for routing calls to the proper operator as it is in training customers to not expect the phone to be picked up on the first ring. Outside of Southwest Airlines, I can’t think of the last time I called any service provider who didn’t make me go through a phone chain to reach the proper person. (Thanks, Southwest.) I’m conditioned to deal with some amount of delay (and angst) before reaching somebody who can actually help me out. With magicJack’s agents supporting multiple chats at once, customers can see a delay of 10-20 seconds or more from the time they end up typing a response until the agent begins his or her own response. But, since that’s set as the norm, I don’t think customers do too much teeth-gnashing. Chats are initiated quickly, usually in less than five seconds; agents keep the customers engaged; and most importantly, customers anonymously grade the agent at the end of the chat.

Grades. Not just for schoolwork any more.

I love the grading concept. I wish that more customer service interactions could be graded immediately upon completion. A couple of weeks ago, United had a big fail at ORD, when their inability to get a jetway to a gate-arrived airplane for 11 minutes caused four of us on a flight to SFO to misconnect, even through the SFO airplane was still on the gate; based on the number of us who were ready to burst out of the starting gates to get off of our plane, I know that we weren’t the only four who ended up missing connections we should’ve easily made, but didn’t. United, you earned an F. A few days earlier, I’d pulled into a Marriott property with an unplowed parking lot, even though it hadn’t snowed in days. I don’t typically mention stuff like this to the hotel, but this was egregious, particularly since I ruined a new pair of shoes trudging in from the lot. The front desk agent shrugged off my comment about the lot not being plowed; even when I pressed her on the issue of why it wasn’t plowed, she showed no interest in providing an explanation. Marriott, you earned an F—but you raised it to a B courtesy of the property’s general manager dropping me a note within 48 hours of my website complaint, offering to pick up the cost of my shoes and put some extra points in my account. Here at the Marriott Wardman Park where Shmoocon attendees are currently enduring (?) the snowpocalypse, Marriott gets an A+, having kept employees on-property last night to ensure that they could meet the expected level of service for the ~1500 of us in attendance.

Anyway, back to magicJack support. I think they’re light years ahead of what most companies are doing—not all, but most. They’re using tools to not only manage customer service, but to measure customer service, then act upon that data. The idea of tracking agents’ output for purposes of reward, penalty, or compensation certainly isn’t new. But, the ability to combine the server-side monitoring of agents with customer-side innovation (such as setting a 24-hour tracking cookie on a client’s computer, and immediately escalating the chat to a “superagent” if the client initiates a second call in a 24-hour period) is compelling. Tying that together with the ability to remotely take over a customer’s machine via LivePerson to actually show them how to resolve the issue, or simply fixing it for them, makes for a further compelling solution—one which ideally leads to a customer grading an agent as an A.

The three call regions are staffed 24 hours a day, seven days a week, with an average of about 120 agents in service at any given moment; roughly ten or so of the highest-rated agents (superagents) are on duty at any time, ensuring escalation coverage no matter the hour. Average chat length is about 16 minutes; with agents supporting up to five chats at a time, the efficiency factor works out well. Sure, you might say that single-tasking a chat could result in a faster time-to-resolution; but, when you think about the time that troubleshooting takes (plug in your magicJack, make sure your phone cord is tightly seated, tell me what’s on your screen now, etc.), multitasking becomes much more attractive.

Even more interestingly, agents are compensated based on their call volume—and a grade multiplier. Meaning, an agent can’t simply rush through support calls to ring up a high number of calls complete, regardless of quality. The grade multiplier ensures that agents will provide due care to each caller (or at least, to the vast majority); sloppiness leads to low grades, which leads to less compensation, which leads to no longer being a customer service agent for magicJack.

I’m intrigued by this story and this model not because I got a couple of freebie units last year. I’m intrigued by this story because to me, this is really a case of “ain’t necessity a mother”. Or something like that. magicJack had a serious, serious problem a couple of years ago, when their Better Business Bureau rating was an F. Folks, it don’t get much worse than that. Memories are long, hearsay even longer. I had dinner at CES with a buddy of mine who’s in the VOIP space. He mentioned that he’d seen my femtojack post, and asked how I could respect a company whose BBB rating was an F. I told him that I couldn’t respect a company whose BBB rating was an F—and asked him if he’s bothered to check magicJack’s BBB rating recently. When I told them that magicJack had improved to an A-, he mumbled something along the lines of “they suck”, then ordered another drink.


Well, yeah. magicJack did suck. And, some portion of geekdom and the phone-calling public will continue to think they suck—but for a pretty high percentage of their user base, magicJack must be doing something right. Shelf space in Wal-Mart and Best Buy isn’t cheap to obtain, and is even tougher to hold onto if product return rates are too high. Units are obviously selling in, selling through, and being used with a decent level of customer satisfaction.

I’m hopeful that the femtojack will achieve similar or even more widespread success. No, I don’t know whether YMAX is going to be able to overcome the wrath of mobile carriers, and whether they’re on the verge of an avalanche of grief from the FCC.

But I can’t wait to find out.