Identity theft is rampant, and I wouldn't trust anyone with knowing too much about me. Banks and government agencies aside ... no one knows my full name no one knows my real birthdate (except the friends who show up to buy me drinks). no one knows my mothers maiden name no one knows my social security # no one knows my real postcode (unless they actually deliver goods) no one knows where I was born This also goes for random people and surveys, and any store cards / loyalty cards I may get. Why? I'm not paranoid, it's just that they have no need, nor right to that information. I don't have a big ego where I want to be able to google myself. Who I am is my business. All that aside, I don't see what's wrong with OpenID. It's fine because I can set up a number of different profiles for an email address I use for random activities (like SO or posting here). From my perspective, OpenID solves the insecure storage of credentials easily mapping credentials to other held data (although likely not the case in practice) 100 different implementations of password reset, forgotten password, insecure passwords in plaintext emails, etc

@Jeffrey Davis - There's a number of issues with that: Lets look at a http get request (using Fiddler2). ------------- GET http://www.google.com/search?hl=en&q=cookie&btnI=I%27m+Feeling+Lucky HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, */* Referer: http://www.google.com/ Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;) Accept-Encoding: gzip, deflate Host: www.google.com Connection: Keep-Alive Cookie: PREF=asdf=1234&abc=123; NID=asdf=1234&abc=123 -------------- The important part in the request is the query string, and the cookies. Without SSL, others can see everything. With SSL, others only see 'www.google.com' Cookies are, in reality, just another header in the list of http headers. Further, most authentication cookies and/or cookies that hold identifying information should already be encrypted by the server and only decryptable by the server, and there's already a mechanism for cookies to only transmit the cookie when the connection is secure. The authentication cookie for a typical web stack might look like: 745370B77DC347648F307DCFC800CD7BBF584A030D6477337ADD77670B77654222560F77A0DA36A4F5732D2AB867C828B22FC7777D05047B74AA08373FA70500DAFF2D2D0B7B7356BD22BAB0CA48DBF6D4D7872C5062DD8788B376F757B62D26D27F83AF777CD767B7427DDCA0DAFD82DD74DDA4 So if you can see the transmission in plain text, even with encrypted cookies, you can still become the person. The web's http protocol is stateless in the sense that between requests, a server has no ongoing connection with you. To achieve an illusion of state, the client holds the state, and cookies are a key ingredient to make it happen. Steal the state, become the person. So maybe you're saying you want to open 2 sockets per request? The first socket is the encrypted channel for transmitting the headers and sensitive information, and the 2nd socket is unencrypted. The web server would then have to combine multiple incoming requests, do something, then split the result into sensitive and non-sensitive information. The client then recombines the two streams and presents something to the user. I'm making a stab in the dark, but I recall the most expensive part of SSL is establishing the connection. So if you're already making an SSL connection, why wouldn't you just use that and avoid all the complicated and error prone splitting and recombining? Not to mention the re-architecture of every web server and every web client to support a new split protocol, and hoping that every web developer gets it right and never accidentally transmits sensitive information insensitively. Right now it's easy for a web client to display the green bar/padlock icon. if(All requests for content SSL) -> secure! if(no SSL) -> not secure if(partial SSL) -> not secure. The beauty of SSL is that it encrypts everything*. Your web client can be sure it's talking to the correct web server, and nothing* in the middle can know what you're doing.

I hardly think that all-encrypted traffic is 'boiling the seas'. As others write - it should be the bare minimum. The second you tell everyday people that almost everything they read, write, click, view, etc are completely readable by anyone in the middle (governments included) they are noticeably, and understandably, upset. Like most people, I don't have anything to hide, but that doesn't mean we don't value our privacy. Maybe it doesn't matter to you if people know what products you like on Amazon, or how often you visit thinkgeek, or if you have a predilection for anime. Maybe you descend from the Dutch and never draw the blinds on your house. Good for you, but most people expect a modest amount of privacy and do not want someone else linking all their habits together (if they're lucky, it's just to sell them something). Otherwise things become far too Orwellian for my liking. There's no need for 2-way tv's in them if you can glean all you need from someone's online life simply by capturing some of their traffic, or watching the websites they frequest. SSL is cheap, and for a modestly-size site, SSL offloading firewalls are easy for an experienced sys admin.