User-level control for allowed OpenID/other external identity provider sources

[azurelunatic]

Title:
User-level control for allowed OpenID/other external identity provider sources

Area:
comments, OpenID, interoperability

Summary:
Occasionally there is an external identity provider that makes any given user want to flee screaming; might be useful to allow that user to deny comments from external users from that source. Like, say, Facebook.

Description:
Dreamwidth doesn't (yet) have Facebook integration, but LiveJournal does. The future of the web seems to be going in an "everybody talks to everybody" sort of direction. The word on the street is that Facebook Connect is eventually going to be converted into OpenID 3.0, and eventually Dreamwidth will wind up with OpenID 3.0, and then the matter of "Will Dreamwidth really really allow Facebook users (with the site's policy about legal names and the related high potential for privacy shenanigans) to comment in my (likely pseudonymous) journal?!?" will be moot.

With Dreamwidth's commitment to openness, it would not make sense for Dreamwidth as a whole to deny users from any one given site the chance to log in and play along, unless that source were a complete pit from whence only spam and blatantly-illegal-in-the-US material emerged.

However, Dreamwidth also has a thing about control; would it make sense for Dreamwidth to allow users to create either a blacklist or a whitelist (or both, with any not specified screened before display) of external ID providers?

One can, of course, already add any given user to one's Circle; presence on someone's access list ought to exempt commenters in personal journals from certain anti-spam, anti-abuse control measures if it doesn't already. One can ban any given user. However, if one wants to exclude one entire broad class of offsite users, one has to bring out the laser cannon to use as a flyswatter, and deny commenting to all but those on the access list. This is easy to explain to someone who's just tried to comment but can't (user only allows comments from this specific list of registered users), but not necessarily fair to the journal owner if they would like to have more permissive comment settings but for whatever reason do not want comments from that source. (I so often see these things framed as "not fair to the people who would like to comment but can't", but I'm tired of that argument.)

It would mean telling users who tried to comment "You cannot comment to $USER's journal because $USER does not allow comments from $LOCATION OpenID accounts (here's how to get a real account, or you can try another OpenID provider)", which is not really friendly. It would mean disallowing a broad class of identified people based on the site they choose to come from. But it would also mean more control for journal owners in their own space.

Poll #4519 User-level control for allowed OpenID/other external identity provider sources

Open to: Registered Users, detailed results viewable to: All, participants: 74

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
31 (41.9%)

Should be implemented with changes. (please comment)
3 (4.1%)

Shouldn't be implemented.
25 (33.8%)

(I have no opinion)
14 (18.9%)

(Other: please comment)
1 (1.4%)

Comments

[cesy]

I'm not keen on this, mainly for the reasons you already touched on - if you only want people you know or trust, the tool for only allowing access list is already there. I don't actually understand the use-case for blocking validated OpenID users for an entire site just because of where they come from. The only exception would be if OpenID 3.0 contained privacy holes in the specification, in which case Dreamwidth presumably wouldn't implement it anyway.

[andrewducker]

Agreed. If you're allowing anonymous users then it makes no sense to ban people from particular domains.

If you're allowing OpenID users that you don't have trusted, then you're effectively allowing anyone to comment anyway.

The only option that would make sense here would be whitelisting, and this can already be done, through the Trust system.

[charmian]

If it simply directs users to use another openID login, I'm not really sure what problem it solves, because they'll just use another login and do it. Also, I wonder if, in this future where FB becomes openID3 (whenever this occurs), whether DW will still be using invite codes. Otherwise, this could end up looking to unsavvy webusers who do not really understand openID like DW is trying to demand money from them to comment. (as registration is not open)

[ninetydegrees]

+1

[aedifica]

I don't actually understand the use-case for blocking validated OpenID users for an entire site just because of where they come from.

Me either. If I'm going to be commenting on someone's journal without using a Dreamwidth account, what difference does it make if I use my LJ OpenID or my Facebook? In neither case does the other site get access to my comment or your post.

[the_shoshanna]

Agreed. If you're allowing anonymous users then it makes no sense to ban people from particular domains.

This.

[melannen]

I like this idea - to me, it's basically an matter of site cultures. If a website has a similar culture around identity as DW (or my part of DW) does, I would allow its openIDs; if a site doesn't use identity the same way as my part of the internet, I would like to not let it use openids.

This causes the same issue a lot of people are scared by in the LJ/FB integration - if a lot of $legalname peope are posting in my journal, with openids that presumbly link back to a facebook/linkedin/etc page full of other $legalnames, it makes it much more trivial to find my $legalname and other things I wouldn't necessarily want to be trivially linked to by dw. Whereas if they have to comment anon, they might still choose to sign a legal name, but are much less likely to link to a page full of other legal names and photos etc; and if they use an openID from a site that's based on pseuds, I don't care.

Some people wouldn't care, so let them allow, but it would be nice to choose on a fine-grain level for my journal. (I don't, for example, care about FB, but linkedin gives me the willies.)

[matgb]

I want to actively promote the site to off site friends. The way LJ has integrated Facebook login and the ability to upgrade to a real account is actually really nice, and I'd like to see similar here.

So if we implement similar, which would be good for the site, how would it prevent people from logging in, like the site, buidling up a circle, then finding they can't comment somewhere so grabbing an invite and upgrading?

I don't want the site so say "we'll treat you just like a full user" and then say "except some users don't want to treat you like a real user, get a proper account", goes against the spirit of interop.

If you want to block people from commenting, then use the access restrictions available. If I manage to persuade friends from, say, Facebook, to sign up, join in, enjoy the site enough to go out and find other things to read, then find themselves excluded from some comms and journals due to some effectively spurious concern, it's wrong to me.

If you don't want a specific individual commenting, you can ban that individual, if you only want a subset of people commenting, you can grant access to commenters. But excluding an entire class of users just because of what site they've used as an identity provider is blunt instrument collective punishment, and it goes against what I want from the site.

[musyc]

I like this suggestion, and I'm sort of on the same page as melannen with it regarding site cultures, though I'm more about behavior than specifically identity. I might be fine with someone using an openID from a site such as Blogspot or Google or the New York Times, but hell if I want someone from 4chan, SomethingAwful, or Dramatica to be able to comment or send me PMs under that particular persona. Etiquette and allowed acceptable behavior are far different.

[turlough]

I can see both the pros and cons of this and I can't really decide which I think are more valid.

[azurelunatic]

Ah, yeah, I was sort of picturing this as a level of comment control that did not allow anonymous users.

[arethinn]

Related - I wish that OpenID users (mostly, coming from LJ) weren't counted as anonymous (for purposes of being allowed or not allowed to comment) unless they've "claimed" the ID here on DW and registered an email address. It defeats the purpose of putting in my crosspost footer, "Please comment on my DW account!" if they can't do so without that considerable extra step. I got spam comments within days of setting my comment permission to "everybody" and I don't particularly wish to allow truly anonymous comments - but at the moment, that's my only option if I want (most) LJ OpenID people to be able to comment. I understand not wanting OpenID to be a "registered account" in the sense of a DW account, but it should be better than anonymous - isn't that the whole point of OpenID?

[azurelunatic]

The difference is the content at the linkback. In the case of Facebook users, that content is likely to include a social web of people using their legal names, because Facebook requires legal names.

[matgb]

I wish that OpenID users (mostly, coming from LJ) weren't counted as anonymous (for purposes of being allowed or not allowed to comment) unless they've "claimed" the ID here on DW and registered an email address

My response to that is actually to substantially improve the OpenID UX so that validating is easy and painless, treating them as anon makes sense in a number of ways given that an OPenID is so easy to get hold of it can be automated by bots.

Essentially, if you allow this, your spam problem will increase.

I got spam comments within days of setting my comment permission to "everybody" and I don't particularly wish to allow truly anonymous comments

FWIW, I'm set to fully open, and the only spam I can recall deleting from DW has come from logged in bot accounts. I understand the latter desire (it's not for me for now, and definitely not before the above UX stuff is done), and that's a different thing, but allowing anon comments shouldn't increase spam that much as there's, reportedly, very little of it hitting the site.

Virtually all the spam I get on LJ is from logged in accounts as well.

We definitely need to improve the UI and UX for OpenID, but doing as you suggest would be counter productive, as OpenID will come to mean 'spammer' for a lot of users :-(

[azurelunatic]

I'm not sure whether there already is a suggestion or bug to make OpenID with unregistered email address separate from anonymous or not; I suspect there might be.

For what it's worth, this is inherited behavior, which was itself a step up from the old treatment of all OpenID with anonymous.

[matgb]

Facebook requires legal names.

Actually, it doesn't. It used to, but they changed that a few years ago and removed the clause. Facebook (2) | Statement of Rights and Responsibilities:

# Registration and Account Security

Facebook users provide their real names and information, and we need your help to keep it that way. Here are some commitments you make to us relating to registering and maintaining the security of your account:

1. You will not provide any false personal information on Facebook, or create an account for anyone other than yourself without permission.
2. You will not create more than one personal profile.
3. If we disable your account, you will not create another one without our permission.
4. You will not use your personal profile for your own commercial gain (such as selling your status update to an advertiser).
5. You will not use Facebook if you are under 13.
6. You will not use Facebook if you are a convicted sex offender.
7. You will keep your contact information accurate and up-to-date.
8. You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
9. You will not transfer your account (including any page or application you administer) to anyone without first getting our written permission.
10. If you select a username for your account we reserve the right to remove or reclaim it if we believe appropriate (such as when a trademark owner complains about a username that does not closely relate to a user's actual name).

It was clarified, and I can't recall where that "real name" does not have to mean "legal name", although they may be backtracking a little bit. Interestingly, I found this:

# Special Provisions Applicable to Share Links

If you include our Share Link button on your website, the following additional terms apply to you:

1. We give you permission to use Facebook's Share Link button so that users can post links or content from your website on Facebook.
2. You give us permission to use and allow others to use such links and content on Facebook.
3. You will not place a Share Link button on any page containing content that would violate this Statement if posted on Facebook.

I think, but am not sure, that posting links to locked content violates their privacy policy, so LJ may be in breach. IANAL though...

[zvi]

we typically oppose security by obscurity measures, and this is the same. Most people on the internet already have multiple OpenID providers. If you get slashdotted and ban slashdot, people will just switch over to their google openids or aol open ids or yahoo openids or the openids on their own servers.

[trixieleitz]

I think I saw this idea discussed as a way of dealing with a (hypothetical) situation where accounts with a specific OpenID provider are being used exclusively for spam or harassment. I suppose that in that situation, it might be worth blocking that provider site-wide.

[azurelunatic]

As your senator from the Antispam State, I can say that happily, I do not at this time know of any OpenID providers that are solely sources of chaos/panic/disruption, which (sadly) means that if the capability to ban sitewide by OpenID source existed, it would sit idling, unable to be deployed as it would affect legitimate users.

[thorfinn]

I think the idea is that this suggestion promotes diversity - you can set your journal and communities you own to allow all types of open ID, whilst others who are more leery of specific sites can disallow those in their journals and spaces.

I think, in fact, having this suggestion is likely to strongly increase the chance of being able to introduce FB Connect, and other identification systems, simply because then individuals can choose to opt in or not, rather than having it be a site wide blanket decision.

Diversity...

[thorfinn]

It's a diversity of choice use case, and there often is a genuine "site culture" difference.

People *are* leery of certain OpenID providers and not others, and might choose to allow specific openID providers over others.

I would like that to be an individual decision rather than site wide, partly because that increases the chances that we can actually have those other identity providers.

If people don't have to automatically accept all OpenID or all alternate identity providers, then there's much much less concern about introducing those identity providers.

Dreamwidth then doesn't have to make a site-wide choice - it can be left to individuals to trust or not trust those third party ID providers in certain ways.

[thorfinn]

But one might choose *not* to allow anonymous users, and then also choose specific OpenID providers to allow, or open ID blanketly, or FB Connect specifically, etc.

[thorfinn]

I'm more fond of the idea that one might want to opt in to specific OpenID providers, rather than blacklist specific providers.

This should support both, though.

Re: Diversity...

[azurelunatic]

And (I just remembered that I was supposed to make a suggestion about this) if this is integrated with the OpenID source picker menu, if it is implemented, then if there are common OpenID sources that a given journal owner does not accept, those sources could be shown-inactive rather than shown as options.

Devil's advocate....

[kyrielle]

But the case cited where it links back to real names (without the OpenId user actually seeking to link to real names) might apply - someone who is trying to keep a privacy wall to their real/legal name might want to ban services that use or strongly encourage such names, since it could be a privacy breach for them if their friends or family commented from those OpenId accounts.

And, by the same token, the 'culture' argument of not wanting to provide link-back to an account on 4chan or whatever (if they used OpenId from that site) also applies.

It doesn't stop the people from commenting. It doesn't even stop them from being obnoxious where culture differs. But it does mean that if they want a link-back to their account on the blocked site they'll have to add it manually, and it does mean that people who don't won't accidentally auto-link back to an account on a site you don't want to be associated with.

Having said that, I'd LOVE OpenId integration with Facebook in the future, as then some of my family might comment who can't currently. I'm not very likely to use this feature, but I do see its utility. Maybe just the ability to ban '*.facebook.com' or the like rather than an individual user.

If it's done, though, I think the FAQ for it should be as crystal clear as it can be that this is not a security measure, but a marginal privacy measure that only prevents accidental linkage (although, if you also screen OpenId comments that contain links, it would be a fairly strong marginal privacy measure).