In developing our People Service, Liberty proceeded on the assumption that a user's social network (as manifested in the membership of their People Service) was an identity resource like any other (e.g. profile, geolocation, calendar etc) and so the user would be able to control under which circumstances, and to whom, it was shared with.
In describing existing social network sites like LinkedIn, Friendster, Orkut, etc, the authors write:
Most networking sites share a similar model of interpersonal links — they are mutual, public, unnuanced, and
decontextualised:
- links are mutual: if A shows B as a connection, then B has
also agreed to show A as a connection, - the links are public: they are permanently on display for
others to see — here, the sites do differ, e.g. LinkedIn
allows you to see only the connections made by your
immediate links, and only if they allow it, whereas Orkut
allows users to explore freely, and others limit network
viewings to a still more broad class of friends of friends of
friends, - the links are unnuanced: there is no distinction made
between a close relative and a near stranger one chatted
with idly on-line one night, - the links are decontextualised: there is no way of showing
only a portion of one’s network to some people — some
sites do allow users to adjust the closeness by degree of
the people who are to be allowed to see their
connections, and within that degree everyone can see all
connections (there is no ability to segregate one’s links),
and similarly for one’s profile, and a few sites allow
limiting parts of the profile to closer connections, but
again connection degree is the only distinction made.
We considered each of these aspects in developing the People Service.
mutual - while we allow for symmetric connections between users, we don't require them. Just because Bob is in Mary's list doesn't necessarily imply that Mary is in Bob's. However, it's worth noting that, for some use cases, the lack of a mutual connection can have a significant impact on the effectiveness. For instance, if Bob adds Mary to his connections in the context of enabling her to view his geolocation - without Bob also being added to Mary's list , Mary's applications will be unable to take advantage of this privilege and query Bob's geolocation on behalf of Mary. They wouldn't know where to start (unless Mary tell's them 'Oh, Bob said I could see his geolocation and this is the address').
public - ultimately, depends on the policy of the user (and of the provider's ability to enforce said policy). Most use cases we considered have the list of connections being queried by some provider on behalf of the same user (e.g. some provider querying Bob's list of connections on behalf of Bob, rather than some other user) and so the access control decision boils down to 'Which providers can ask on my behalf'. Another class of use cases would require that access be defined in terms of the identity on whose behalf the request was being invoked. For such use cases, a user might define access control for their list of connections as 'Allow anybody on my list to see the list, forbid any others'.
unnuanced & decontextualized - a user can categorize their connections through groups and/or metadata tags. Based on such categories, the connections can be differentiated (e.g. allow anybody to see my 'Work Colleagues' but keep hidden the 'Family' group).
What we haven't thought about to this point is the ability of a particular member of somebody's People Service list to specify their policy over display (e.g. allow Mary to specify that, while she consents to being added to Bob's list of connections, she does not wish this fact to be advertised'. This would introduce the question of who 'owns' this information.
No comments:
Post a Comment