<p>I remember when Dan Mills showed a first prototype of having the browser help you login. I have long wanted to login to the browser itself, and then have it handle my passwords etc. I use 1Password to do some of this, but I still have to click on buttons to do the login.

The initial work has been taken to the next level with the Account Manager Add-on by Dan and co:

How Does It Work?

The Account Manager specification proposes two small changes to Web sites:

The browser needs to know how to register, sign in, and sign out of your site. You will need a static JSON document, automatically discovered by the browser, which describes what methods the site supports and how they should be executed. For example, a web site might describe their support of “connect” (sign in) like this:

This example tells the browser that the site supports signing in with a form POST to /accounts/LoginAuth, and what parameter names to use for the username and password (Email and Passwd respectively).

The browser needs a way to check which user (if any) is currently signed in. To do this, you need to set an HTTP header in the same code where you would set a cookie with a session ID. If you can’t set an HTTP header, you can also supply a URL the browser will ping.

The header would look like this:

X-Account-Management-Status: active; name="Joe User"

That would tell the browser that “Joe User” is now signed in, so it can provide the appropriate UI (to switch users or sign out).

It’s good to see someone is finally doing it.
However I feel safer entering my passwords each time, rather than having them stored on my machine, unencoded.
(How hard will it be for someone to open %APPDATA%/Mozilla/Firefox/ & read off the password file?)
I guess they could have the option of client-side encoding, & passing across the hash to the web service (so they could duplicate the encoding on their server-side hash), but I still feel a lot safer storing my encrypted passwords on remote servers, rather than all bunched together on my machine

ProPuke, what makes you think Firefox stores passwords unencrypted? They’re Triple DES encrypted and protected by a master password. Unfortunately they implemented the master password prompt in the most annoying way possible: modal popups, sometimes several in a row. Until they fix that, I’m not so enthusiastic about any new password related feature in Firefox.

1) As Novalis points out, bots can use the json file to efficiently discover not only how to login, but (to some extent) what class of login system you have. It makes it easy to create a targeted attack that works on all sites with the same kind of login. I’m not saying they can’t get this info now, but it takes more work than just loading and parsing a json file.

2) Auto-login creates massive surface area for cross-sit-scripting attacks. Right now, if you’re not logged in to a site, an XSS attack against that site is going to fail. But if your browser logs in for you, well… all the attacker has to do is make sure to send a request for the login page first.

Perhaps the Firefox implementation addresses #2 somehow (tab sandboxing would be ideal) and maybe #1 is worth the added convenience to users, but I’d wait and see on this.