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.

[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.

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.

[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)

[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.

[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.

[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.

[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?

[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.

[florentinescot]

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.

nods. This happened to me. I had a few friends that couldn't comment here because of some sort of glitch and they weren't "validated" (or whatever the word is). I had my access set to "access list," and even though their LJ ID was in my list, they still couldn't comment because for some obscure reason they weren't validated.

[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.

[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.

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).

[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.

[foxfirefey]

So, I think there's a big technical reason not to do this, and that is:

I, personally, want to start moving towards a system where an OpenID is something that is attached to an account, whether identify or full. So that you can, say, attach your LiveJournal to your Dreamwidth officially. Or whatever.

In that case, do we block somebody who has an OpenID from that particular domain attached to their account, even if they're fully registered users? Or how much sense does it make to block OpenIDs from one domain if they can just add another one to their account?

[azurelunatic]

Hmm.

Block an identity account if it only has OpenIDs from locations on the user's blacklist, and no grey or white.
Screen an identity account if it has a mix of OpenIDs.
Screen a user account if it has any blacklisted.

[thorfinn]

This sounds like the sort of edge case problem that isn't worth accounting for. If someone is commenting with a DW account, then they're a DW account, regardless of what information is attached to that account.

[azurelunatic]

(Coming back to this after more thought, and related discussion elsewhere) The potential that it's a legitimate user increases the more the person has web presence elsewhere. I am unsurprised when any singular OpenID account is a spammer; I would be unsurprised to find out that a spamlord had presence on any 10 sites. And the next bit is a bit nebulous in my head -- yes, once spamlords figure this out, they're going to exploit it -- but it's entirely natural for a legitimate user who's got presence on a number of sites to want to set them all up when setting up an account, particularly if the account creation logic encourages them to. Where are you elsewhere, who are you there? Oh, I'm so and so on Twitter, so and so on IJ, and -- oh my, you have a slot for MySpace?! uh, I suppose I am so and so there, hee, I haven't used that in forever. So more than one OpenID on an account that's still solely an identity account, would itself be at least a temporary indicator that the person is less likely to be a spammer.

So at least for the moment, there should be a greater degree of systemic trust that someone with multiple OpenIDs and a legit email address (possible refinement: require validation before allowing advancement to the next level of systemic trust that's granted by multiply sourced OpenIDs on an identity-only account) is likely to not be a spammer.

So there are more user concerns than just spam; the others are likely to be harassment and ... embarrassment? exposure? Exposure is probably the best word for the concept.

Harassment is a thing that I don't have enough systemic information on to speak with my usual assurance. Also this is going to get exceptionally rambly. But from what I've heard, it seems often enough to involve individuals (or hordes) targeting individuals, either selected singly, selected singly because of previous conflict, or selected as a member of a target group. So as a target of harassment, anonymous comments tend to be a bad idea to start with. [Digression: In the case of a conflict between two parties where they're both sick of each other, mutual ban and mutual killfile (are we getting killfile? would be nice!) is probably the best way for them to keep separated from each other.] In case of a ban, it makes sense to assume that the person who has banned the account does not want contact from the individual who owns the account (and I think this is a safe assumption to make on a systemic level because while it would be merely irritating to have banned someone by accident that you meant to talk to just not under that identity, it could be actually bad to still allow contact from someone you really meant to ban).

I think that the thing where identity accounts can be referred to by their OpenID URL is possibly misleading, if there's going to be a system where an identity account can pick up multiple identities and somehow not become a full account. If you ban something by its OpenID, you should be banning the whole account. And how do you name an identity-only account, if not by the ext_ name, if what you mean is "the identity account that holds the OpenID ___________, and by extension any of its other identities"? Which sounds like it could cause a problem if you can add an OpenID to an identity account, and then set security on who sees that you have this OpenID. That sounds like it would bring a user's expectation of privacy on a secured item, and a user's expectation that they can ban an account by information sufficient to identify the account, into conflict, through the systemic expectation that you can identify an identity account through its OpenID URL. And I don't know how that can be solved except to either say that if you've actually hooked up an account and verified it as an OpenID and not just listed it, that it can't be hidden, or to ... I dunno. Only hide OpenID connections in case of a full account, but anyone who has a previously existing ban on the account sees that there's been a namechange?

And this leads me to another realization: 'ban' and 'block' are very distinct concepts. So presence of an OpenID from a blocked source doesn't necessarily imply that the whole account should be disallowed from contact, whereas presence of a banned element should mean that the whole thing is banned.

[daweaver]

At the risk of coming across as a broken record, OPENID is not a trust system. It makes a trivial assertion at a particular instant in time, and that assertion naturally times out when the associated DNS record expires, in no more than 30 minutes. If people wish to ignore the large warning posted to OPENID when it was first publicised, then that is a decision that each individual should make.

That said, I think it would be tremendously confusing for individual customers to determine that they will accept OPENID logons from provider X, but not from provider Y. Either people believe that OPENID can be a proxy trust system, or they do not. If customers wish to allow OPENID commenting, then there is little difference between providers. I cannot, therefore, support the suggestion as it stands.

Personally, and at the risk of introducing scope creep, I think there should be an additional setting: to treat all OPENID accounts as anonymous, even if previously passing an email check, unless specifically on the Access list. Given the settled opinion of the Suggestions Gatekeeper, I have no doubt that this will not be implemented.

[thorfinn]

I disagree with your assertion that there is no difference in openid ( or other auth system ) providers. For example, OpenID itself has support for the provider to inform you if the URL owner has changed... Most sites don't use that - yet, but the capability is there.

Different sites also have vastly different identification requirements and identity tracking, which matters. In fact, I am inclined to trust a facebook connect ID to be identifiable to a real person in the case of trouble, but not so for LJ openID.

Yes, it's potentially confusing for people to wonder about all these different providers, which is why there should be good default sets, e.g. All openID, no openID, only openID 3.0, etc.

[fizzyblogic]

I like this, particularly the error message. Suggesting a different OpenID site seems like a polite but firm way of saying "I don't want comments from that site, but I would quite like your comment so try another way".

[vanessagalore]

I agree.