I’ve been following some of the issues Mike Macgirvin has been talking about that can exist as a challenge in the hurdle to cross-federate with other services: in a nutshell, federated apps should work together to ensure a comparable policy base between applications.
Smoothing over “policy differences” is something that cannot be
achieved by mandating a protocol (unless these are part of the protocol
definition). It would require enumeration of the issues involved and a
concerted effort ` to come up with an acceptable policy base.
-Mike Macgirvin
I think this is fundamentally important. There are certain things between #Diaspora and #RedMatrix that are currently incompatible in terms of default privacy settings.
Below are some points Mike has made that I think could provide a good starting point:
The service needs to be able to deliver private posts to a specific set of recipients. Otherwise we can’t put those folks in “aspects” (privacy collections).
The service needs a way to delete a previously posted post/comment/whatever across the entire network (or at least along the path that it was posted). Deleting from API services that are cross-posted is probably impossible, but there’s no excuse if there’s no federated delete mechanism on the federated service.
(This is a new issue but important) The service shouldn’t leak private posts/mail via notification emails.
The service should have some way of including a private photo in a post, besides an obscured URL that can be fusked.
We probably need some kind of common definition of what a “friend” is in terms of access rights, both a one-sided friend and a mutual friend. For instance GNU-social connects as a “follower” and can see published posts from the followee. Diaspora is the other way around - you “share” your posts with somebody but if I recall can then see the sharee’s public stream (posts are sent to the sharer) without requiring the sharee to reciprocate or approve this. They are public, but the sharee’s site is using resources to send these posts so the sharee should have a choice in my opinion. Friendica and redmatrix are kind of a hybrid, but require your permission to give rights to anybody. It doesn’t just happen because you choose to share or follow somebody else. I’m just saying this isn’t consistent. I’m not sure what the right approach should be, except that I think everybody should confirm before an un-solicited “friend” is given any access beyond what is publicly viewable. We probably need some way to make the friending experience and permissions expectations to be consistent across services. On Facebook for instance you can send PM’s to non-friends. In most of the free web you can’t. (In Redmatrix it’s configurable).
Diaspora doesn’t to too badly in all of this. Finding a way to share a private photo to Diaspora (4) has got me buggered. One possibility is if they supported data urls and were able to accommodate large body sizes containing at least thumbnails of these embedded photos (that was how we shared private photos in Friendica before we had zot). 3 and 5 we can document but I hope that 3 will become a reality. GNU-social is almost impossible to work with because of 1 and 2.
5 is just setting a common member-level expectation of what “friendship” entails so that folks don’t get totally confused by the federated web or leak privacy accidentally because another service has a different definition of privacy for one-sided friendships.
I guess this all boils down to “define federated privacy”. Then we can figure out how to implement it.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
TL;DR:
Different networks might have different interpretations of what is private and how this private should behave. My example was the difference between a private posting in diaspora, which has a fixed set of persons, that will see the discussion, and a private posting in my little own network in Stud.IP, which has a set of persons that can vary over time, be extended or even reduced like memberships of groups. But this is only one example and there might be even more attributes in which the “privacies” of the networks may differ.
My conclusion back then was that we need a protocol that respects all kinds of privacies and and that is expandable for future privacy settings. In this protocol any private posting might behave a little different, so it can mimic the behaviour of diaspora as well as of Stud.IP as well as of the most networks we like.
That was only half of the truth: in fact all we need is a software that is able to respect these different kind of privacy settings for each private posting (or maybe just “thing”, if we want files to be included in this). To have such a privacy-rich protocol is not absolutely necessary, but it would make a lot of things easier for the software.
So now to your points:
Of course!
Of course! That is not a matter of privacy in my eyes but of consistency. A network in whcih we can’t edit or delete content is just too stupid.
That is not part of the protocol and I am not sure, if we really need this. The service should … err … serve the user and his/her needs. So if the user wants to get an email notification - why not? That point might change when it comes to end2end-encryption, because the service can’t decrypt the message on its own, but I guess we’re not talking about that kind of privacy here yet.
Of course! A private posting and a private picture are just some sort of private content and should behave the same.
Here I disagree. I am not sure, what we will need a strong definition of friendship for? When it comes to sending messages it is up to each service to define if the message will be rejected or not. That’s it. I think it is only a concern for the service who can write a message to whom and not for protocol. In the protocol we might only need the possibility to define a user-flag with the meaning “you can send this user a message” to display the correct icons.
That is what I think about this. Of course these arguments are just deriving from my point of view that might be kind of special.
It is definitely a good and important topic. Thank you for starting this, Sean!
I’ve recently started using Red Matrix (which is how I found this conversation) and I’m greatly impressed by its functionality and general usability but I’m still kind of baffled by the privacy settings in terms of I’m not sure or remember how I configured it. I also tried to setup another channel to serve as a discussion forum but I couldn’t figure exactly how to do that either.
My point here is that it would be greatly beneficial if there were some standards developed so that we could go about building truly decentralized yet interconnected services. In some ways this is probably similar to the issues networks used to have before TCP-IP and the internet.
It would also make it easier for other people to write their own software that would compete with and compliment the other decentralized social networks.
It would seem to me that end-to-end encryption would be the only way to really accomplish this from a technical level, anything else would potentially be less than private if it were transmitted through any third parties.
But having some mechanism through which you can direct message someone is important. Perhaps changing the name on “private messages” to be direct messages.
Then a module could be developed to set-up GPG encrypted private messages that could have other features as well self as self-destruction. I know there are services out there already that do this for chatting. It is trickier when you are dealing with a web browser as the primary means of interactions. Privacy and the web are kind of difficult.
I wonder if it would be feasible for every message to be encrypted with a public key for each other recipient. So that when they view it they simply see a message that their gpg plugin decrypts. I know someone developed this for e-mail years ago as an add on to mailing list software. Something along these lines would be one way of ensuring messages directed at a few people were always private to only these recipients. The public key directory could be configured into their profile and so you added their public key when you “friended” them.
Which gets me back to the concept of friends and whether a shared vocabulary should be created. I think we need to look at the privacy models of the various social networks that exist and try to make something that is intuitive to people. I’ve always imagined that a good way of doing this would be to have graduated levels of friendship and branches of sharing. Some things you’d want to share with your family, other things you want to share with coworkers. Google+ attempts to do this but I think most people find it too complicated to have such distinctions.
Giving a people a lot of options doesn’t solve the problem if they aren’t sure what they are accomplishing by choosing them.
So you need to not define friendship so much as define the intended recipients. If your network/software only allows your message to be either public or shared with people you’ve accepted as “friends” then people just need to know how to add people to their friends. If you have graduated access control to your profile and posts or granular definitions of the recipients ie “share this with only these people” that is a very different then a default everything is public, people who follow me simply get updates ala a service such as twitter. We’ve found in the recent outcry over the lack of privacy on Ello that people do indeed want to be able to limit their persona from being accessible to people they have not chosen to share it with.
Whether this is something that can be defined by a shared protocol and stay useful for decentralized interaction is up to us to figure out I suppose.
I guess this would be a good place to talk about these things, but I’m kinda sceptical whether anything will come out of it. What is likely they will come up with something and say that everybody could have their say - and then conveniently ignore the fact that not everyone had the time to put into this. And then those who didn’t have time to put into that will be called names for “not playing nice”.
I’m guessing diaspora* as a project will (and have already been) be called those names
But, maybe my scepticism will turn out to be false.
It’s just that the problem with building things using something common is that it just doesn’t happen. It would be nice, but in practise always there are so many stakeholders and everybody thinks their way is the best. And since time is not infinite, people generally don’t have time to just fit things together - or if they would do that, nothing else would get done.
