

Introducing BrowserID: A better way to sign in - joeshaw
http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in

======
SeoxyS
They seriously need to work on their communication skills. It took me a good
15min to figure out what this thing actually does. And I'm still not sure I
got it right. OpenID failed because it was too complicated for mere mortals.
This, I fear, may be too confusing. At least form the way it's presented.

After reading the protocol spec, I have a somewhat better understanding of
this. If I got this right, this is basically what this does:

* asymmetric crypto authentication in the backend.

* control over email address == authentication.

* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).

* falls back to regular email authentication we see every day.

I'm still unclear how you can securely verify email ownership thru
cryptographic means. Anybody care to explain it?

~~~
bct
Ignifero described what happens when your browser or email provider don't
support BrowserID.

When your browser and email provider both support BrowserID:

1\. You log into e.g. gmail.

2\. Your browser generates a keypair and sends the public key to gmail.

3\. Gmail signs your public key and sends your browser a certificate saying
"this key is owned by whoever@gmail.com".

4\. You click "sign in" on some site (e.g. Hacker News) that uses BrowserID.

5\. Your browser sends Hacker News an message saying "my user is
whoever@gmail.com", that is signed with the private key generated in step 2.

6\. Hacker News looks at the "gmail.com", grabs gmail's public key (the one
that signed your public key in step 3) and verifies the signatures.

Hacker News now knows that you control whoever@gmail.com.

The process is described fairly well (diagrams and everything) at
<http://lloyd.io/how-browserid-works>

~~~
huhtenberg
Read through your link, and here's just an observation -

> _BrowserID is a decentralized identity system_

BrowserID effectively links identity an email service provider, and while I
realize that not everyone shares their emails with Google, a vast majority of
people still does. That's not that much of _decentralization_ , is it?
Practically speaking.

(edit) Added _practically speaking_... and ease up on that downvoting,
distinguished HN comrades. Non-natural post scores hurt my feelings.

~~~
JoshTriplett
"decentralization" doesn't mean "forced decentralization". Anyone can register
a domain name and have their own email at that domain, so anyone can create an
identity. And ignoring the transitional bits in BrowserID, eventually that
identity gets controlled entirely by the public/private keys in the user's
browser.

Or, in other words: if you don't trust Google, don't use gmail; that someone
else chooses to do so doesn't make this system less secure for you.

~~~
huhtenberg
Sure, I understand that of course. I am just saying that _practically
speaking_ this property is not going to matter much in the world where
everyone and their dog is on GMail. It is certainly nice to have though.

~~~
nl
The last numbers I saw put Gmail at under 10% of email account marketshare.
Hotmail and Yahoo both had much bigger shares.

It's difficult to imagine an authentication system that doesn't have some kind
of centralized mechanism for making sure identities aren't duplicated. In this
case, delegating that to a combination of two existing technologies (DNS for
the domain, then email for the username) that are open, well understood and
easy to implement seems appropriate.

What's the alternative? Using some kind of pseudo-GUID and then maybe a
derivative of the Paxos distributed consensus algorithm to decide if it is to
be trusted? I'd imagine there would be a good number of PhDs in that approach
before a system like that would be close to being ready for actual
implementation.

This system seems just about as decentralized as is practical. If you disagree
I'd be very happy to hear alternatives.

~~~
JoshTriplett
You _can_ have fully decentralized identities quite trivially: just create a
public/private key. No consensus algorithms required. With browsers now
supporting synchronization features to connect the browsers on all systems
used by a single user, such a system could actually work quite well now,
without the usability issues it would once have had.

~~~
nl
This is a variety of SPKI[1], right? I was thinking of a conventional PKI
approach, with an adapted web of trust to verify identities [2].

You are right - theoretically this could work. But it would pretty much take a
"boil the ocean" approach to make it work.

Browsers would need to implement a secure (private) keystore, and presumably
some way to sync that to other browsers.

A whole new standardized authentication flow would need to be created, which
wouldn't be the same as the existing certificate-based authentication (which
no one uses anyway)

[1]
[http://en.wikipedia.org/wiki/Simple_public_key_infrastructur...](http://en.wikipedia.org/wiki/Simple_public_key_infrastructure)

[2]
[http://en.wikipedia.org/wiki/Public_key_infrastructure#Web_o...](http://en.wikipedia.org/wiki/Public_key_infrastructure#Web_of_Trust)

~~~
nolliesnom
Huh? Browsers support client SSL certs today, but for some reason nobody uses
them except intranets.

------
ora600
What I'd really want to see is public-key authentication for website.

Let me upload my public key when I create an account on a website, and let the
browser interact with my ssh-agent to authenticate.

~~~
wmf
This already exists, but the UX is terrible and there's a chicken-and-egg
problem in getting it fixed in every (deployed) browser.

[http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-
client-c...](http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-
certificates/)

~~~
joeyespo
Yeah, even using them over at GitHub (well, pushing with Git over SSH in
general) has proven to be a rather steep learning curve for a lot of people.
But hey, it's being widely adopted there, so that's a step in the right
direction for this.

------
superuser2
My first ever programming project (I was 11) was basically this (edit: from a
UI perspective, not under the hood), in PHP. I had no idea what I was doing,
the architecture was questionable and at this point decentralization and
OpenID were new and hot. It flopped horribly; it would have been a nightmare
had it taken off, but it was fun.

My flow was basically this: website links to <http://my-
site/login?to=http://site.com/authenticate>. User logs in against my MySQL
database with an email I verified and a password. If successful, I generate a
"ticket" number, my site makes an HTTP post to <http://site.com/recevive> with
md5(ticket number + secret key) and the user's details, and then the user is
redirected to <http://site.com/authenticate?ticket=12345>. Site.com verified
the ticket using its API key and stuck it in its database. When the user hits
site.com/authenticate, it looks it up by ticket number and has that person's
details.

Obviously a terrible idea for a number of reasons (MD5, the race condition
between the user and the ticket, and the reliance on my shared server being
up) but my 11-year-old self thought it was pretty cool. Just thought I'd
share.

~~~
rubyrescue
that's a really cool project at 11 years old, both in terms of your idea and
what you can actually accomplish! off topic, but when i was 11 i had a c64 and
basic and couldn't dream of talking to another computer unless i saved my
program to the tape drive and had my mom drive me to my friend's house to load
it on his c64.

------
stickfigure
One huge problem: Email address != identity.

I should be able to change my email address (and/or email hosting provider)
without changing my identity on a bazillion sites around the internet.
Facebook got this right from the beginning. Google is sort-of getting this,
although the chasm between Google Accounts and Google Apps Accounts makes this
really messy.

Really this product should be called BrowserEmailAddress, not BrowserID. It
doesn't serve identity.

~~~
paulosman
I agree that email address != identity, but nothing would stop a site that
uses BrowserID from allowing a user to change the email address that they use
on that site.

It's very similar to the countless existing services that rely on email for
identity... you'd just have to verify ownership of the new email address
(usually through a confirmation email).

~~~
stickfigure
Sure, every website can implement this flow, and users could could go to every
website they've ever logged into and update their email address... assuming it
all works properly even though they might not have access to the old email
address anymore.

At the very best this technology offers considerably less value to websites
and more hassle to users than Facebook or Google. And it's about 5 years too
late.

~~~
paulosman
"Sure, every website can implement this flow, and users could could go to
every website they've ever logged into and update their email address...
assuming it all works properly even though they might not have access to the
old email address anymore."

And how is this different than the current situation? Nearly all web sites
require an email address. With BrowserID, you at some point confirmed
ownership of that email address, so you could continue to use it to login,
then change when you're ready.

"At the very best this technology offers considerably less value to websites
and more hassle to users than Facebook or Google. And it's about 5 years too
late."

Tell that to users who a) don't have Facebook accounts or b) don't want to use
Google or Facebook with their identity. Far more people have email addresses
than Facebook or Google accounts.

~~~
stickfigure
Fast forward another ten years. Do you really think typical websites will
still ask people to create usernames and passwords? I predict that the current
trend of "offload that crap to Facebook/Google/BrowserID" will continue. Even
BrowserID.org makes that assumption.

The question is whether a BrowserID identity is as useful as one of the
established identity providers. You start out with a chicken-and-egg problem;
websites won't consume BrowserID if users aren't using it, and users won't use
it if websites aren't asking for it. What will overcome this Catch-22?
Techwise, the dependence on email seems less compelling than Facebook or
Google auth.

Maybe BrowserID can rely on mass distrust of Facebook and Google. I'm not sure
that's sufficient though - especially with Google.

~~~
21echoes
facebook, i agree, makes sense for an assertion of your public, real-name
identity. there will always be sites and situations where i _do not want_ my
real name associated with what i do there.

google auth is just one provider of the same identity as browserID-- an email
login. so, imo, browserID is a strict improvement, in that it is more seamless
than google auth in regular usage (leveraging the browser as the user agent),
and works with more providers.

------
sirn
How is it different from OpenID, apart from it's not decentralized?

~~~
mbrubeck
This lets users sign in with an existing email address, so they don't need any
new sevice or identifier to remember. It's decentralized; Mozilla has a
service for web developers for convenience, but any site can implement the
protocol itself instead (or use another provider). And it's designed to let
browsers handle the login flow in the future, simplifying login and account
creation for end-users.

~~~
pavel_lishin
Most of the oauth services I used allowed me to create an account with ... an
e-mail and a password.

Literally the same thing, here.

~~~
Osiris
Isn't one of the advantages of this system is that your password doesn't get
stored by the website? Just some type of token? If their database gets stolen
or leaked, they shouldn't be able to hash attack your password and gain access
to it since it's not there.

I'm just assuming it works this way, as passing the password along would
defeat the security of the system and make you more vulnerable.

~~~
pavel_lishin
You still have to enter your e-mail and a password into the BrowserID popup;
and with OAuth, the sites using it didn't store your password either.

I literally don't see a major difference here, except that now we're using
email instead of whatever bullshit identifier you could have used with other
OAuth providers (e.g., your Livejournal username, your Facebook account, etc.,
etc.)

If I'm wrong, I would love to be enlightened.

~~~
bct
browserid.org ("the BrowserID popup") is just a way to bootstrap the system.
The idea is that browsers and email providers will support this protocol and
browserid.org will be totally unneccessary.

The major difference is it's totally irrelevant to the site (relying party)
what provider you're using. The site doesn't need a login page with a facebook
button, a twitter button, a livejournal button, etc., it just needs a "sign
in" button.

------
kpanghmc
Am I the only one who kind of wishes we never went down this "let's fix
authentication!" rabbit hole? It feels like we've just replaced one problem
with another.

Now, instead of simply having to remember what username/password combination I
used, I have to remember which (if any) OpenID provider I used, how much
information about myself does said provider expose, and how to merge my
accounts when I inevitably end up choosing the wrong provider and create a
duplicate account on the site.

~~~
starwed
Did you _read the article_? This is an attempt to fix all those issues you
list.

~~~
speckledjim
So now when your email address gets hacked, ALL your usernames and passwords
to every website are also hacked!

At least with normal un/pw you need to request a password reset from the
website.

I don't think we should be tying logins to email.

~~~
21echoes
by tying all your logins to email, you're left with only one account that you
can focus on keeping secure and un-hacked (or a few, as BrowserID allows for
multiple emails). The BrowserID is also in talks about support one-off
identity generation via the browser, bypassing email on sites which you don't
want to identify with.

BrowserID supports password reset requests, which can be built into the
browser

email is the single most user-recognized signifier of identity we have on the
internet today. tying identity to anything other than email just seems silly

------
ams6110
More at <https://browserid.org/>

~~~
falava
and <https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol>

------
drfloob
Say you're signed in to BrowserID already ... is there anything that would
stop an attacker from being able to log you into some other BrowserID website
without your knowledge or consent? With login reduced to two mouse clicks, it
seems like a well-crafted webpage could log you in wherever it wanted. If that
were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited
at a large scale.

------
AlexeyMK
BrowserID is a good first step, but ultimately as a website owner I'd much
rather authenticate with Twitter/Facebook, since it makes it easier for me to
figure out who the user is/ask them to share with friends.

Identity is cool, but Facebook is winning the 3rd party connect game right now
because it offers websites syndication, which is more valuable than just
authentication.

I'd love to see a BrowserID that can _also_ grant permissions to Facebook,
Twitter, etc.

~~~
AndrewDucker
I do not want to link my Facebook with anything else. Nor do I wish to link my
Twitter to that.

I do not trust either of these companies, or have a strong attachment to them.

If they want to support BrowserID then they can - as username@facebook.com or
username@twitter.com

------
rlpb
This looked great until I got to certification. At this point I think they've
just re-invented X.509 and added browser/Javascript integration.

Why not have a new way of using X.509 in the browser? I'm not talking about
client side SSL certificates as they are at the moment. I mean that on login
to your mail provider the browser will automatically generate a keypair and
get a certificate either from your mail provider or from a third party which
has verified that you own the email address in the traditional way. This
certificate will contain a Subject of mail=me@example.com, Issuer of either
CN=example.com or CN=trustedverifier.com. Then the browser can just present
that certificate as normal to destination.com, and perhaps only on request (so
the user can choose whether to "log in" or not). If the issuer matches my
email address domain then destination.com will fetch the public certificate of
example.com to verify. If the issuer matches trustedverifier.com then
destination.com will already know whether it wants to trust it or not and have
the public key if it does.

This does seem to be what the article describes, only the article has more
optional elements and re-invents some of the cryptosystem rather than re-using
X.509.

------
dendory
How is this any different than current single signon systems, like Microsoft
Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and
anyone can run their own but lets not forget users dont care at all about
that..

~~~
bct
As a user, once your browser and email provider support it, it's single-click
login (and signup), without any redirects.

As a site operator, you don't need to choose which company you're going to
accept as an auth provider, or have a login page with lots of icons on it; you
just have one button that says "Log in".

------
yarone
So, it's basically a traditional single-sign on system? Is that right? Like,
in the old days, I integrated one of my products with AOL. You could click a
link and it would automatically sign you into my product using you AOL
Screenname and Password (behind the scenes, AOL would verify that the
screenname and password are correct and my app would create a new user in my
database).

~~~
bct
Your description is too vague to generate an answer to your question.

------
tobylane
I hope that one of these services is on the user's side, so much that the ID
isn't enough for, say, advertisers to track users over different sites. And
how graceful is it for versions of IE that aren't 'recent'?

------
shockie
What's the advantage over openid?

~~~
bct
Some people think that using URLs instead of email address in OpenID was a big
mistake.

Having in-browser support for this kind of thing seems like a plus, too.

~~~
codyrobbins
To this day I still do not understand how this inane argument happened to be
the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’
_more_ confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not.
I’m not one for conspiracy theories, but the whole URL-versus-email argument
against OpenID seemed like the excuse various people used to put a nail in
OpenID’s coffin when they didn’t like it for other less defensible reasons.

~~~
nl
I'm a reasonably competent web user.

I've implemented OpenID.

I run my own Open ID server.

I've implemented Shibboleth (and lived!).

I know that Yahoo is an open ID provider, and I think Google is too, but when
I'm presented with an old-style (URL) OpenId login I don't have a clue what to
enter to use either my Yahoo or Google account to login.

Yes, I know that now most login forms provide easy links to use Google or
Yahoo to login. The point is that entering the URL is confusing because no one
knows what their OpenID url is, and it isn't standardized in anyway.

The situation is so bad that the OpenID providers had to develop a way for
users to enter their email addresses, and then the client performs a discovery
request to find their URL.

~~~
codyrobbins
What bearing does the fact that Google and Yahoo chose shitty hard-to-remember
OpenID URLs have to do with the overall fact that OpenID uses URLs for
authentication? That’s like saying using email addresses for authentication is
a terrible idea because mail administrators can assign really hard-to-remember
email addresses. The solution is simple: set things up so they’re not hard to
remember. Again, there is no reason why your OpenID login can’t be ‘name.my-
open-id-provider.com’.

I would be willing to bet Google and Yahoo made their OpenID URLs hard to
remember because they already had single sign on products that they wanted in
the limelight preferentially over OpenID. However, cursory support of OpenID
made them both look like supporters of open standards even if their
implementation (hard-to-remember URLs) doomed it to underuse.

------
bruceboughton
Can someone explain what makes this a _browser_ ID? I don't get it...

~~~
mbrubeck
It's designed so that the browser can interact directly with the
authentication protocol, saving steps for the user. This grew out of Mozilla
Labs' "account manager" project, which had a protoype UI you can see here:
[http://hacks.mozilla.org/2010/04/account-manager-coming-
to-f...](http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/)

------
bergie
Somehow I find WebID (<http://www.w3.org/wiki/WebID>) more appealing. There
are already countries that give their citizens SSL client certs.

~~~
bergie
Here's a quick WebID to BrowserID comparison:
[http://lists.w3.org/Archives/Public/public-xg-
webid/2011Jul/...](http://lists.w3.org/Archives/Public/public-xg-
webid/2011Jul/0011.html)

------
flashmob
Email != authentication

Websites providing a disposable email address are mainstream - even hotmail
allows you to create them these days.

------
newman314
Thought that popped into my head. Instead of having separate passwords for
different sites, now you are trusting your email provider to be absolutely
secure (with that one ultra-secure password you are using, right?).

So if a BrowserID user were to ever get their email service compromised, it's
keys to the kingdom.

IMO, I think this needs a rethink.

~~~
caf
The idea is that you would use this in situations where you currently would
offer a "reset password via email" option - since this means you already
treats control of the email address as identity.

~~~
newman314
Wondering why I was downvoted for pointing this out.

But anyways, my impression from reading the page was this is not just used as
a password reset scenario but as a general login method.

Which if you agree with, leads us back to the scenario where authentication &
authorization lies solely with the email account, which if compromised is the
single point of failure.

I would appreciate it if someone were to help point out what flaws there in
this line of thought rather than a straight downvote with no explanation.

~~~
Dove
If an email account can be used for password reset, a compromised email
account can be used to log in. Since much of the internet already works this
way, the proposed system has a neutral effect on security, while making things
easier for users.

In effect, any site that offers a password reset via email is _already_ using
your email as your identity.

~~~
bxc
I actually use this as the primary authentication mechanism for sites I
rarely/occasionally visit... password reset at every login!

------
NHQ
This is just another web based open sign-in. Why did they tie this to email,
of all things?

My immediate thought was that a browser-based ID implementation would let you
keep secure credential on the computer, saved by the browser, up to and
including pics, profile, etc. In other words, take social credentials native.

------
lojack
Do people really consider OAuth2 difficult to implement?

Also, not trying to knock BrowserID or say that it'll never work, but due to
browser compatibility this is still probably 5 years off before I'd begin
using it. From what I can gather it requires postMessage which alienates IE7
users.

------
rnicholson
Interesting that in the demo video he used in-browser Gmail vs. using
Thunderbird.

I realize its nitpicky, but figured for a demo like this Mozilla would use the
opportunity to showcase all their offerings in the workflow.

------
ams6110
This seems to encourage using the same credentials everywhere which I think
most agree is a "bad idea." If BrowserID is compromised, the attackers have
access to all the sites where I use browser id, right?

~~~
jdunck
There is a large distinction here - the provider (in the video, BrowserID.org)
would have to be compromised, as only they have your credentials. This is
quite a bit different and more secure than using the same credentials with
many different providers, because in that scenario, the weakest of any party
could get compromised and that way compromise all parties.

~~~
slowpoke
In addition to that, since the ID provider does not get any sort of
information about which websites you visit with your ID, it would be
impossible to know where exactly the ID is in use.

At least that's how I understand it.

------
latchkey
This is full of fail. Your email address is not your identity. I must be able
to change my email address without having to change my identity.

~~~
51Cards
It's not that simple. They authenticate against your Account at Browser ID. I
would assume you can go into Browser ID and add / remove email addresses from
your account which makes it even easier when you change your email. Now you
don't have to visit 20 different sites to update them.

~~~
stickfigure
Is there some sort of account ID other than an email address? It looks like
the email is all that gets sent to the website (although I didn't read deeply
enough to be sure). If you change (add new, remove old) your email address at
browserid.org then revisit a site you authenticated to before, what happens?

~~~
JoshTriplett
Indeed. Ideally, the site would end up with the user's public key, and
optionally their email address; they should use the former as the primary key
in their database, and the latter as an easily-changed property.

~~~
bct
That would be nice except I think that you will have different keys for
different browsers, and for different machines.

Presumably you could sync them up if you really wanted to, but it would be an
awful user experience if that was mandatory.

------
jerrya
I like this idea, and I hope mailinator supports it.

------
nikcub
can't see it taking off only because it solves a problem that 99% of internet
users do not know exists. I have never had a regular, average, non-tech
internet user say to me 'you know what is a real pain in the ass - signing up
for web applications'. Most of those users only ever signup for a handful of
applications, and are using oauth for everything else (twitpic etc.)

------
orijing
Does that mean this is as secure as the user's email provider? What if I have
an AOL email and AOL gets hacked?

------
omarqureshi
Whilst I understand and really like the non-tied in aspect of it, I'd probably
implement some sort of facebook/twitter/google account authentication
alongside of it.

Reason being is that, it too is just another authentication service that I'd
rather users not have to make the effort to sign up for.

~~~
bct
The intention seems to be that browserid.org is temporary, just there so that
this can work until it's supported by browsers and identity providers
directly. Once that is achieved, there's nothing extra to sign up for.

~~~
omarqureshi
Sorry, the video didnt make that clear - not even slightly.

------
nolliesnom
By what mechanism does BrowserID require RPs to respect the valid-until field?

------
pavel_lishin
Was that... was that a blink tag?

------
alecbenzer
anyone else notice the video is recent enough to have google+ enabled?

------
Raphael
And then you get phished for your one password.

~~~
JoshTriplett
The password only applies to browserid.org, not the browserid standard. Native
browser implementations won't involve a password, just a public/private key.

------
ignifero
You can try it live at <http://textchannels.com/> . I like it , it's pretty
simple and neat. Easier than oauth login.

~~~
riffraff
can you explain why this is easier than oauth?

~~~
ignifero
\- No need to register your application with browserid.org

\- No need to use an oauth library (just 1 GET request)

\- Oauth provides access to user data on the provider, while browserID
provides no data. Less anxiety for the users.

\- No request_token/access_token pairs

\- In the future, the user will (hopefully) be able to change his default
browserid and as a developer you just don't care.

~~~
riffraff
thanks, I thought you meant it was easier _as an end user_ and could not see
why.

~~~
JoshTriplett
The implementation using browserid.org, to an end user, will not get any
easier or harder than OAuth or any other third-party service. On the other
hand, a browser-based implementation could simply bring up a browser
notification saying "Authenticate to example.org using your email address?",
to which you could click "yes".

------
ukaszg
so, its an easier way for sites to track users?

~~~
bct
Not really. It's a way for a user to prove to a site that they control an
email address.

~~~
ukaszg
sounds like tracking to me

~~~
bct
Ok, but only In the same way that typing in a username and password on a
website allows them to track you.

~~~
superuser2
To have a conversation with someone, you have to uniquely identify them, and
correlate all the words they've said as coming out of their mouth and not
somebody else's, then put all these words (which you've identified as being
part of the same sentence) together into meaning. As you get to know someone,
you correlate all these meanings into a mental model of the person, and use
this to guide how you interact with them. People who can't do this are
considered mentally ill.

It's one of the defining pieces of consciousness, and essential to the human
experience. So, as programmers, we make a deliberate choice to enable this
functionality for end-users in most internet applications (like email, IM,
social networking, and discussion boards) by displaying a token belonging to
you (and only you) next to what you're saying and doing. This can be a
username, email address, phone number, picture, etc. This particular spec is a
more convenient way of establishing your ownership of a token used to identify
you.

You can choose to use sites (like 4chan) which don't reveal this information
publicly. But if you sign your posts, or indicate in any way that you are the
same person as a previous poster, you are establishing an identity which 4chan
is tracking and revealing to the world. There is no conversation without
tracking.

Whether or not the sites you use choose to identify you, however, they know
you by the IP address you are coming from; they have to, in order to send
information back. Tor can mitigate this (if you change exit nodes with every
request) by hiding your path from A to B within a cryptographically secure
mass of data, but if the random number generator determining the amount of
time to wait before forwarding your packets is broken, that's blown too.

IP addresses change, so if I want to correlate you between your ISP's DHCP
leases (or between your multiple internet connections - Starbucks, home,
work), I'll set a cookie. This is how when you clicked "reply", Hacker News
knew it was still the same person who logged in with "ukaszg/hunter2".

Tracking is essential to civilized conversation. To fight tracking itself is
to ask that the entire Internet become 4chan and that nobody assume the same
identity from post to post. I hope this isn't what you mean.

\--

Tracking makes you nervous because

a) computers exhibiting human behavior is kind of creepy b) sometimes,
companies choose to violate users' expectations of what will be done with the
information they've correlated

But you can't take this information away from them while still using their
services. You can refuse to use services which violate your expectations, you
can demand better, and I encourage you to.

But ultimately, these services have to pay the bills and make a profit. I
could be wrong, but I'm going to take a wild guess and say you wouldn't pay
for Facebook; I'm going to go even further and say that you would be
_offended_ at the idea of having to pay for Facebook.

Well, Facebook's employees want to feed their children and buy cars and houses
and video games and TVs just like you. And Facebook's owners and investors
want to get rich. If these objectives aren't met, there won't be a Facebook.

So instead of taking your money, they take what they can guess about what you
will buy, and charge advertisers for it. Advertisers, in turn, can show you
products which you won't scoff at paying for, and eventually some less
speculative cash enters the equation.

You cannot avoid tracking. But if you want the companies tracking you to
conform to your expectation that your data not be used to sell you stuff,
you're going to have to pay them. Rackspace email is $2/mailbox/month. There
are no ads.

~~~
JoshTriplett
I agree with almost everything you just said, with one exception: while sites
often need to have a notion of identity for their users, that identity should
not correlate with the identity used on any other site, or with other
alternate identities on the same site, unless the user wants that correlation.

A system based on pseudonyms allows anonymity through the creation of
arbitrary new identities. With care, such a system can also support
reputations for a given identity.

------
rkalla
I interpreted this as OAuth + Gravatar... is that the gist?

------
detay
I don't want to see another browser-specific feature from mozilla. As
mentioned here several times it doesn't seem too different from openId and
it's for mozilla!

seemed pointless to me.

------
NathanKP
When I tried to sign in on the demo site I got a 502 Bad Gateway error. This
isn't an encouraging sign.

