Hacker News Reader

bcton Introducing BrowserID: A better way to sign in

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".

bcton Introducing BrowserID: A better way to sign in

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.

bcton Introducing BrowserID: A better way to sign in

I've read it more thoroughly now, but I'm still not sure where you're coming from. You'd rather use a secondary identity authority, even when a primary is available? Or are you saying you'd like to require a full send-me-an-email-and-i'll-click-on-a-link verification every time you log in to a relying party?

bcton Introducing BrowserID: A better way to sign in

Can you link me to where you're reading that? I don't see anything like that (but I've only skimmed the documentation).

bcton Introducing BrowserID: A better way to sign in

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.

bcton Introducing BrowserID: A better way to sign in

A system that assumes that everyone is on GMail will tend to ensure that everyone is on GMail, whether or not that's a good thing.

Decentralization leaves the possibility of that situation changing open. That matters.

(Or, less philosophically: there was a time that everyone and their dog were on Internet Explorer. I think we're all glad that we didn't close the door to browsers other than IE.)

bcton Introducing BrowserID: A better way to sign in

I don't follow you, what's invasive/interfering about it? You & your browser can decide whether any of the steps of this process actually happen.

bcton Introducing BrowserID: A better way to sign in

> On the other hand, email is already known to be an unstable key for identity.

Would be happier if there was only one company that provided email service and you were only allowed to have one address? That's essentially the situation with Facebook.

You're free to apply whatever constraints you like to your use of email. An email address is as unstable an identity as you make it.

bcton Introducing BrowserID: A better way to sign in

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

bcton Introducing BrowserID: A better way to sign in

> Facebook got this right from the beginning.

What a weird double-standard. A feature of email (that you can have several, and you can change which one you use) is a failure, and a failure of Facebook (that it's one site, forever) is a feature?

We're all familiar with ways to migrate from one email address to another. If/when you leave Facebook/it disappears, how will you migrate your identity then?

bcton Introducing BrowserID: A better way to sign in

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

bcton Introducing BrowserID: A better way to sign in

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

bcton Introducing BrowserID: A better way to sign in

There are two separate things here. Using the terminology from http://lloyd.io/how-browserid-works , you have:

1. Primary Identity Authority. This is a host (i.e. the one in your email address) that supports BrowserId. This is fully decentralized.

2. Implementation Provider/Secondary Identity Authority. For now the site has to choose one to trust, but once your browser has support it becomes the IP, and when your host becames a PIA there's no need for an SIA.

bcton Introducing BrowserID: A better way to sign in

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

bcton Introducing BrowserID: A better way to sign in

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.

bcton Introducing BrowserID: A better way to sign in

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.

bcton Introducing BrowserID: A better way to sign in

Once this is supported by browsers and email providers there is no "BrowserID" to be compromised, your email provider would have to be compromised (which already gives attackers access to all the sites that you use that email on).

(Unless you meant "BrowserID" the protocol.)

bcton Today Show hosts think gamers over 30 are "weird"

Anyone who thinks of "TV-watcher" as a significant part of their identity is a bit weird, too.

bcton Google Introduces Facebook Competitor, Emphasizing Privacy

There's no question that people care more about what their immediate acquaintances know about them. That doesn't mean it's a great path for society, though.

Unfortunately the fashionable thing to do these days is to assume that everything will work out for the best on its own.

bcton How Perceptual Hashes Work

http://musicbrainz.org/doc/Audio_Fingerprint

The Picard MP3 tagger uses this kind of thing (and MusicBrainz' database of tracks and audio fingerprints) to identify files.

bcton Anyone Can Take Down Facebook Pages with a Fake Email Address

(Alternatively: Golly, it sounds like having your business depend on a third party that has no obligation to you has all kinds of problems!)

bcton Anyone Can Take Down Facebook Pages with a Fake Email Address

Golly, it sounds like re-inventing the web on top of a centralised platform has all kinds of problems! Who'd have thought?

bcton RESTduino - Arduino hacking for the REST of us

True. Now that you point it out, it is odd that I chose to focus on that one divergence.

bcton RESTduino - Arduino hacking for the REST of us

This is really cool, looks like it will make integrating your microcontroller with other systems really easy.

But - and I hate to be the REST Nazi - this is RPC, not REST.

"REpresentational State Transfer" is about making things happen by Transferring REpresentations of resources' State.

The GET requests are good, but for setting outputs it should do something like:

  PUT http://192.168.1.177/9

with body

  HIGH

POST could work too, the important thing is that the resource's state, the resource's address, and the action being performed are all separate.

This RPC system is beautifully simple, it does what it needs to and I can't think of any way that making it RESTful would improve it, but it's not RESTful right now, and calling it that only deepens the confusion about what REST is.

bcton Bug 647959 – Add Honest Achmed's root certificate

You don't need to get all philosophical about it, it's simple: Racist speech is A Bad Thing* because people actually do make that absurd, dumb and wrong presumption, and racist speech reinforces those racist attitudes.

(* let's forget the word "offensive" because this is not the same territory as yo' momma jokes and curse words - racism affects the real world)

bcton Hashify.me - store entire website content in the URL

I don't think there's any abuse here (after all, data: URIs exist). A value is just another kind of pointer.

The important thing is that the identified resource is unambiguously identified.

bcton Hashify.me - store entire website content in the URL

What are the differences between this and a data: URI? Just the shortener and that it can use out-of-band Javascript for the editor?

bcton Why HTTP Streaming?

It's still draconian error handling, all the spec says is that you have to stop parsing and notify the user.

> Meh.

There were many circumstances that prevented the adoption of XHTML-as-XHTML. One of them was the fact that your users would get a cryptic error page, with no context, if something went wrong.

What Webkit does is much less threatening.

bcton Why HTTP Streaming?

Please note that there is an important difference between "well-formed" and "valid".

bcton Why HTTP Streaming?

> What would be weirder, seeing the page either render fully or blow up, or seeing a page start rendering and then at some point be replaced by an error message?

Who says the page has to be replaced? Webkit and Opera (IIRC) happily render the page up to the first error that they encounter.

Gecko's decision to do the YSOD was a bad one.