[...]we prefer to show other internet sites around the net, even when they aren’t associated to us, by linking to them. Below are some web-sites worth checking out[...]…

Thanks for writing this! 

With respect to the fact that information is leaked back to the IP (browserid.org), this is only the case until we have native browser support. browserid.org is a requirement to bootstrap the system, and mozilla incurs the cost of running it and commits to running it with the transparency and level of responsibility you’d expect.  Ideally though, we’ll see browserid become popular and will get all major browser vendors on board, this eliminates RP to IP (browserid) leakage, because the *browser* becomes the implementation provider.

As far as verification, the central verification service is provided as a convenience.  By design it can and should be run by the RP.  A community member has already written a verification library in PHP, and as we progress we’ll work to ensure that robust verification implementations are available for all important web development environments.  By encouraging and making it easy for RPs to own verification, we plug this information leak.

The password anti-pattern you discuss is a real problem.  In the next several weeks I hope to implement a UX iteration under Alex Faaborg’s guidance and this is one of the issues we hope to address.  I’ll blog as I go and you can follow our progress on github.

As far as passwords over GET, that’s fixed 2 days ago and I’ll push it into production shortly: https://github.com/mozilla/browserid/commit/c53307230a13706bdc3ea7cbb6a930f8b3ea4f15

Private keys might be compromised by an attacker with access to your device, but so can today’s credentials stored in your browser profile and password manager.  I don’t see increased risk. 

Finally, right now there’s some excellent discussion going on on the identity mailing list, and one of the topics of discussion is how we can help the user deal with email addresses that are compromised or they loose control of.  This is one problem of many that the community is working through in the open – while some solutions are proposed I don’t know that we’ve yet struck the perfect balance: a mechanism that is simple for RPs to implement while being discoverable and making sense to users.  I’d encourage you to come discuss your proposal on the list:  https://lists.mozilla.org/listinfo/dev-identity

Again, thanks for the excellent criticism!
lloyd