By Jake Edge
February 2, 2011
Last week's Security page had a quote from
37signals about its decision to drop support for OpenID. Since then there
have been several postings that purport to explain the problems with OpenID
and why it never gained much traction. One of the better
analyses comes
from Wired's webmonkey blog, which calls OpenID "The Web's Most
Successful Failure
". So, why hasn't OpenID taken the world by
storm?
OpenID set out to solve, or help solve, the "single sign-on" (SSO) problem,
so that users could have a single identity that they used with multiple web
sites. But OpenID is more than that, because it allows users, rather
than web sites, to decide how much personal information needs to be
shared. It is this user-centric nature of OpenID that may be leading to
its downfall.
We have looked at OpenID several times over the years, including an overview in 2006, and a look at OpenID 2.0 in 2007. By the time we
looked at the OpenID Connect proposal back
in June, the problems with users being able to control the amount of
information provided to web sites was becoming evident. It was, in fact, a
major
reason that OpenID Connect was proposed.
While OpenID is by no means perfect, the resistance to its adoption is not
necessarily completely technical. Other OAuth-based schemes have become
much more
popular at least in part because web site operators get access to much more
personal information by default than they get when users log in with
OpenID. Even site-specific registration tends to extract more information
(email address, full name, and so on). Because that kind of information is
valuable to web site operators—and willingly given up by the vast
majority of users—OpenID users are seen to be "less
valuable
", as OpenID Connect developer Chris Messina pointed out.
The Wired blog post put it this way:
Web publishers never warmed to OpenID since it allows a user to log in to a
website and leave a comment on a story, a blog post or a photo while
essentially remaining anonymous to the publisher. That anonymous aspect has
made OpenID less attractive to publishers who want to collect more data
about their readers or interact with them — whether that means following
them on Twitter, connecting with them on Facebook or sending them e-mail.
But one of the main alternatives to OpenID—one that has seen
much more adoption—is Facebook Connect (though the "Connect"
part of the name has largely been dropped). As that name would
imply, it is run by Facebook, which is an organization that is not noted
for its interest in preserving user privacy. One hopes that the
pervasiveness of Facebook sign-ons will have some boundaries. While it
does solve the SSO problem for Facebook users, in a fairly uncomplicated
way, it would be horrifying to be
greeted by your bank's log-in screen asking for your Facebook ID.
OpenID suffers from some design flaws, using a URL as the OpenID identifier
being one of the most prominent, but its Achilles heel is that it is complicated
for users, beyond just remembering their OpenID URL(s). An additional problem
is that some of the larger web services were only interested in being
OpenID providers (i.e. using their URLs to log in
elsewhere), and weren't particularly interested in being "relying parties"
(i.e. taking OpenID URLs from elsewhere to allow users to log in). This
asymmetric "support" for OpenID further muddied the waters for users.
At this point, though, we may well have seen the crest of the OpenID wave.
Wired posits it being incorporated into Mozilla's (and other browser
makers') efforts to move
identity
management into the browser itself. That would allow the browser to
route around the individual web site log-in screens and authenticate the
user behind the scenes, so OpenID could be used in a far less complicated
manner.
In the end, OpenID is targeted at users who value their privacy and
want to take control of their internet identities—two traits that
seem to be in short supply for many users. Facebook Connect (and the Twitter
equivalent) leverage huge user bases to make adoption by other web sites
very attractive. Though there is evidently still some user confusion about
using those authentication methods, the experience is more straightforward
than OpenID.
So, where do we go from here? The US government is starting to make noise
about trusted internet identities, which
might provide an alternative SSO solution—though not without privacy
(and other) concerns of its own. LWN has implemented OpenID relying
party support, though there is still some work and testing to do before we
can roll it out. The
37signals announcement and the related chatter seems likely to turn off
some other sites that were considering OpenID support.
It is tempting to call OpenID a failure, and to some extent it is, but it
has some compelling ideas, at least for technically (and privacy)
savvy users. But the features that are most attractive to those users
are precisely those that web site operators wish to
avoid—anonymous/pseudonymous authentication doesn't play well with
their business models. For sites like LWN, where registration doesn't
require any personal information, the barriers to adoption are likely to be
things like available developer time (that's certainly the case here). In
addition, there has
always been some interest from our readers in OpenID support but it never
seemed to garner a critical mass clamoring for it.
If OpenID had taken off the way many hoped it would, supporting it would
have become a much higher priority for LWN and lots of other sites.
As Wired notes, OpenID was ahead of its time. It suffered from some
technical problems—what new protocol doesn't?—but those could
have been fixed if there was some groundswell of interest from users
or web sites. Since that didn't happen, it's probably time to start
thinking about other SSO options that aren't controlled by companies or
governments. Without a solution that is under individual control, we risk
being herded into systems that cater to the needs of these large
organizations—with all the dangers to internet freedom that implies.
Comments (29 posted)
Shutting WikiLeaks down won't stop government secrets from leaking any more
than shutting Napster down stopped illegal filesharing.
--
Bruce
Schneier
Comments (none posted)
Groklaw has an in-depth
look at the
temporary restraining order [PDF] granted on January 26 to Sony against George Hotz for restoring the ability to run Linux on PlayStation 3 consoles. "
Hotz is also ordered to hand over to Sony "any computers, hard drives, CD-roms, DVDs, USB stick, or any other storage devices on which any Circumvention Devices are stored" in his "possession, custody or control." I guess it's off with his head, too, then, because he surely knows how to do what he did. People who live in countries that don't have the DMCA also know. Just saying.
[...]
I would have thought Sony would be more technically clueful about the Internet, but what they do well is get the law to help them out. That's the purpose of the DMCA, if you think about it, to scare people so they won't do what they otherwise can do. So Hotz is in some hot water at the moment, I'd say, an object lesson, and it'll stay that way until the hearing, a date for which is not yet chosen. And from my reading, I'd say after that too, at least with this judge.
"
Comments (22 posted)
In an unprecedented move, Egypt has completely removed itself from the internet, presumably in response to gathering unrest there, as
reported by Renesys. US (and other) politicians will undoubtedly look on this as a validation of the "internet kill switch" idea (pushed by Connecticut senator Joe Lieberman among others). "
At 22:34 UTC (00:34am local time), Renesys observed the virtually simultaneous withdrawal of all routes to Egyptian networks in the Internet's global routing table. Approximately 3,500 individual BGP routes were withdrawn, leaving no valid paths by which the rest of the world could continue to exchange Internet traffic with Egypt's service providers. Virtually all of Egypt's Internet addresses are now unreachable, worldwide.
"
Comments (38 posted)
Sourceforge.net
briefly reported an attack on its infrastructure on Thursday January 27 that resulted in some services (CVS, interactive ssh shells, and others) being suspended. More details were
released on January 29, which show that the attack exploited a privilege escalation to root in one of the Sourceforge services. "
Its better to be safe than sorry, so weve decided to perform a comprehensive validation of project data from file releases, to SCM commits. We will compare data [against] pre-attack backups, and will identify changed and added. We will review that data, and will will also refer anything suspicious to individual project teams for further assessment as needed.
[...]
The validation work is a precaution, because while we dont have evidence of any data tampering, wed much prefer to burn a bunch of CPU cycles verifying everything than to discover later that some extra special trickery lead to some undetected badness.
"
Comments (3 posted)
With an amusing title, "Nmap 5.50: Now with Gopher protocol support!", Nmap
lead Fyodor
announced
the most recent release of the network exploration tool on January 28. It
does indeed come with Gopher support, but other new features may be of wider
interest: "
A primary focus of this release is the Nmap Scripting Engine, which
has allowed Nmap to expand up the protocol stack and take network
discovery to the next level. Nmap can now query all sorts of
application protocols, including web servers, databases, DNS servers,
FTP, and now even Gopher servers! Remember those? These capabilities
are in self-contained libraries and scripts to avoid bloating Nmap's
core engine.
"
Comments (none posted)
