?

Log in

No account? Create an account
Previous Entry Share Next Entry
Identities vs. Users
querki
jducoeur
I am often scathing in my opinions about how badly the major social networks deal with issues of Identity -- in particular, their stupidly coarse-grained view of the world, which often ignores the fact that many people would like to be able to easily use multiple distinct online identities. (Work vs. Home vs. Play vs. Kink, etc.)

That said, the Querki project is reminding me that doing this stuff right is pretty hard. Consistently distinguishing between a User (an actual, real-life person, accessing Querki on their desktop or phone), and a potentially unlimited number of distinct Identities for each of them, requires constant, careful thought. Doing it *well*, so that Identities don't "leak", is especially tricky.

Mind, I'm not promising HIPAA-grade protections at this point, much less life-and-death security: it's infeasible for me to do that level of security auditing any time in the next year or two. But that *is* the long-term goal. I should be able to have a Facebook account, multiple Google profiles, an LDAP profile from work, a Twitter account, a native Querki login, an LJ login, and so on, all connected to the same Querki account, and I should be able to easily say that certain of those accounts aren't visibly the same person.

(Why? Because I'm trying to not build Yet Another Bloody Social Network. I would like folks to be able to use their existing flists from the social networks inside Querki, and have it Just Work. But that requires dealing with the fact that those flists aren't necessarily fungible: I might well be trying to keep them distinct. Querki should facilitate that, insofar as we can.)

The problem pervades almost everything. Take my current project, for a typical example: implementing Notifications. The trick here is that a Notification (a System Message, a Personal Message, a Space Change Notification, whatever) is sent from an Identity to another Identity, but is actually *delivered* to a User. That is, I should be able to easily see all of the new Notifications from all of my Spaces, regardless of which Identity I am using in any given Space. And when I reply to one, it should automatically come from the appropriate Identity, without me needing to think about it manually.

(Yes, there are nasty edge cases if I want to have multiple distinct Identities within the same Space. For the moment, I'm simply not allowing that -- it opens up all *sorts* of sock-puppeting abuses, and needs to be thought through very carefully.)

I don't think I actually know any service that has ever actually tried to do this right, although it wouldn't surprise me if a few exist. Making it usable is going to be a heck of a project. Mind, I'm not tackling the thorny UI issues yet -- so far, we only have the native Querki logins, and we don't yet have the ability to link those together. But if I'm ever to have the slightest hope of accomplishing this, I have to get the data structures and communication right, and if we're not going to have accidental breaches the system has to play completely fair internally: the knowledge of how Identities relate to Users is tightly controlled internally, and most subsystems don't have direct access to it.

It's a fascinating project, and it does give me a *little* sympathy to the social network companies. It doesn't require malice to not want to deal with this -- the simple truth is that, if you don't build it in from the beginning, with a crisp distinction between your concepts, it's probably nearly impossible to do it well...

  • 1
One thing that would be awesome is if there was a way for a single User to be operable by multiple Identities. For example, a User that is my company's forward face that can/will be accessed by multiple members of my PR team, all of which can see the entire history of that User's interactions with the outside world.

Hmm -- I hadn't thought of it in *quite* those terms, but it's a good point. We certainly will need the concept of "virtual Users", for small business and organizational purposes; that is, we need the ability for a Space to be owned by an organization rather than an individual. That's been in the plans forever, but I haven't really dug into exactly what that means from an Identity POV.

I'm not sure that the end result is going to be quite what you're describing here, but you're certainly correct about the problem -- we need multiple actual people to be able to collaborate as a corporate "User". I'll have to chew on how best to make that work. Thanks!

Hmm - I'd thought that having multiple Identities was a little less seamless than you're apparently making it - that you'd be acting as a single Identity at any particular time, with changing between them being an explicit action (via dropdown or somesuch).

It sounds like you're pursuing more aggressive integration than that?

Ideally, yes, but we'll see what's actually feasible. My stake in the ground is that Membership in a Space is by Identity, so if I'm operating within the context of a given Space, the system can (and probably should) automatically switch me to that Identity -- frankly, anything else is likely to be inconvenient at best, and at worst will probably often lead to Identity leakage due to mistakes. This change should be *visible* to the User (your "Logged In" at the upper right should indicate your current Identity in some fashion), but probably automatic.

There's a long ways to go before that -- among other things, I need to get better solutions to the "what does this look like to other Members?" problem that you've been handling with test accounts. But it's the long-term plan...

...so if I'm operating within the context of a given Space, the system can (and probably should) automatically switch me to that Identity

It seems like that could also lead to identity leakage - not on a technical level but on a workflow / user level.

If I'm working as Identity X (in which I am open about facts A, B, and C about myself), then switch windows / click a link to go to another space where I'm auto-shifted to Identity Y (in which I am open about facts C, D, and E about myself), if I don't notice that my Identity has shifted I may fail to alter what sort of information I do / don't reveal.

-- frankly, anything else is likely to be inconvenient at best, and at worst will probably often lead to Identity leakage due to mistakes.

Yeah, that's also probably true, particularly the inconvenience.

As much as it's a punt, I think "user preference" may be the right answer here. This convenience vs. security tradeoff 100% affects the user, not the site, so it ought to be under their control (with a sensible default, which I could see going either way).

if I don't notice that my Identity has shifted I may fail to alter what sort of information I do / don't reveal.

Fair point, although I'll want to see how realistic this concern is. That is, I agree that it's hypothetically quite easy, but I'm not sure that people are likely to make this mistake in real practice.

If it does prove a real concern, then we'll certainly at least need affordances to help with it (and those aren't necessarily complex -- the usual ubiquitous avatar icon, which is certainly coming, would help a good deal).

This convenience vs. security tradeoff 100% affects the user, not the site, so it ought to be under their control (with a sensible default, which I could see going either way).

Oh, it should certainly be under user control at some level: my rule of thumb is that Settings Are Good. But the standard assumption for Querki (and I do believe it's true) is that, once it hits the mass market, 95% of the users will never touch 95% of the settings. So the default behaviour needs to be as least-bad as we can come up with...

“The trick here is that a Notification [...] is sent from an Identity to another Identity, but is actually *delivered* to a User.”

I'm not sure that's how you want to approach it. While ultimately true that the user will see the notifications sent to their various identities, I think they may want to be able to specify different communication methods for different identities. I think you need to know which identity a user is using to interact with Querki at any given time, and don't just assume that they want to see notifications from other identities. While it would be nice to have a way to see all notices about all spaces to all identities, I think you might want an explicit “user omniscient” context that one turns on to see everything, with the understanding that while that's going on, anyone reading over their shoulder might, in fact, see everything. At other times, I'd think you want fairly high walls between the identities. Perhaps with the ability to poke holes in them. One might, for example, say your Home and Play identities know about each other, and you can see notices to either from either. But the Kink and Work identities have never heard of each other, and would be scandalized to hear news of each other.

Possible -- we'll need to work this through in more detail.

But past a certain point, I will probably just recommend getting separate accounts as the only way to keep things *deeply* separated. That is, I may never really commit to a level of separation that would be sufficient for the "my life will end if anyone finds out that these Identities are the same person" cases -- frankly, *I* likely wouldn't trust any online service to that degree, so I'm not sure that I want to be asking others to trust mine that much. (I'd like to be able to accomplish it, but I also don't want to arrogantly mess up anyone's life.)

That said, I get your point, and it's probably correct for many less-extreme cases. I suspect it leads to yet another concept, which I think of as "Profiles", which would define my current *view* of things. The mapping between Profiles and Identities is potentially pretty complex; I'll need to ponder how that might work without being massively confusing. (I have a few ideas about a drag-and-drop interface that might help, but it would need a lot of UX testing...)

That said, I get your point, and it's probably correct for many less-extreme cases. I suspect it leads to yet another concept, which I think of as "Profiles", which would define my current *view* of things. The mapping between Profiles and Identities is potentially pretty complex; I'll need to ponder how that might work without being massively confusing.

You could also go with a less-powerful but simpler "When I am using Identity X, I can also see things from Identities... [picklist]" system.

(Though that doesn't work for auto-switching from one Identity to another, because then you could get chaining - start at Work, auto-switch to Home, auto-switch to Kink, even if a direct Work->Kink is forbidden.)

Interesting idea -- that one hadn't occurred to me. I'm not actually sure it's simpler (I see why you say so, but I think explaining how to think about it may be tricky), but it may well be worth at least some paper prototypes to compare and contrast when we get there...

Another possibility (brainstorming, not advocating): let users create Identities which are aggregates. "This can see everything from Work, Home, or Kink; and will act as any of those depending on Space."

Runs into problems if it's ever possible for >1 Identity from a User to be used in a Space, though.

(Deleted comment)
Well, when I say "deliver to", I really mean in the abstract, pretty much regardless of delivery mechanism. (Of which there will certainly be at least a few -- having both pull and push will be simply necessary, and likely a few forms of each.)

The additional layer of abstraction might tie into the discussion of Profiles upthread, but I'm not sure. I think we'll need to play with this a bit, see where the problems are, and evolve from there once we understand the needs better. (This is all a huge ball of theory so far...)

I have to join in on the 'delivery methods need to be able to differ for identities'.

If I'm at work, I may not mind getting my notifications from family, and social friends, but getting my kink notifications may be a problem. If I'm at a play party, and am trying to not link my home/work identity with my play identity, getting those notifications could be problematic.

In my (massively overdesigned) in-design address book app, my concept of identities is more fluid. (really, I'm aiming for multi-platform, threaded, social media reader, but address books are a first step).
An Identity has a Name. (John Doe)
It may have one or more associated Locations (physical addresses, phone numbers, various accounts) (Home, livejournal, facebook, gmail)
It may have one or more Sub-Identities. (I... uhm, forget why)
It may have a list of one or more (foreign Identity/access Right) tuples. (John is underage, so Mary Doe can take any action on his behalf; his sister Sarah Doe can read anything, but has to tell Mom if John did something stupid)

One of the access rights is Proxy, which allows foreign identity to take actions on behalf of the base ID. so My Kink Identity might give proxy rights to my Home Identity, but not my Work. meanwhile, Work gets proxy from Home, but Kink get proxies from no-one. The rights are not transitive.

I've also played with Time and Space modifiers to access rights, but that gets a bit berserk.

In the end, an Entity is a collection of Identities. A User (or Group) ends up being One or more of those Identities and the access rights they have to other Identities.

Not sure I'm going to get *that* over-designed, but your point is taken. I've opened a User Story to track this notion that I should be able to manage what I see when...

(Yes, there are nasty edge cases if I want to have multiple distinct Identities within the same Space. For the moment, I'm simply not allowing that -- it opens up all *sorts* of sock-puppeting abuses, and needs to be thought through very carefully.)

You've probably already considered this, but it seems like there's the possibility of information bleed via this prohibition?

Say I suspect that Identity X and Identity Y are the same User. I'm running a Space that X uses. I send an invite to Identity Y(*); if they are the same User, it'll be impossible for them to accept. It's not remotely proof, but it is information. (And if Y accepts, it's definite proof of difference.)

(*) = Except that Invitations are sent to things like email addresses, so AFAIK there's no way to directly Invite an Identity right now. Will that always be true?

You've probably already considered this, but it seems like there's the possibility of information bleed via this prohibition?

Yep, I'm well aware of that -- it's actually the main reason why I consider my "only one Identity per Space" stance to be a temporary position.

That said, there seems to be a direct tension between this and sock-puppeting, which IMO is a fairly serious evil that we have to provide guards against. I *think* that it's possible to split the difference (mostly because access to a Space is more controlled than in a typical blog), but I don't want to treat the problem casually: we're going to need to run some scenarios and make sure it isn't too easy to game the system. And we'll need to think about the UX implications carefully.

Except that Invitations are sent to things like email addresses, so AFAIK there's no way to directly Invite an Identity right now. Will that always be true?

No -- indeed, it wasn't the original design. In the medium term, I expect the *vast* majority of invitations to be via social-network connections, and we are likely to allow direct in-Querki invitations to Identities (that is, I can invite someone who I am in some other Space with). The email invites are mostly a bootstrapping thing, which I expect to become relatively minor in the long run...

  • 1