jducoeur: (Default)
 h/t to osewalrus for the pointer to this fine article about the misperception that anonymity is the cause of bad behavior online, and that forcing everyone to use their wallet names is the solution.  The summary is that there has been actual research on the subject, and no, requiring wallet names doesn't help.  (And it makes some problems much worse.)

Mind, I think anonymity per se *is* a problem, because it prevents a lot of social tools from working right -- some amount of persistent identity is, in my experience, necessary for the functioning of a good community.  But pseudonymity, in my experience, is the best balance point: enough persistence to build community, without flailing around at the mistaken idea that online identities should be synonymous with real-world ones...
jducoeur: (querki)
[For the identity geeks in the audience]

I sometimes talk about how piss-poor the major players in the social networking world are about Identity, and how annoying that is -- Facebook and Google's naive assumption that one person should have one and only one identity online, based on their wallet name, is both naive and dangerous. Frankly, it's poor engineering, and fails to recognize that *most* people have multiple distinct identities, even if those are as loose as "me at work" vs. "me at home".

That said, I will admit that doing it right isn't easy. I'm putting a fairly preposterous amount of effort into getting the abstractions right for Querki, even though Querki really only lets you have one identity so far. For the moment, your identity is your Querki login, but that's always been a temporary plan. In the long run, the notion is that you can attach any number of Facebook, G+, Twitter, (hopefully LiveJournal), etc, accounts to log into Querki, and use all of them distinctly as you see fit. Moreover, I'm trying hard to get Querki to grok the notion that there are distinct identities, and we should try hard to avoid "leakage" between them.

That's all about getting the abstractions right, and I just had a reminder about how useful it can be to do that correctly from the beginning.

I'm in the middle of implementing Apps -- the ability for one Space to be a "child" of a higher-level Space, using all of its Models and Things. Security's important there -- the child Space can see everything in the parent App, so I've added a new permission, saying who is allowed to use this App. That "who" is the owner of the child Space. And last night, I was tearing my hair out, because I was missing a bunch of code pathways to get at the User who owns the Space.

Fortunately, this morning I realized that that was because I was fighting my own abstractions. This was hard because it *should* be hard, because it's incorrect: if a User inherits the App from a Space owned by the wrong Identity, that leaks the relationship between that User's Identities to the owner of the App. It should be an Identity relationship, not a User one, and my own architecture was pushing back at me, telling me I was making a mistake.

That's as it should be, and it's an illustration that Identity isn't something you can easily fix after-the-fact -- you can't build a system assuming a 1-to-1 relationship between User and Identity, and then make it subtler later without a lot of difficulties. Rather, the distinction needs to be baked in from the very start.

(Why bother? User convenience, to a large degree: I don't want to have to keep logging out and logging back in in order to use a couple of distinct identities. And partly to allow you to manage your identities flexibly, so that you *can* treat identities from different services as linked if you choose to do so: the long-term goal is that you can manage your portfolio of diverse identities as you see fit. But in large part, it's a grand experiment -- an exploration of what happens when you take this problem seriously, so we can collectively learn how to make Identity on the Internet better.)
jducoeur: (Default)
One of the hot new ideas in the Identity space is the notion of the "iname" -- an identity indirection that serves as a wrapper for your email, URL, phone number and whatever else. You register for an iname, and that gives you a handle that you can pass around (eg, "=jducoeur"), via which people can contact you indirectly, without necessarily exposing your actual addresses or getting rigidly bound to them.

And my reaction to this whole thing is, "This is a good idea why?" It's yet another more or less flat namespace (exactly as hierarchical as DNS, far as I can tell). It's yet another namespace that seems to be open to squatting. It's still dependent on brokers. It seems to be exactly as good as DNS, in pretty much every important respect.

Honestly, I find the whole idea daft -- it fails to solve any of the interesting problems, and seems to be very much yesterday's technology. It adds a layer of complexity for no obvious benefit. (Unlike systems like OpenID or CardSpace, which have their flaws but are at least adding new and useful benefits.) I am completely failing to understand why otherwise-sensible people seem to be enchanted by it. Can anyone explain the attraction to me?
jducoeur: (Default)
One of the hot new ideas in the Identity space is the notion of the "iname" -- an identity indirection that serves as a wrapper for your email, URL, phone number and whatever else. You register for an iname, and that gives you a handle that you can pass around (eg, "=jducoeur"), via which people can contact you indirectly, without necessarily exposing your actual addresses or getting rigidly bound to them.

And my reaction to this whole thing is, "This is a good idea why?" It's yet another more or less flat namespace (exactly as hierarchical as DNS, far as I can tell). It's yet another namespace that seems to be open to squatting. It's still dependent on brokers. It seems to be exactly as good as DNS, in pretty much every important respect.

Honestly, I find the whole idea daft -- it fails to solve any of the interesting problems, and seems to be very much yesterday's technology. It adds a layer of complexity for no obvious benefit. (Unlike systems like OpenID or CardSpace, which have their flaws but are at least adding new and useful benefits.) I am completely failing to understand why otherwise-sensible people seem to be enchanted by it. Can anyone explain the attraction to me?

Profile

jducoeur: (Default)
jducoeur

May 2025

S M T W T F S
    123
45678910
11121314 151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags