An introduction to lists and privacy management in Onesocialweb

[Laurent Eschenauer]

A comment of Tyler on his timeline made me think that we are missing a bit of a tutorial on how privacy is managed in Onesocialweb. So, here is a first introduction, that will eventually make it to the wiki. Any comments/ideas/feedback is welcome. Note that not everything stated below is implemented today, but it is coming.

The main concept: 

---------------------------

You have total control on who can do what with your data, at the most fined grained level possible. That means that you can set privacy on a per item level (for activities), on a per field level (in your profile) and on per relationship level (just in case you may want to keep that ex-girlfriend private :-)

In our opinion, this fine grained access control is a key value add from our approach and is really unique today. We have not seen anything similar yet, working in a decentralized way, and achieving this with PuSH, OStatus, Salmon, etc.. won't be straightforward. This is one of the main reason we opt for XMPP to build our system (strong identity and security framework in place).

How it works: 

------------------------

The user experience is dictated by the client, so different clients may expose none, some or all of these concepts, depending on what their aim is. The protocol itself enable to grant/deny actions to subjects. The actions and the subjects are extensible, so that some server and clients could add their own logic if required.

A subject could be:

-  'everyone'

-  'network' (e.g. limit to 'vodafonernd.com' to keep inside the company firewall)

-  'contacts' (anyone being in your roster)

-  'group' (e.g. a roster group. You could tag some contacts as 'friends' and limit sharing to them)

- 'relationship' (the users with who you have a confirmed relationship)

- 'individual' (a specific user JID)

Actions could be read, but also write, delete, update, append, etc.... 

Examples:

-----------------------

- An entry made visible to everyone but commenting is limited to your contacts

- A photoalbum made visible to friend and editable by your wife (so that she can add pictures to it)

- Your location profile field made visible to roster and writeable by fire...@yahoo.com (so that the service can update your location)

- ...

What you can do today:

---------------------------------

1. In the console:

Use the command /privacy to change your privacy setting (until changed again or session is closed). You have four choices:

E: everyone

G: group (it will then prompt you for a group name, enter the name of one of your roster group)

I: individual (it will prompt you for a user JID)

N: none

2. In the web client:

Click the key icon below the status update text area. You can then select between 'Everyone' or one of your roster group. If you have none, here is how to create them: Go to the contacts application, pick a user, select the 'manage person' tab, and there you can add the person to an existing list, or create a new one. 

[tyler gillies]

Awesome information, thank you

--
Everyone Loves Tea
http://www.everyonelovestea.com


--
Subscription settings: http://groups.google.com/group/onesocialweb/subscribe?hl=en

[Martin Pilpul]

Hi,

Due to a lack of time I don't have the chance to get into onesocialweb
that deep at the moment. But I'm very interested in it's development, so
thanks for all you work.

One question arose when I read you last mail:
Is there a chance to revoke access to some contents/posts after they
have been published? Or do only those privacy settings apply to a post,
that are set at the moment a subscriber sends a query to the server?

greets,
Martin

[Vishal Patel]

Hi Martin,

Welcome to the discussion. I think the point you are making was also
brought up previously. Does the following thread help?
http://groups.google.com/group/onesocialweb/browse_thread/thread/ac8eab056d13e6d3/aa45264712f5ea60

Important: subscribers don't query the server -- the server pushes
updates to subscribers. That should help you follow the issues raised
in the linked thread. :)

--Vishal

[Laurent Eschenauer]

Due to a lack of time I don't have the chance to get into onesocialweb
that deep at the moment. But I'm very interested in it's development, so
thanks for all you work.

Thanks !

 

One question arose when I read you last mail:

Is there a chance to revoke access to some contents/posts after they
have been published? Or do only those privacy settings apply to a post,
that are set at the moment a subscriber sends a query to the server?

Different elements here:

1. A user can delete an item and a notification is pushed to the subscribers, they are expected to comply (but of course, since we use a 'fat ping' approach, it cannot be enforced). This is all part of PubSub:

http://xmpp.org/extensions/xep-0060.html#publisher-delete-success-notify

2. Access control rules are linked to an item. We keep the rule, not its translation to actual JID. So, if I posted an entry three months ago and made it visible to 'Friends' and that I had you as a friend today, you will see that entry. Equaly, if I remove you from my Friends list, you won't see these entries anymore when you query my activities.

Let me know if it clarifies. I'll add this bit to the doc as well.

Cheers,

Laurent

[tyler gillies]

#2 is freaking awesome

--
Everyone Loves Tea
http://www.everyonelovestea.com

[Renato Iannella]

On 20 Apr 2010, at 16:23, Laurent Eschenauer wrote:

A subject could be:

-  'everyone'

-  'network' (e.g. limit to 'vodafonernd.com' to keep inside the company firewall)

-  'contacts' (anyone being in your roster)

-  'group' (e.g. a roster group. You could tag some contacts as 'friends' and limit sharing to them)

- 'relationship' (the users with who you have a confirmed relationship)

- 'individual' (a specific user JID)

Hi Laurent, great to see work in this direction ;-)

Do the above terms (or should they) appear (and be defined) on the "Social Relationships" Data Model:

  http://onesocialweb.org/spec/1.0/osw-relations.html#model

We did (as part of the W3C XG) a review of "common" policy terms:

  http://www.w3.org/2005/Incubator/socialweb/wiki/PolicyCommons

One clear missing subject is "friends of friends".  This would be useful to add...

Also, the term "Network", as used by Social Networks, is different than your "network" (ip network) and maybe confusing?

Cheers

Renato Iannella

http://renato.iannella.it

[Alard Weisscher]

Hi Renato,
 

Do the above terms (or should they) appear (and be defined) on the "Social Relationships" Data Model:

  http://onesocialweb.org/spec/1.0/osw-relations.html#model

We separate relationships from subjects in the ACL. Relationships define the relation between two individuals (like friend, colleague, parent-child, etc). The subjects in the ACL are quick ways to define a group of people based on different criteria - of which a relationship can be one (e.g. only allow your colleagues to see this). At this stage you could also use (roster) groups as a subject, commonly known in Social Network world as lists, were you can pick any word you consider appropriate to organize your contacts. So these terms will not be added to the Social Relationships model.
 

We did (as part of the W3C XG) a review of "common" policy terms:

  http://www.w3.org/2005/Incubator/socialweb/wiki/PolicyCommons

One clear missing subject is "friends of friends".  This would be useful to add...

Yes, we will add friend of friend as well.
 

Also, the term "Network", as used by Social Networks, is different than your "network" (ip network) and maybe confusing?

Some of them indeed need clarification. However the words we are using, are not necessarily what you put in the UI, only the language used in the ACL. Client developers can call it anything they want. In our clients we thought to include the domain itself as a hint in the UI (e.g. betavine.net). Also Contacts needs further clarification in the UI.

Cheers, Alard
 

[Martin Pilpul]

Hi,

thanks for the useful information.

Have you thought about using some form of PKI encryption of content data?
(this time i searched the list for some keywords, but did not find
anything).
This would have some advantages for privacy.
1. obviously the data will be encrypted on transport.
2. this way you can revoke access on step earlier. What I understood is
that any revoke of access will be pushed to my friends. If I revoke
access for one of them he will get the information, but untill he
receives the updated items he'll still be able to view them.
With some sort auf keymanagement - something like a keyserver where you
have to look up vor the encrypten key - the access will be revoked in
the moment i revoke it and not when the friend receives it.

I know this has impact on some benefits of a decentralized network, the
ACL will no longer be stored with the item and it's not secure against
"friends" that backup unencrypted items everytime, but i think from a
privacy point of view this would be useful, since the full control would
remain with the owner or at least with his homeserver if this is where
the keys are stored..

Another thing that I've read and thought about, regarding privacy
management, is some sort auf forgetting. Simple example: for status
messages older than let's say a month, it is not relevant if there where
postet on 2010/03/20 at 10:43:33. Knowledge about the day would be
enough. In most protocols things like timestamps are basic information
that can't be altered. Facebook may show thing like "posted a month ago"
but in the database the item still has a unique timestamp.

Just my thoughts about improving stuff that always sucks on know networks :)

Thanks,
Martin

[Vishal Patel]

Hi Martin,

Some great ideas here!

Regarding transport encryption, the XMPP core includes provisions for
TLS, so for content that is "fat-pushed," we can simply rely on that.
In fact, I think the Smack library default mode is to use TLS when the
server supports it. Both server-to-server and client-server messages
can make use of this quite transparently.

Correct me if I am wrong, but it sounds like you are suggesting that
any fat-pushed content is sent to the recipient as an encrypted chunk.
To decrypt, the recipient must request a decryption key from the
sender, and the sender can choose to deny that request. This
certainly adds overhead and does not appear to gain us anything...

Let's say we have a sender (person-S using server-S) and a recipient
(person-R using server-R). In the existing scheme, if person-S wants
to revoke access to a fat-pushed item, server-S sends a delete request
to server-R:
1) if server-R is "bad" it will ignore the request
2) if person-R is "bad" (but server-R is behaving) and has already
viewed the item, he will have saved it elsewhere
3) if person-R is "bad" (but server-R is behaving) and has not viewed
the item yet, he will not see it since server-R will honor the delete
request

In your proposed scheme, person-R/server-R must request a decryption
key from server-S to view the item:
1) if server-R is "bad", it will request the key immediately upon
receiving the encrypted item and store the decrypted content
2) if person-R is "bad" (but server-R is behaving) and has already
viewed the item, he will have saved it elsewhere
3) if person-R is "bad" (but server-R is behaving) and has not viewed
the item yet, he will not see it since server-S will deny him the key

Maybe I am not understanding correctly. :) Can you provide an
example in which your scheme guarantees different outcomes than the
existing scheme?

About the timestamp issue...I am not really clear about how it relates
to privacy. Can you explain? Specifically, I am not unclear about
how knowledge of the exact timestamp becomes more of a privacy concern
as the time fades into the past. Furthermore, the exact timestamp is
in fact useful to client software which needs to show activities and
replies in threaded views. A back-and-forth conversation between
friends will not make much sense if the items go out of order after
one month because they were all posted on the same day. :)

--Vishal

[Laurent Eschenauer]

Have you thought about using some form of PKI encryption of content data?
(this time i searched the list for some keywords, but did not find
anything).

Others are thinking about it, there is an ongoing work at XSF/IETF on end-to-end encryption:

http://xmpp.org/rfcs/rfc3923.html

Now, I agree with Vishal that no amount of tchnology would solve the DRM issue you are referring to, and I personally think that this is a non-technical issue that needs to be solved by non-technical means: if you cannot trust your friends, don't share stuff with them :-)

However, I'm more concerned by the 'bad server' scenario. Not that the admins may be bad, but simply that someone forget to update to the latest version (happens a lot in wordpress) and the server gets compromised. This is where e2e comes in: strong confidentiality, non-repudiation, and even protects against replay attacks. 

So, we'll monitor this work and won't hesitate to bring in whatever piece is usefull to this project, but with one key design element always in mind: keep it simple for the end user. This magic has to happen in the background and not complexify the user experience.

[Pilpul]

Hi Vishal and Laurant,

thanks for your responses.
1. your description is nearly correct, but I'm not thinking about
scenarios where a server or person is bad or not, it is about the
process when it becomes bad.
Imagine you quit with your boy_girlfriend. For a long time it was
totally ok he_she got all status update, but now you don't want her_him
not only to stop receiving them but also to remove access to all items
he_she already owns. Sure he_she could make a copy of all decrypted
items, but if the items are transmitted encrypted and stay encrypted at
the receivers side and are only decrypted when accessed, access is
revoked at the moment you decide to remove him_her from the list of
users that can access the decryption keys. At the the moment you decide
to to remove him_her from your friendslist your client sends an update
the him_her, that he_she has to accept (and may not).
You're right, that there is still the possibility that he_she had copied
all items before, but I would assume that there are several scenarios in
which the idea to make a copy comes up in the moment when the
friend-connection is removed.. so encyption with a keylist which is
controlled by the owner of the information (you) would leave some more
control on your side..

I hope this was more clear..
But you're right this would make a lot of overhead and I don't know if
it's worth it. I was just thinking about methods to enforce control on
the side of the information owner although he_she has no control over
what the receiver part is doing..


2. The timestamp idea is ment as an example for a more general approach
of managing the masses of personal data that is floating around in
social networks. Most of the data is only relevant in short period of
time (from now to next week for example) imagine talks about goint out
etc. But all application store are desigend to store them forever. The
idea may be to make it more "natural". Like you won't remember all that
was said during a telephone conference with your friends about going
out, why should your network application? This would enforce "privacy"
(in a broader meaning) in a way that makes it easier to handle the large
amount of information that ist collected by the applications..

The timestamp example is only one tiny idea how this could be done, but
most systems do not allow stuff like that on a very low level (that a
timestamp has to fit the YY/MM/DD-HH/MM/SS pattern) because computers
are not designed to forget..

Greets,
MARTIN

[Martin Pilpul]

Hi again,

let me add a source of hints for privacy requirements.
The Primelife Project has done some research on privacy problems with
social networks and collaborative environments:
http://www.primelife.eu/results/documents

Especially this document:
"Requirements and concepts for privacyenhancing access control in social
networks and collaborative workspaces"
http://www.primelife.eu/images/stories/deliverables/h1.2.5-requirements_selective_access_control-public.pdf

provides some useful points, i think.
Some requirements can not, or not easily, be transferred to a
decentralized network, but i think it's worth a look. You can find a
compressed overview on pages 62-67.

so long,
Martin