Weekly Update: 20 August

[denise]

Good morning/afternoon/evening/middle-of-night, Dreamwidth! So, this week, those who said that moving the updates to Wednesdays officially would mean they'd be posted on Fridays happened to be correct. I've got a good reason for it, though: I was waiting a day or two until we could commit some code so that I'd have something big and awesome to tell you guys about. More about that in a few minutes, but let's go through some of the rest of it first.

Oh, and for those of you who were curious after last week's update: the hole in our shower wall is now patched. (However, we came home from a weekend trip to visit my family to find that the smoke detector was beeping nonstop. Considering that we have 20' ceilings, and the building keeps the ladder locked up, this necessitated some unhappy calls to the maintenance folks.) I know y'all just couldn't sleep until you heard the outcome there.

Development

This week's code tour comes to us courtesy of jd. It contains mostly backend fixes and style display fixes, with one big exception (which I'll get to in a section of its own in a bit, although those of you who've already seen the code tour probably know what I'm going to say...)

As always, these fixes are not yet available on the live site, and won't be until the next code push. Keep an eye on dw_maintenance for announcements of code pushes.

Summer of Code

It's "pencils down" for Google Summer of Code, and we're really happy to have had such an awesome Summer of Code with some really dedicated, passionate, smart and talented students. It's been a great learning experience for everyone involved (especially us!)

You can view a sneak peek at one of the GSoC projects, the iPhone/iPad app with a title of iDreamwidth, by i_xerxes. The rest of the Summer of Code projects will be coming out over the next few weeks and months; just because the official SoC period is up doesn't mean that our students won't keep hacking on their projects. We'll keep you updated!

Nifty CSS Tricks

In case you guys don't know about it, the dw_nifty journal has tips, tricks, and nifty things you can do with your Dreamwidth account to improve your personal experience. One of the neat things it does is collect interesting tricks you can do with your journal style to customize the display of things, which is made possible through the magic of CSS (cascading style sheets) and the fact that our Styles team did a tremendous amount of work during closed beta and earlier to create CSS classes that would allow you to target just about anything you want using CSS.

Some of the tutorials that have been posted, for things that are frequently requested, are:

* Make entries from feed accounts have userpics, and give a custom background color to comments by certain users

* Add borders to your dynamic expanding cut tags

* Force all entries from a particular user on your reading page to use a single icon

Plus, there's an overall post about how to use CSS to filter your reading page, which can be useful for doing things like blocking entries from particular feeds/posters/accounts you don't want to see on your Network page, or blocking entries from that one really annoying person who spams your favorite comm with 20 posts a day about how adorable their cat is when he snores. (My cat is snoring right now. It's pretty adorable.)

If you come up with some awesome CSS tricks of your own, post them to dw_nifty so others can use them. We always love hearing about what people come up with.

Invite Codes

As many of you have noticed, we gave out more invite codes yesterday! This time, we gave 7 codes each to all users who have been active on DW in the last 30 days. You do not need to save the email that we sent you with the list of codes -- they're always available at your Invite Someone page.

If all your friends are on DW already, you can donate unwanted/unused codes to the dw_codesharing community.

Community Promo

Some communities you might be interested in:

metaquotes: Styled after metaquotes, this is a community for the funniest, most touching, most profound, or just plain awesome things you see while reading DW.

knitting: For people who like to take two sticks and a piece of string and turn them into things. (Side note, entries for the Maryland state fair are due on Monday. I don't think I'm going to finish the knitted sweater I was planning on entering in time. Sigh.)

sun_salutation: A community for people who practice yoga to discuss tips, tricks, and other yoga-y goodness.

classicfilm: Pretty much what it says on the tin! Discussion of all sorts for classic films.

As always, dw_community_promo is where to go for a good time.

And, since it's been a while since we've done community promotions in dw_news posts, it's time to start building up a list! If you've got an active community (receives at least a few posts per week) that you'd like others to know about, toss a link in the comments. It's helpful if you also include a brief summary of the comm's purpose and tell others why it's awesome.

Roleplaying Games

I've been really excited to see more and more roleplay games starting up on DW, since I think we've got a lot of features that are incredibly helpful for roleplay. (Of course, the true "killer feature" for RP is going to be the main/alternate account system, which is still on the roadmap, fear not.) Since we've been seeing lots of people requesting more invite codes for the purposes of RP, I thought it was about time to mention that we are happy -- eager, even! -- to give out "promo" invite codes: one single code that can be used to create multiple accounts, which can be given out to players so that your game doesn't have to scrounge invites from everywhere in order to make accounts.

If you're starting a game, and need codes for your players, just contact me in the Account Payments support category and let me know:

* The name of your game (this will be used as the name of the code);

* The number of accounts you envision needing (this can be added to later, if you need more; I only need to specify a number at creation);

* The main community for the game, which will be suggested to your players as part of the signup process

This also applies to non-RP communities -- if you've got an existing base of people who are coming over to Dreamwidth to join a community you started, or you're moving a community over wholesale, we're happy to give you out a promo code. It doesn't matter how large or small your community is. (Most of our promo codes are requested for 10-15 accounts to begin with!) We're happy to give out promo codes to anybody who wants to bring a group.

(Also, right now the closest thing I can find to a "here's a new game starting up!" type announcement place is rpads, which is pretty dead, so if anyone knows of anywhere better for me to point to in future news updates when I'm talking about RP games, let me know! Lord, I wish I had time to RP.)

Update Page

So! Last week in dw_news we demo'd the next round of the new Update Page, being revised in order to allow support for draft and scheduled posts (as well as many other usability tweaks and bugfixes). Just like last time, we got some great comments, which we (okay, fu and hope) have been collecting, pondering, and poking at.

The major dislike we've been hearing (from those who do dislike it, of course, which is -- thankfully, omg -- a minority) is that people feel the page is too 'busy'. So, right now we're working on how to balance the need to have access to the full range of features DW has without burying them or hiding them away vs presenting a design that doesn't make people instinctively flinch. There's going to be at least one more round of tweaks and feedback before we get to the point where we can even think about releasing it, don't worry!

One thing people have been frequently asking is what it will look like in other site schemes. We haven't shown it in other site schemes yet because of [insert long boring handwavey explanation here that basically boils down to, it was just incredibly simpler to present it as a static HTML page instead of as a page that could be 'skinned' using our site designs]. The time has come, however, where doing that conversion makes sense, in terms of work expended, since we're getting closer and closer to a usable design. This means that the next round of design user-acceptance-testing will allow you to view the design in your chosen site design. (And will, of course, likely turn up a ton of other things that look wrong about it! Nature of the beast.)

As a side note, thank you to everyone who took the time to offer thoughtful, measured feedback, and especially to the people who took their brainstorming to the point of offering sketches or mockups! That sort of detailed feedback and brainstorming is a great help; even if we don't wind up using a particular idea, for one reason or another, it's always great to have such concrete things to work with.

This Week's Big Thing...

And, with that, we are on to This Week's Big Thing!

A few days ago, fu (who is totally my favorite person right now) committed the code for something that people have been asking about for a while: rename tokens. That's right, with the next code push (which, again, will be announced in dw_maintenance, and given how huge this is, will be announced here again) you'll be able to purchase a "rename token" that will let you change your Dreamwidth username.

I'll answer some questions about how the whole process will work that I think will come up, and then if there's anything I miss (or, okay, let's be honest, when there are things I miss), leave questions in the comments and one of us will try to get to you as quickly as possible.


How will it work?

You will be able to rename both personal journals and communities you control (ie, comms you're an admin of, even if you aren't the sole admin, so all comm admins will be able to rename the comm). To do this, you'll purchase a rename token from the Dreamwidth Shop. Rename tokens will cost $15 USD (150 Dreamwidth Points).

The token will be delivered to your account and 'held' there, so you won't have to perform the rename immediately; you can hold on to it for future use and not have to worry about losing the email in which the link to rename your journal was sent to you.

You'll then visit the rename page. If you have a token on your account, you can change your username right there. (Or, you can choose to 'work as' a community you admin if you want to rename it; tokens for comms go to the admin, not to the comm.) If you don't have a token already, there'll be a link to buy one and then continue the process.

Once you use the token, oldusername will become newusername. If 'newusername' was already registered, and you are renaming to it, the former contents of 'newusername' will become 'ex_newusername123' (where '123' is a random 3-digit number). You will still control that account, so if there were entries in it they won't be lost or deleted, just moved.

What options will there be while renaming?

Personal journals:

* will have the option to forward oldusername to newusername or break the connection. If the connection is broken, oldusername will be deleted and purged, so someone can use a rename token to rename to that account. If the connection is kept, anyone visiting oldusername.dreamwidth.org will be seamlessly redirected to newusername.dreamwidth.org.

* will have the option to clear out the list of people who subscribe to them or retain the list of people who subscribe to them. This means that if you choose to clear the list, anyone who has subscribed to oldusername will not be subscribed to newusername, and will have to subscribe to you again.

Communities:

* will have the option to forward oldusername to newusername or break the connection. If the connection is broken, oldusername will be deleted and purged, so someone can use a rename token to rename to that account. If the connection is kept, anyone visiting oldusername.dreamwidth.org will be seamlessly redirected to newusername.dreamwidth.org.

* will NOT have the option to clear out members, since this can be done through the community management pages.

What can I rename to?

You can rename your account to:

* an unregistered username

* a username that has been deleted and purged (not just deleted; it must say "this username has been deleted and purged" when you view the account)

* a registered username that you control, where both accounts have the same confirmed email addresses

You can't rename your account to:

* a username registered to someone who is not you

* a username that has been suspended, or an account that is in memorial or locked status

* a username that has only been deleted, not deleted and purged


You can rename personal journals to the username being used by a community you control, and vice versa, as long as you're an admin of the community.

What are the limitations to renames?

Let me put this in bold so that it's really really really clear: renames are not an effective way to 'disappear'. There are technical reasons for this, but short answer: After you rename, all comments and community entries you left under oldusername will be updated to display that they came from newusername. It's just plain not possible for us to change this without radically restructuring the way that DW works (on the order of "rewrite from the ground up", more or less), so if something happens in your life and you desperately need to 'hide' from someone, a rename is not a foolproof way of doing it, even if you choose not to forward oldusername to newusername. (Basically, comments and comm entries are stored in the database by userid, not username. When you change your username, your userid stays the same, so there's no real way for the system to know that 'userid 12345' used to be 'oldusername' but past a certain point is now 'newusername' in order to decide which username to display.) There's also no guarantee that someone wouldn't be able to go through your old relationships list and find your new username by 'triangulating': seeing what new name has popped up in common on all the profiles of the people you subscribe to/give access to.

A rename can be a good way to disappear from a casual acquaintance who found the direct link to your journal but don't know much about DW, but it will never be a way of completely disappearing from DW. If that becomes necessary for you (and I sincerely hope it doesn't), the only way to be sure is to create a brand new account that isn't connected to your old account. (And even then, people can still triangulate.) I want to be really clear about this, because otherwise people might get burned.

Renames should be used more for "I'm tired of my old username", not "I need to vanish"!

Why does it cost money?

On the whole, renames aren't a terribly good thing for the site. (They aren't awful, but they aren't harmless, either.) There are a lot of complex reasons for that, but it boils down to:

* It's confusing for people to load one username and be redirected to another.
* It takes processor power to do the rename.
* It can cause issues with 'moving' content around.
* It can lead to username squatting if people choose to redirect their journals.
* If people rename multiple times, with redirection, the 'chain' of former usernames can get very deep, and cause issues with the database and with display.

Because of all of this, we'd like to discourage people from renaming their journals every week or two to suit their current fancy! Charging a nominal fee lets people ask themselves if they really want to do it, while making it possible for people who really want to do it.

Having additional sources of revenue is also important for us, because I get nervous when we only really have one source of revenue (paid accounts). It's going to take us a few years before the 'bump' of income in April/May and October/November (from people who first paid for accounts on open-beta launch hitting the 6-month and 12-month renewals) evens out, and any other source of income that isn't periodic like that is a good thing for us. We're hoping that the revenue from renames (and vgifts, which is another project we're working on) will help even out some of those bumps. (This is not to say we're in financial trouble, not at all, but it's always, always good to diversify.)

Can I swap two usernames?

At immediate launch of renames, this probably won't be possible without a complex dodge involving three tokens (the way it works on LJ right now), but within the next few weeks, fu will be adding a way to swap two usernames (so that name1 becomes name2 and name2 becomes name1) with a single step involving two tokens. We'll announce it (and document it) when it becomes available.

Can I rename to a purged account?

Yes, you can. If an account has been deleted and purged, you can get a token and rename to it. Anyone can rename to the username of a purged account without controlling it.

The reason you can't just re-register the name without a token is because there were already comments and comm entries made by that username/userid combination. Journal entries are deleted when an account is deleted and purged, but comments in other places and community entries in other places aren't. Part of the rename process removes those old contents to another username (the 'ex_username123' form) with the same userid, freeing up the username for it to be associated with your userid. Basically, there needs to be an extra step involved in using a name that was already in use at some point, and that step is part of the rename process -- hence why those usernames are only available via rename and not by regular account creation.

?

I'm sure I'm forgetting something, but that's the basics of what I think people will want to know! If I've missed things (okay, since I've missed things), leave questions here. I will get to them later on today after I wake up. (Yes, I know it's 1330 in my time zone. I'm still up past my bedtime.)

(Also, huge thanks to cesy for writing up the first draft of the rename FAQs! They'll be added to the site when we launch renames, but I've cribbed heavily from them for this section.)

*

With that I shall bid you adieu! As always, if you're having problems with Dreamwidth, Support can help you; for notices of site problems and downtime, check the Twitter status page; if you've got an idea to make the site better, you can make a suggestion.

We'll see you next week for our next update. (Anyone betting on what day it will actually be posted will get the hairy eyeball. *G*)

Comments

[denise]

Yes, the same thing will happen here, and for the same reason that old comments will show the new username. The only way to prevent it is to prevent people from ever re-using account names (which we don't want to do); OpenID identifies a particular URL, not a particular person.

[sashajwolf]

That seems to me to be quite a security flaw. I'd thought better of Dreamwidth than to go ahead with something like this knowing of the flaw.

[denise]

We are looking into better ways to handle it, yes. The problem is that OpenID wasn't really designed for what people have started to use it for. There have been lots of discussions on how to improve the protocol to prevent that situation from happening, and we certainly can make changes as we come up with better solutions.

(The FAQs on renames, as drafted, also include a warning about this situation.)

[sashajwolf]

But you're going to go ahead with purges and rename tokens before a solution is found?

It's good that there's something in the FAQ on renames, for those who may want to buy a rename token, but the people who really need to be warned are the people giving access to DW OpenIDs on other sites, who are unlikely to read that FAQ. They may not read any DW FAQ at all, since they may not be DW users.

[denise]

Yes, we are, because:

* The biggest risk for our users arises from other sites recycling usernames that have been used to log into Dreamwidth via OpenID, not from Dreamwidth doing so. Even if we don't allow people to re-register a username that was deleted and purged, other sites do, and those OpenID accounts are the ones that DW users are likely to be interacting with. So, the biggest risk for our users comes independent of our actions, and our actions don't mitigate that risk at all.

* The problem is fairly widespread -- the vast majority of services out there recycle usernames or logins in some fashion, which can lead to all sorts of problems on other sites. (For instance, when I was with LJ, a common cause of accounts being broken into was people having used an email address from a provider that removes accounts for inactivity and then recycles the username; someone would sign up for the released account, then request a password reset and gain control of the account.) While I'm not saying that "everyone else is doing it" is any reason to be doing things, nor is it a reason not to find a better way to do things, it is something that people should be aware of in general as a risk; it isn't unique to DW.

* The problem affects a really small number of accounts at the moment; the number of accounts that have been deleted and purged on Dreamwidth right now is tiny. (I don't have an exact number, but I'd be really surprised it it were even into the low four figures.) Statistically, the chance of someone renaming to an account that had been used for an OpenID login elsewhere and finding the site that login had been used on is really low right now, which means we still have time to solve the problem.

And when I say "time to solve the problem" and "looking into better ways to handle", I don't mean "do something to fix this next year", I mean "may even change by the time renames go live on the main site". There are ways to work around the limitations in the OpenID protocol, and it is fu's primary project right now; fixing it will involve changing our implementation of OpenID, though, not anything to do with the rename system or how renames are implemented.

Still, even once we do make those changes, as you point out it only benefits people on other sites who have some sort of relationship with an account on Dreamwidth; it doesn't fix the problem for people on Dreamwidth who have given access to someone's OpenID from elsewhere. The only thing we can affect for our users is the following scenario:

1) Someone has used their DW URL to log into another site with OpenID;
2) That person renames to a new DW username and chooses not to forward their old username.
3) Someone renames to that username;
4) That person logs in to the same site with OpenID.

That's the scenario we warn about in the draft of the rename FAQ. For the other-way-around scenario, in which other sites recycle usernames that someone on DW has granted access to, I've added more of a warning to FAQ 54 for people who weren't already aware of the problem.

[sashajwolf]

... and also, I think it's either thoughtless or disingenuous in DW staff to say that OpenID wasn't really designed for what people have started to use it for; DW's cross-site functionality has done more than most to encourage that use, particularly through the import function.

It is not a trust system

[daweaver]

OpenID identifies a particular URL, not a particular person.

A cursory reading of the specification says that this was always the case. OPENID is designed to demonstrate that a particular person (or a browser session) can generate a particular response from a particular URI at a particular point in time. Nothing more. It is not a trust system, as Bradley Fitzpatrick pointed out when he first publicised the technique.

The problem is that OpenID wasn't really designed for what people have started to use it for.

OPENID is not a trust system. It is simply wrong to assume - as Dreamwidth does - that the same person will be able to make the same assertion at any point in the future. Or that the person who made that assertion in the past is the same person who is making it now. OPENID far more weak, time-dependent, and trivial than appears to be generally understood. OPENID is not a trust system, yet Dreamwidth encourages its customers to treat it as a trust system.

Given that OPENID is not a trust system, and staff are aware that the current implementation is broken, would Dreamwidth benefit from disabling the OPENID logon until such time as it can be fixed, which may be by ripping it up and starting afresh? Or by giving customers the option to treat all OPENID logons as equivalent to anonymous? And/or by giving customers the option to disable the outbound OPENID from Dreamwidth without messing about in the stylesheets?

Re: It is not a trust system

[chris]

The following may be the most negatively critical comment I have made about Dreamwidth yet.

I am disappointed that nobody on the staff has replied to three or four related comments and left this unresolved matter hanging open for over 72 hours. (This is absolutely not personal; I know that denise has had house issues, jury duty issues and more.) While I know that you are all busy with development as well as administration, I believe that Dreamwidth prides itself on the availability and responsiveness of its staff as part of its commitment to open operations. I don't think anybody wants you to spend all your time responding to comments on news threads, particularly when just one person is hogging undue attention, but when at least four different commenters have related, but unaddressed, concerns, then it represents a level of service less than we might have hoped for - and, to my dishonour and discredit, less than the level I have claimed that the staff provide. This isn't Dreamwidth at its best.

I know you are, among all the many other excellent development plans for the future, working on ways to work within the OpenID spec to improve the process, and I welcome that. However, the implementation as it is at the moment is something that you (denise in particular, here) have already criticised. The other commentators are much more specific about this and are probably worth more attention than this comment, but when the current implementation is so flawed, even though you may be implementing it as well as it is implemented anywhere, why have you prioritised other developments above resolving these serious flaws? If these serious flaws cannot be designed out of the system as it stands, why use OpenID at all without publicising its risks and drawbacks more visibly than happens at the moment?

Re: It is not a trust system

[cesy]

I'm sure someone will respond to this officially soon, but I have noticed that in Bugzilla, fu has already been working on using token-fragment-things so that the security issue is avoided. As I understand it (and I don't, really, which is why I didn't comment before), this will mean that when you rename, your old OpenID is somehow disabled, and a new user using your old name gets a different OpenID, even though it looks like the same address, so they wouldn't actually be able to access your accounts on other sites.

Re: It is not a trust system

[chris]

Thank you for the response, which does sound encouraging, but my concern is more about OpenID in general rather than risks that have come to prominence as a result of these renaming-focused discussions.

Re: It is not a trust system

[denise]

There is nothing more that I can say. I've already explained to people that the number of people this would effect would be tiny, any changes we'd make would only help people on other sites and not people on DW, and we are already working on a fix. I'm not sure what else I'm supposed to do, other than rend my garments and beat my breast.

Edit: I'm sorry, that was undeservedly snarky of me (I should not answer comments when I've first woken up). Still, I really don't see what else I could possibly do, and when I feel there's nothing else I can contribute in a reply to a comment, I simply don't reply to the comment.

Re: It is not a trust system

[chris]

No problem! You weren't particularly snarky first time, but I have left this response to see the cold hard light of day, counted to ten and let my thoughts percolate while I was at work. My concern relates to the use of the OpenID system in general, rather than specifically to the new potential risks that have come to light as the result of discussions concerning renaming.

Given that OpenID is not a trust system, as you've said, and that it's being used in ways that it wasn't designed for, why does Dreamwidth take the decision to continue to use OpenID as a trust system without prominent warning of the risks, rather than to rip it out and possibly re-implement it in a fashion that both (a) educates users about and (b) reduces the risks arising from these pitfalls?

Re: It is not a trust system

[denise]

There really wasn't anything better, is the problem. There still isn't, unless we're willing to support closed systems like Facebook Connect or Windows Live ID, which isn't really a great idea. OpenID isn't perfect, but it's better than most options, has the benefits of being easy to implement and easy to maintain, is widely adopted, and already has ongoing dialog about how to best extend the protocol to alleviate the problems that have been identified with it.

The risks inherent to OpenID are much the same as the risks inherent to using the internet -- anyone's account can be hijacked, anyone can use a service that recycles usernames, anyone can share an account login with a significant other. (Anyone can share an account login with a SO they then break up with, who takes all their data and all the friends' data they have access to and smears it all over the internet. In the six years I worked for LJ, this happened approximately four orders of magnitude more often than someone having a privacy violation traceable back to the use of OpenID.) In my measured and professional opinion, the risk associated with the use of OpenID is (less than) negligible, and spending more than a minor amount of time on mitigating those risks is a poor use of time. Some risks are inherent to life on the internet, and this really is one of them.

I have put a warning on OpenID recycling in the FAQ on granting access to people, and fu is working on adopting identifier fragments for renamed accounts' OpenIDs. Anything more than that is bad return on investment.

(And thanks for accepting the apology. I'm at the point where I'm frustrated by the discussion, because it doesn't seem to be doing anything other than retreading the same ground and as I said the risks are negligible, but I really shouldn't have taken it out on you and I promise to caffeinate and count to ten before replying to comments in the future.)

Re: It is not a trust system

[daweaver]

In my measured and professional opinion, the risk associated with the use of OpenID is (less than) negligible

That is your opinion, it is clearly derived from evidence, and I respect your right to hold it. I happen not to share it, for reasons briefly explained upthread.

At heart, this is all about risk perception. I perceive OPENID as weak and making trivial claims, the potential gains are easily outweighed by the risk of misidentification, so the technology is simply not worth bothering with. Other people perceive it as unreliable, in many and various ways, and have different responses to their view of the risks.

This whole thread has demonstrated that there is a wide diversity of opinion on this matter, yet Dreamwidth as an organisation does not appear to acknowledge this. There seems to be a one-size-fits-all policy when it comes to measuring this risk, and if one person's perception of risk applies to all then those of us with reservations about this method are liable to feel marginalised. I find myself wondering how this squares with Dreamwidth's much-advertised claims to honour and cherish diversity?

Re: It is not a trust system

[denise]

If you disagree with DW's policy on dealing with OpenID, the solution is to either not use DW or not use OpenID on DW. It's entirely possible to interact with DW and never touch OpenID.

Using any service that you did not create yourself and that you don't have the final decisionmaking power on entails the chance you will not agree with the decisions that service makes; that's part of delegating your decisionmaking ability to the people operating that service. At the point where your decisionmaking and the service's diverges so wildly that you are unhappy with every or nearly every decision that is being made, you can leave and either start your own version (that's what we did when LJ annoyed us enough) or find another service that makes decisions differently.

Every social networking site on the internet of any size supports and uses OpenID, however, so you may need to begin your own in order to find one that doesn't.

If you feel marginalized based on your beliefs about technology conflicting with the decisions made by others about technology, I am very sorry. (That isn't sarcasm; I truly am.) However, making decisions about technology is the role of the owners and operators of a particular site and/or network.

I don't think we are going to ever see eye-to-eye about this, and so I am going to have to bow out of this discussion, since I don't see it going anywhere useful.

Re: It is not a trust system

[daweaver]

Right. I've gone away, counted to a really *really* large number, and have things to say in the spirit of constructive criticism. There is a middle ground between the options presented at the start of the contribution above: persuading Dreamwidth to alter its policy through force of argument and consideration of alternative methods.

For starters, why OPENID and not OAUTH? Being the slightly sad person that I am, I've read through both specificiations, and I'm struggling to find an obvious problem with OAUTH. That's not to say that it's perfect, but it's far less obviously wrong than OPENID. There must be a good reason why Dreamwidth preferred to go with the trivial assertions of OPENID, and I very much hope that the reasoning wasn't "it came with the Livejournal code we started with, and we always wanted to snaffle Livejournal's paying customers first."

To the best of my knowledge, there are many social networks that do not accept OPENID logons. I may be wrong in some of the specifics, but I see no evidence that Hyves accepts this logon method, nor does LastFM, Spotify, Vampirefreaks, Deviantart, Librarything... there is a significant list.

I understood from its advertising that Dreamwidth welcomed contributions from its customers, and would be more accountable than Livejournal in the Six Apart era. That I got the familiar "this is our server, if you don't like it, the doors are there" feeling was doubtless unintentional, but no less real.

Here's another idea. Change the core functions to make it easier to remove an outgoing OPENID claim from styles. Simply break the print_head function into its component parts - print_head_doctype, print_head_rss, print_head_javascript, print_head_stylesheets, print_head_openid, and probably some that I've forgotten. Not only would this allow additional granularity for developers and staff, but would also allow people to specify a preferred OPENID server, or deliberately exclude Javascript calls from certain styles, or whatever. For backwards compatibility, the existing print_head simply calls the various components. This would not be difficult, and it would over time enhance the diversity of the site.

Those are reflections offered in the spirit of constructive criticism.

Re: It is not a trust system

[cesy]

Why not put these through suggestions, and then someone might change it? I'd love to see OAUTH functionality added.

[pseudomonas]

"OpenID identifies a particular URL, not a particular person."

Yes, this is technically true, but I don't feel that this is what is being communicated to users. The "Manage Circle" interface, to give the first place I looked, puts OpenIDs together with DW accounts under the heading "people". The way OpenID is *being used* by the likes of Dreamwidth makes it imperative that acquiring someone else's URL is not a likely occurrence.

[bens_dad]

I am sorry, but *any* identity scheme intended for individual humans is incompatible with the idea of re-using account names.

The only way to prevent it is to prevent people from ever re-using account names (which we don't want to do);

I believe that you can have OpenID or re-use account names,
but not both. If DW follows LJ in this I am seriously concerned that OpenID is dead.

I'm also now much less likely to get around to getting a paid account because of this.

[fu]

(Sorry, commented with the wrong account!)

If I may: OpenID 2.0 provides for identifier recycling with the use of a unique fragment: http://openid.net/specs/openid-authentication-2_0.html#identifying

Basically, to the user, they don't need to know/care about the fragment; they should just be able to log in using their username.provider.com. However, (if there is a fragment provided) both the server and the consumer authenticate against the URL + the fragment.

[bens_dad]

Thanks.

I look forward to seeing this in action.

There will of course need to be an easy way to discover the fragment of another user. In a world where LJ allows LJ users to "friend" DW users they will need to be able to include the fragment as well as the base URL in the name of the account they friend.

[denise]

As Afuna said, we're working on ways to work within the OpenID spec to improve the process. Account recycling is an issue just about anywhere, though -- for example, while I was working at LJ, a frequent issue was people's accounts being broken into because they had initially registered with an email address from a provider that closes accounts for inactivity and recycles the username. The only way to completely prevent it is, as you say, not allowing usernames to be reused -- but then you have the problem of namespace exhaustion.

There is no good answer that solves 100% of the problems involved, so we're doing all that we can to minimize the risks and documenting the risks that remain.

[bens_dad]

Namespace *exhaustion* is a long way off and very unlikely to happen before DW has gone out of fashion and come back in, assuming that it lasts that long. It is far more likely that namespace exhaustion will be avoided by changing the dreamwidth part in a human generation or two.

Desire for reuse of popular names is a more realistic issue, but for me any service provider who puts that above the long term security of identity looses a lot of credibility and warm fuzzy feeling.