Protecting yourself from Google’s protection racket

About a week ago at Google I/O, Google said it would begin testing in June an alternative to passwords. People have been talking about eliminating passwords for years. They’re hard to remember, particularly when one has dozens of them. Some people have hundreds.

And people tend to mismanage them — the classic sticky note on the side of the monitor is only the best example. So, Google is proposing to use a mix of biometric and other data from users’ Android phones. This data is expected to include facial geometry (picked up by the camera), voice pattern (picked up by the microphone), walking style (picked up by the accelerometer), and swiping and typing patterns (picked up by the touch screen).

The intelligent part of the system is expected to create a summed likelihood score based on all the sub-scores, and if it passes some threshold — say, 85% — the gatekeeper gives the okay to the website. Google is calling this set of software Trust API. Various sites have to opt in to receiving these scores. Maybe Facebook only cares that there’s a 75% chance that you are you, but Bank of America wants to see 90%. The institution can send challenge questions if the score is too low.

The benefits of such a system are obvious. The user doesn’t have to remember anything. A hacker trying to spoof an identity would have a hard time matching all those sub-scores.

But anyone believing that this scheme is better than bad ol’ passwords needs to think again.

Up on Hacker News, readers greeted the proposal with derision.

One poster pointed out the privacy concern: in order to use a Web service of any sort, one is required to reveal his or her full identity. The whole point of a user name and password is that one can create a limited identity used for that purpose alone.

Another noted the beneficial transience of passwords: if someone hacks a password, it can be reset.  If someone hacks an iris scan, you can’t install a new iris.

Then there is the security concern: fingerprints can be cloned, retinal scans can be faked, photos can be copied. It might be possible to fool the gatekeeper. As one renewed adherent of passwords said, “Those things might be hard, but not as hard as getting something out of my brain (disregarding ‘rubber hose cryptanalysis,’ of course).”

One systems administrator pointed out that biometrics can’t be changed, and, for corporate IT managers, revocation of credentials is a requirement of any authentication system.   When an employee has been hacked, a new set of credentials needs to be issued to that employee.

Then, there is the performance issue: all this computation needs to be done somewhere. If it’s done on the phone, then performance and battery life are adversely affected. If it’s done in the cloud, possibly unacceptable delays may occur from round trips to the service. Given Google’s philosophy, it’s likely that such calculations will be in the cloud. That way, all roads lead to Google, and Google gets at least a sniff of all information passing through the Trust API.

Finally, a software developer noted that the whole notion of Trust API follows a disturbingly familiar pattern. A major player — in this case, Google, but it could just as easily be Apple, Facebook, or Microsoft — decides to create a huge artificial intelligence (AI) problem out of identity verification in order to “protect users from harm,” thus anointing itself the gatekeeper and effectively walling off competition.  

As another Hacker News poster put it, “I’m all for getting rid of passwords, but the idea of Google (and other service providers) keeping that much information on me would definitely push me to getting rid of [my] smartphone.”

If identity validation involves complex AI computation in the cloud, then no one except the behemoths will be able to do it anymore, which, quite possibly, is the idea.