Free Newsletters
Technology & Business Daily

InfoWorld
Log-in | Register

  Tuesday, December 16, 2003 

The LinkedIn dilemma

Here's what stopped me from writing an endorsement for somebody on LinkedIn today: the requirement to define our relationship as one of these choices:

The same kind of thing stopped me from joining the identity-badge party at the Digital ID conference recently. I'm bugged by forms that invite or require me to specify the unspecifiable. Particularly when Google already knows the subtle truth of the matter. For example, the signup for nTag asked me to state my interests. But I already do that all the time. Everything I write is a statement of my interest in something. Should it be my job to fit those interests into the Procrustean bed of somebody else's form?

Ditto for LinkedIn. The sum of my relationship with "R." is: 1) he wrote some cool software that I tried and wrote about, and 2) we had an exchange, more recently, in the comments area of a website. And guess what? When I google for "R.'s" last name and mine, the first two hits correspond exactly to those two points. If there were a freeform input box, I'd have simply entered the query.

Now clearly I lead a much more public life than most, and I create a much more complete document trail for Google to follow. But is that a difference in degree, or a difference in kind? I suspect the former. And if that's true, then I'm skeptical as to the benefit of a parochial reputation system such as LinkedIn, which requires extra effort to join, to feed with metadata, and to use. If we have (or are rapidly evolving) a global reputation system that can absorb and contextualize our routine communication, then parochial systems will need to deliver huge amounts of extra value.

I'm well aware that not everybody can or should spill vast quantities of words onto the Web. On the other hand, I think it will make less and less sense to operate in stealth mode. Most "knowledge workers" will want to plug into the public conversation at certain points -- to promote our activities, to discuss and collaborate, to seek information. So you drop a stone in the pond, and ripples go out, and reflections ripple back. Do we need more than this, really?

I understand the impulse to codify social protocols in software. I'm not at all sure we can do it in ways that preserve the necessary fluidity and fuzziness. But there's VC money in them thar hills, so I guess we're going to do the experiment and find out.

 

Sun's identity pitch

At SunNetwork 2003 back in September, Jonathan Schwartz made the case that the Java card is the most strategic piece of Sun's whole technology stack. Actually, I'd say per-employee pricing is the real strategic innovation. But I've always hoped to see movement on the identity card front, so this clip, in which Schwartz stresses something I've been harping on for years, got my attention:

Java card support will be built into the desktop that we offer. It is the fundamental way we will help people to understand that if there were a menu item in your mail app that said, 'Show only mail from people that have been strongly authenticated,' then spam would disappear. 'Show me only content that has been strongly authenticated,' viruses would disappear.

I'm with you, Jonathan. Now as a longtime advocate of this view, I've gotten plenty of useful pushback. And it's true, there are problems. PCs don't come with card readers. It's unclear how the governments and banks and airlines and other entities who currently issue cards will evolve the identity infrastructures this solution implies, how those infrastructures will cooperate, and how revocation can be managed in a scalable way.

That said, I worry less nowadays about card-reader deployment. Maybe because I figure that we'll just authenticate to our phones, and let them talk Bluetooth to PCs and other devices.

I also worry less about how we'll relate identity cards (or devices, like phones) to identity infrastructures. Look at how ordinary credit cards are now used at airline kiosks. There's no multifactor authentication involved in printing your boarding pass. But multifactor authentication is part of the larger system. Your government-issued biometric, aka driver's license with photo, will also be checked. It's all a question of context.

I'm not even too worried about how we handle revocation, now that I've seen what Corestreet has in mind.

All in all, I'm fairly optimistic about the scenario Schwartz paints. The whole talk, by the way, is here. It lays out the new server and client strategies. I do wonder how all this adds up to a "Java system." There are roles for J2EE, J2SE, and J2ME. But the server suite is based on Solaris, with Java APIs that you might rather generalize as Web services APIs. The desktop is based on Linux/GNOME/Mozilla/StarOffice, and while there is indeed a Java client software renaissance underway, it looks to me as though IBM (with Eclipse and SWT) is more of an instigator there than Sun. But the cards, and more importantly the phones, that part I get. So maybe J2ME really is Sun's ticket.

 


Recent Entries


















































Sponsored Technology Links

 
 
 HOME  NEWS  BLOGS  PODCASTS  VIDEOS  TECHNOLOGIES  TEST CENTER  EVENTS  CAREERS   About | Advertise | Awards | RSS | Contact Us 

Copyright © 2008, Reprints, Permissions, Licensing, IDG Network, Privacy Policy, Terms of Service.
All Rights reserved. InfoWorld is a leading publisher of technology information and product reviews on topics including viruses,
phishing, worms, firewalls, security, servers, storage, networking, wireless, databases, and web services.

CIO :: ComputerWorld :: CSO :: Demo :: GamePro :: Games.net :: IDG Connect :: IDG World Expo
Industry Standard :: IT World :: JavaWorld :: LinuxWorld :: MacUser :: Macworld :: Network World :: PC World :: Playlist