![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeur[Crossposted to Google+, LiveJournal and Art of Conversation. That, in and of itself, illustrates some of the points I'm making.]
I've posted a lot (mainly on Google+) about the problems with the way Google is handling identity, and the various dangers of it. The just-linked article describes neatly why Google wants to mess up the identity architecture. But it's worth spelling out the alternative, and how it should work to be best for the users.
I've been meaning to do a long writeup for months now, but keep getting distracted, so here's the back-of-the-napkin summary. Consider it a sort of technical manifesto.
(Yes, this is the short version. It's a quick and dirty writeup, just the spark for a lot more discussion. And most of it isn't that novel: others have talked about it, but haven't gotten far enough yet.)
There are, in principle, four principal layers in a well-constructed Internet identity architecture. I'm not going to go into the fine details, because from this viewpoint they don't matter as much -- what really matters is how they relate to each other. Suffice it to say, none of this is easy, but it's all technically feasible if folks collectively want it enough.
All of these should be talking to each other through *open* protocols, with no back doors. That's extremely important: the point of the exercise is that the individual should be able to control each of these layers him or herself. Even more importantly, no single company should be able to lock you into their stack: if you really value your privacy highly, you should get each of these from separate companies.
(I can't overstate the importance of this. The success of the Internet has largely been due to its embrace of open protocols like IP, TCP, HTTP and so on. It is a travesty that the social network space has festered without them like this.)
The layers are:
Layer 1: Identity -- this is the simple statement of "this is me". Crucially, I should be able to have multiple of these, defined however I like. In my own case, there's "Mark Waks" (the professional / business identity) and "Justin du Coeur" (the social / club identity). These Identities may provide additional details such as name, gender, or what-have-you, but don't need to: all they really need to do is provide an authentication mechanism.
We already have Layer 1, in a couple of different forms. There are SOAP-based versions in the form of the WS-Security stack, and those are fairly elegant and well designed. In practice, OpenID is cruder but much more prevalent, works adequately for many purposes, and is used a lot. (Although not nearly as much as it should be.)
Layer 2: Social Grouping -- this is the notion of G+ Circles, FB Lists, LJ Flists, and so on: groups of people that you define. These Groups may be public (everyone can see their existence) or private (only you know they exist). A Group is owned by one or more Identities, and contains any number of Identities. Note that a Group does *not* contain people, it contains Identities. One of the core principles here is that people know each other as Identities; how much they know about the relationship of a person and an Identity is a relatively private matter. (That is, lots of people know that "Mark Waks" is "Justin du Coeur", but that should be a decision I control, not enforced by the software. The former should be in groups about these sorts of technology matters, the latter in discussions of the SCA and fandom.)
There have been some stabs at doing this properly, at least to the extent of sharing group information between applications. I don't get the feeling that anybody has taken it seriously enough yet, and some providers (notably Facebook) deliberately make life difficult. But it's been examined a lot.
Layer 3: Application -- this is conceptually the top of the stack, but it interacts with the other layers in fairly subtle ways. This is all the stuff you can *do* online. In principle, all functionality belongs here, and shouldn't get mixed in with the other layers.
Most systems get this wrong, mixing everything from personal information to chat into the Identity layer instead of formally separating it via APIs into a consistent Application layer. In particular, the big providers tend to treat applications as what everyone *else* gets to do, while privileging their own stuff. People have always objected when Microsoft does things like that; there is no reason for companies like Facebook and Google to get let off the hook.
There are some nascent proto-standards for this sort of thing, but I haven't seen much agreement yet. It's not going to be real until multiple companies are hosting applications using the same standard, and a fair number of companies are writing applications using it.
Layer 4: Aggregation -- this is the elephant in the room, that everyone prefers to ignore, but it's central to much of the privacy problem.
The thing is, if you really care about your privacy, you need to be able to control how your Identities relate to each other. The Identity provider, the Grouping provider, the Application provider -- none of these should have to know about all of your Identities. Moreover, if one of them *does* own the collection of Identities, then they own you in a sense, and we fail the key objective of giving you control over your online world.
This is the heart of the various Google problems -- I haven't yet figured out whether they are being deliberately obtuse about this problem, or really don't get it, or are struggling with its implications and (typically of Google) refuse to say anything at all until they have the one true solution built in-house, and are simply refusing to engage properly with the wider community. It was the heart of the issue with the Real Names policy (if everything has to be under a single real name, you get aggregated whether you like it or not), and it's the heart of the issue with their new privacy policy (since it is now clear that you can't separate your identities simply by using different apps).
Now of course, you *can* deal this today, by creating completely separate accounts and never letting them touch each other; that's often recommended. But it's a blithe non-answer, because the simple truth is that that's horribly inconvenient. There simply isn't good tool support for it, so at best it's clunky.
This is the bit that's actually technically challenging, because it affects the way the rest of the stack works. In principle, you want to be able to aggregate your *views* of applications -- for example, be able to see all of the conversations that include all of your Identities in a single place. But doing this while getting real privacy means that the Applications have to be built in such a way that they can't accidentally "leak" the relationships between the Identities, and that's tricky. Still, it could likely be managed with a well-controlled environment, with well-defined APIs.
Separating things into clear layers like this, communicating via clear APIs, would improve the online social world in a lot of ways. It would level the playing field, letting in lots of competition in each of these spaces; at the same time, it would make it more economical to build new applications if you didn't have to rewrite them for each social network.
And I should be clear: it's entirely reasonable to cheat a bit. So long as a social network allows in outside versions of each of these protocols, there is nothing at all with it offering a full stack of all of them, integrated to make it easier for a naive user to get involved. Yes, there are some market risks with that sort of collusion, but let's get real -- most people want convenience, and do *not* care about things like privacy or openness. (Yes, they should. But the world doesn't run on nice ideals.)
Why doesn't it just happen? Plain and simply, because the above architecture doesn't offer an obvious way to become a billionaire. In that, it's much like the Internet itself. As an individual, you *want* the social network to be a commodity, the same way that the Internet is. But companies want to lock you into their walled gardens, because that's how they get rich.
History points the way, though. Originally, the networks themselves were walled gardens -- companies like Compuserve and Prodigy tried to lock you into their gardens, providing lots of features but not letting you walk outside. We didn't put up with it then: we collectively instead went for the messy but inter-connected Internet, and those companies basically wound up in the dustbin.
And there's no reason for us to put up with walled gardens now. The very fact that Facebook and Google+ (and Livejournal and and and) mostly don't talk to each other illustrates how broken things are. That's because each of those companies, ultimately, wants to own you and profit from you. We need to get away from that, and not *let* ourselves be owned.
How do we get there from here? Honestly, a lot of hard work on many peoples' parts. Trying honest prototypes and experiments; agreeing standards; ultimately, building a system that does all the sorts of stuff that Facebook and Google+ do in a more open way. The public isn't going to move away from them because of airy principles; they're only going to move if we can build an alternative that is *better*, and demonstrate that to them. That'll take patience.
But I do think it can be done -- moreover, I think it *will* happen, because it is closer to what people want. Folks are pretty fed up with the split between the various social networks: it's a real inconvenience for many people. It's time to start building The Social Network, the social level corresponding to the unified Internet, so that we stop having to choose to fragment.
(And yes, I'm gradually talking myself into rebooting CommYou, with a radically different business plan...)
I've posted a lot (mainly on Google+) about the problems with the way Google is handling identity, and the various dangers of it. The just-linked article describes neatly why Google wants to mess up the identity architecture. But it's worth spelling out the alternative, and how it should work to be best for the users.
I've been meaning to do a long writeup for months now, but keep getting distracted, so here's the back-of-the-napkin summary. Consider it a sort of technical manifesto.
(Yes, this is the short version. It's a quick and dirty writeup, just the spark for a lot more discussion. And most of it isn't that novel: others have talked about it, but haven't gotten far enough yet.)
There are, in principle, four principal layers in a well-constructed Internet identity architecture. I'm not going to go into the fine details, because from this viewpoint they don't matter as much -- what really matters is how they relate to each other. Suffice it to say, none of this is easy, but it's all technically feasible if folks collectively want it enough.
All of these should be talking to each other through *open* protocols, with no back doors. That's extremely important: the point of the exercise is that the individual should be able to control each of these layers him or herself. Even more importantly, no single company should be able to lock you into their stack: if you really value your privacy highly, you should get each of these from separate companies.
(I can't overstate the importance of this. The success of the Internet has largely been due to its embrace of open protocols like IP, TCP, HTTP and so on. It is a travesty that the social network space has festered without them like this.)
The layers are:
Layer 1: Identity -- this is the simple statement of "this is me". Crucially, I should be able to have multiple of these, defined however I like. In my own case, there's "Mark Waks" (the professional / business identity) and "Justin du Coeur" (the social / club identity). These Identities may provide additional details such as name, gender, or what-have-you, but don't need to: all they really need to do is provide an authentication mechanism.
We already have Layer 1, in a couple of different forms. There are SOAP-based versions in the form of the WS-Security stack, and those are fairly elegant and well designed. In practice, OpenID is cruder but much more prevalent, works adequately for many purposes, and is used a lot. (Although not nearly as much as it should be.)
Layer 2: Social Grouping -- this is the notion of G+ Circles, FB Lists, LJ Flists, and so on: groups of people that you define. These Groups may be public (everyone can see their existence) or private (only you know they exist). A Group is owned by one or more Identities, and contains any number of Identities. Note that a Group does *not* contain people, it contains Identities. One of the core principles here is that people know each other as Identities; how much they know about the relationship of a person and an Identity is a relatively private matter. (That is, lots of people know that "Mark Waks" is "Justin du Coeur", but that should be a decision I control, not enforced by the software. The former should be in groups about these sorts of technology matters, the latter in discussions of the SCA and fandom.)
There have been some stabs at doing this properly, at least to the extent of sharing group information between applications. I don't get the feeling that anybody has taken it seriously enough yet, and some providers (notably Facebook) deliberately make life difficult. But it's been examined a lot.
Layer 3: Application -- this is conceptually the top of the stack, but it interacts with the other layers in fairly subtle ways. This is all the stuff you can *do* online. In principle, all functionality belongs here, and shouldn't get mixed in with the other layers.
Most systems get this wrong, mixing everything from personal information to chat into the Identity layer instead of formally separating it via APIs into a consistent Application layer. In particular, the big providers tend to treat applications as what everyone *else* gets to do, while privileging their own stuff. People have always objected when Microsoft does things like that; there is no reason for companies like Facebook and Google to get let off the hook.
There are some nascent proto-standards for this sort of thing, but I haven't seen much agreement yet. It's not going to be real until multiple companies are hosting applications using the same standard, and a fair number of companies are writing applications using it.
Layer 4: Aggregation -- this is the elephant in the room, that everyone prefers to ignore, but it's central to much of the privacy problem.
The thing is, if you really care about your privacy, you need to be able to control how your Identities relate to each other. The Identity provider, the Grouping provider, the Application provider -- none of these should have to know about all of your Identities. Moreover, if one of them *does* own the collection of Identities, then they own you in a sense, and we fail the key objective of giving you control over your online world.
This is the heart of the various Google problems -- I haven't yet figured out whether they are being deliberately obtuse about this problem, or really don't get it, or are struggling with its implications and (typically of Google) refuse to say anything at all until they have the one true solution built in-house, and are simply refusing to engage properly with the wider community. It was the heart of the issue with the Real Names policy (if everything has to be under a single real name, you get aggregated whether you like it or not), and it's the heart of the issue with their new privacy policy (since it is now clear that you can't separate your identities simply by using different apps).
Now of course, you *can* deal this today, by creating completely separate accounts and never letting them touch each other; that's often recommended. But it's a blithe non-answer, because the simple truth is that that's horribly inconvenient. There simply isn't good tool support for it, so at best it's clunky.
This is the bit that's actually technically challenging, because it affects the way the rest of the stack works. In principle, you want to be able to aggregate your *views* of applications -- for example, be able to see all of the conversations that include all of your Identities in a single place. But doing this while getting real privacy means that the Applications have to be built in such a way that they can't accidentally "leak" the relationships between the Identities, and that's tricky. Still, it could likely be managed with a well-controlled environment, with well-defined APIs.
Separating things into clear layers like this, communicating via clear APIs, would improve the online social world in a lot of ways. It would level the playing field, letting in lots of competition in each of these spaces; at the same time, it would make it more economical to build new applications if you didn't have to rewrite them for each social network.
And I should be clear: it's entirely reasonable to cheat a bit. So long as a social network allows in outside versions of each of these protocols, there is nothing at all with it offering a full stack of all of them, integrated to make it easier for a naive user to get involved. Yes, there are some market risks with that sort of collusion, but let's get real -- most people want convenience, and do *not* care about things like privacy or openness. (Yes, they should. But the world doesn't run on nice ideals.)
Why doesn't it just happen? Plain and simply, because the above architecture doesn't offer an obvious way to become a billionaire. In that, it's much like the Internet itself. As an individual, you *want* the social network to be a commodity, the same way that the Internet is. But companies want to lock you into their walled gardens, because that's how they get rich.
History points the way, though. Originally, the networks themselves were walled gardens -- companies like Compuserve and Prodigy tried to lock you into their gardens, providing lots of features but not letting you walk outside. We didn't put up with it then: we collectively instead went for the messy but inter-connected Internet, and those companies basically wound up in the dustbin.
And there's no reason for us to put up with walled gardens now. The very fact that Facebook and Google+ (and Livejournal and and and) mostly don't talk to each other illustrates how broken things are. That's because each of those companies, ultimately, wants to own you and profit from you. We need to get away from that, and not *let* ourselves be owned.
How do we get there from here? Honestly, a lot of hard work on many peoples' parts. Trying honest prototypes and experiments; agreeing standards; ultimately, building a system that does all the sorts of stuff that Facebook and Google+ do in a more open way. The public isn't going to move away from them because of airy principles; they're only going to move if we can build an alternative that is *better*, and demonstrate that to them. That'll take patience.
But I do think it can be done -- moreover, I think it *will* happen, because it is closer to what people want. Folks are pretty fed up with the split between the various social networks: it's a real inconvenience for many people. It's time to start building The Social Network, the social level corresponding to the unified Internet, so that we stop having to choose to fragment.
(And yes, I'm gradually talking myself into rebooting CommYou, with a radically different business plan...)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-02-01 07:29 pm (UTC)Like so many systems, social media has no problem with joining or starting, but everything is broken with undoing.
So I "unlink" you from a group. What happens to your access? (This was quite a problem with YahooGroups, still is.) If I move you from one group to another, what happens to old postings or data? How can I tell if the group I am (at this minute) contains someone I don't want to have see my comments or additions to a thread?
The dynamics are key features, but mostly they seem to be considered in terms of "adding" access, not in denying or controlling.
(no subject)
Date: 2012-02-01 07:44 pm (UTC)In a way, I suppose that's partly because of the above issues: since there isn't a clear division between the abstractions, things tend to wind up very ad hoc, without any underlying principles...
(no subject)
Date: 2012-02-01 08:23 pm (UTC)My agenda is that we use systems over time, yet designs tend to picture systems that are static in time, and therefore miss a key dimension.
You are correct to fold SOME of what I said into "ownership of information about grouping and aggregation".
Part of what I was also thinking about, is the ability to dis-aggregate data by changing permissions or identities. If some organization, such as Google, finds a way to aggregate two of your online identities, can you undo or manage that unwilling aggregation? Can I, for example, revoke your access or visibility into my unit of identity that is managed elsewhere?
Ownership of data is a complex problem, but reasonably better understood than ownership of identity. We can revoke access to data, but not to an identity.
(no subject)
Date: 2012-02-01 08:51 pm (UTC)(no subject)
Date: 2012-02-02 10:56 am (UTC)http://www.sunjournal.com/news/approved/0001/11/30/live-chat-one-year-retrospective-sunjournalcoms-re/1149013#.Tyk4wTKEXqc.facebook
"One year retrospective of SunJournal.com's real name commenting policy "
(no subject)
Date: 2012-02-02 05:55 pm (UTC)(And the survey is rather self-selective: they're already a year into selecting the community for those biased towards a realname preference, so I would expect there to be strong support at this point.)