Title
3rd Way verification

Short, concise description of the idea
If and when hacking makes authentication difficult/impossible, then physical verification of account at house address could be used in feasible rare cases. It has the added advantage of bridging online and physical reality, for those who opt for it.

Full description of the idea
This is a suggestion. Authentication in special / occasional cases can be enhanced by incorporating a 3rd way of physical verification at the home address one has provided (2nd-way verification being mobile phone).
For example, when there is a problem, you are providing your company address also as a point of contact. In rare cases, a person would take the effort to actually write a letter by post or in the rarest cases may even walk in to our office for clarification. The same could be done on the side of users too.
For example, a facility may be provided as an option for the first time activation of an account to be done by physical postage, if a user wants it for reliability, privacy or any other reason. This will involve considerable cost and is a slow process, but if internet becomes an unsafe place due to a lot of hacking, this added layer of authentication may help (assuming that post office personnel don't steal letters). Google did this with Google Ads, and so this is not new, although it may involve considerable effort in streamlining the business process.
It has the added advantage of bridging online and physical reality, for those who opt for it.

• transparency, integrity, security, privacy, legality

• exposure, discordance, cost, slow down, more gateways for error

These suggestions posted in connection with this lj_dev discussion: http://community.livejournal.com/lj_dev/817228.html

Title
Allow non-password authentication when posting via ATOM API

Short, concise description of the idea
Allow non-password authentication when posting via ATOM API, such as OAuth

Full description of the idea
Allow non-password authentication when posting via ATOM API

As brought up in http://www.livejournal.com/support/see_request.bml?id=998808 sometimes you want to let other sites post on your behalf without giving them your password. (OpenID seems a little no-no to me for this, but YMMV.) OAuth is what all the cool kids are using. Make it so!

• Less of users giving their passwords to possibly untrusted third party applications
• Better compatibility with the rest of the blogosphere
• More love for the ATOM API

• This API has not been high on LJ's priority list

Title
Support OAuth access for LJ API

Short, concise description of the idea
External tools and LJ clients require your password to be able to log in as you and post to your journal, but if LJ supported OAuth, this wouldn't be required any more.

Full description of the idea
OAuth is similar in concept to OpenID, but while OpenID is about saying 'I am LJ user X', OAuth is about saying 'I give service X access to my LJ'. It gives a revokable way to give external tools (such as meme posting, or cross-service posting) access to your LJ, and could work for LJ clients too.

This would mean that there would be less risk of account hijacking, as you could use external services like LoudTwitter without having to give them your LJ password. Similarly, downloaded LJ clients could use OAuth so that you don't have to trust the client author with your password. Eventually, your password is used only to log into the LiveJournal web site itself.

Instead of entering your password, the external site or LJ client would direct you to a page on LJ which would ask you if you wanted to authorise that site or application. If you say 'yes', it records the details and allows the site or application to access your account. LJ could also provide a list of sites that you've authorised and allow you to revoke any of them at any time. Presently, the only way to 'revoke' access is to change your LJ password, and if you use multiple external sites or LJ clients you'd then need to go and change your LJ password in all the ones you still want to use.

As an example, Twitter have recently implemented OAuth and plan to replace their password-based API authentication with OAuth over time. This will allow Twitter users of services like 'TwitPic' (which posts/hosts images) to post their pictures to Twitter without giving the third-party service their Twitter password.

There's a very good explanation of OAuth on their website: http://oauth.net/about

• Improves the security of LJ accounts by limiting the distribution of users' passwords.
• Provides a means to revoke access if you decide you don't want to use a 3rd-party service.
• Increases confidence in third-party services as they no longer require users' passwords.

• Would require possibly significant implementation work.
• May be of no benefit to LJ users that don't use third-party services or downloaded clients.
• OAuth is still quite new, and isn't in use by lots of people. There may be problems that haven't been discovered yet.

Title
Manage Accounts page should include your other accounts

Short, concise description of the idea
Currently, the Manage Accounts page allows you to edit only a user's personal settings and those of any communities they manage. It could be expanded so that other accounts under the user's control could be accessed as well.

Full description of the idea
Many LiveJournal users have multiple accounts. The Manage Accounts page is great for seeing the settings of all of the communities you manage and your personal account, but I would prefer it to be able to manage other accounts under my control, by adding them to that list. For example, if I control account FOO, and communities A B and C, and account BAR which controls communities D, E, and F, I would be able to manage all of them from the Manage Accounts page.

In short, you could be able to "link" any accounts you control together, so as not to have to log out to manage other accounts (or post from them, view their friends page, etc!)

• Manage the settings of any or all your accounts without having to log into each
• Post from any account you control, being able to choose userpics specified under each account
• View Protected entries from the list of any account under your control

• Excess load on LJ servers as this change is implemented
• Difficulty in notifying users of this change/explaining it to them
• Additional security checks have to be added in order to "link" your accounts

• Ah geeze, I don't know :)

Title
PKCS12 for email posting

Short, concise description of the idea
Use PKCS12 certificates for email posting

Full description of the idea
Use PKCS12 certificates for email posting.

• PGP/GPG installation not needed.
  Everyone have PKCS12 built-in in their Outlook/Thunderbird

• Some movements needed to get PCKS#12 certificate for end-user.

• http://search.cpan.org/~vipul/Crypt-RSA-1.50/lib/Crypt/RSA.pm

Title
Troubles creating an account

Short, concise description of the idea
Add more information about cookies in the create account page

Full description of the idea
There is no information on the create account page that cookies has to be activated to use LJ. There is no error message, too. There are a lot of people arround, who do not want to use cookies so they have them deactivated by default.

• It would be easier for newbies to create an account.

• Newbies getting nuts while using an account with cookies deactivated.

• Put a big warning on every create account page about using cookies.
• Test every newbie wether there have cookies activated and send an error message explainig the problem if not.