cyclestreets / cyclescape

Cyclescape - cycle campaign group toolkit
https://www.cyclescape.org/
MIT License
33 stars 15 forks source link

Privacy versus Transparency #218

Closed davidearl closed 8 years ago

davidearl commented 11 years ago

Nigel points out that the public visibility of profiles is not compatible with a real name policy.

I think there needs to be a preference as to whether your profile is public, or visible only to group members and admins.

Furthermore, creating issues is always public, so real names are disclosed outside a group context if you do that.

Maybe there could be a preference also so that you can choose in what contexts to display real name instead of pseudonym: always, only in group visible items, or never.

mvl22 commented 11 years ago

It's clear this must be addressed as you say.

I think the simple solution is to enable users to choose whether their profile is public or private. I think I suggested this in another ticket already.

mvl22 commented 11 years ago

I think one solution to this is:

1) to treat the "Display name" at /users/edit as what is shown to non-signed in users. It will need a few code changes for places where the name is shown, and will need a note under that field "This is what will be shown on public pages where users are not signed in."

2) a setting to switch off their profile

3) Also, I think the profiles should be put into robots.txt - I don't think the aim of the site is to have a directory of cycling people for the purposes of Google searchers. The aim is to enable community members to know who they're talking to, and robots.txt banning doesn't disrupt that.

Together, these will prevent someone's real name being picked up by a search engine while meaning that community members will see

davidearl commented 11 years ago

That sounds ok. Don't forget the emails need real names too.

David

On Wednesday, July 17, 2013, Martin wrote:

I think one solution to this is:

1) to treat the "Display name" at /users/edit as what is shown to non-signed in users. It will need a few code changes for places where the name is shown, and will need a note under that field "This is what will be shown on public pages where users are not signed in."

2) a setting to switch off their profile

3) Also, I think the profiles should be put into robots.txt - I don't think the aim of the site is to have a directory of cycling people for the purposes of Google searchers. The aim is to enable community members to know who they're talking to, and robots.txt banning doesn't disrupt that.

Together, these will prevent someone's real name being picked up by a search engine while meaning that community members will see

— Reply to this email directly or view it on GitHubhttps://github.com/cyclestreets/toolkit/issues/218#issuecomment-21097903 .

mvl22 commented 10 years ago

I had a useful lunch with Nigel to discuss how privacy can be enhanced, with a view to a better spec than "deal better with privacy". In the end it took us two hours of discussion, such are the number of questions involved. However, we came up with what we thought would be a workable system that would be understandable by users and (I think) relatively straightforward to implement.

Background discussion: levels of visibility

We firstly discussed how we considered there were four levels of visibility to others of their information that a person might want to control:

  1. Visible to search engines like Google, spidering pages (i.e. 'the world + dog')
  2. Visible to people who have a Cyclescape account (i.e. the 'world' - because anyone can register)
  3. Visible to others in their groups, (e.g. a member of Camcycle revealing their name to other Camcycle members) - a more controlled environment as some groups control who can join, and the point of groups is to help build up a community where people get to know each other and so work more effectively
  4. Visible to no-one else

We considered that types (1) and (2) were the same; it is trivial for people to create an account; making things appear that (2) was somehow 'not public' would in fact be actively misleading.

We thought that (4) was not necessary to implement, and would add a lot of complexity; anyway, the presence of a display name gets most of the way towards this point, and if people join a group there is a reasonable expectation that other members should be able to see who they are talking to. There is a danger that more complexity actually reduces privacy because people then don't understand it so don't change anything (i.e. the Facebook effect).

So in the end, this simplifies down to visibility of real names to the following easily-understandable distinction:

a. Only members of my group(s); or b. Anyone

(A side effect of this is that no special logic is ever needed for group administrators, because by definition they will be able to see the real name as their group memberships overlap.)

So, in terms of actual implementation:

1. How is my name shown to other users of the site?

The general rule we came up with is, wherever a page (or e-mail) shows a person's name:

  1. If display name is set, then if person looking at your name is in the same group [strictly speaking: if group memberships overlap] as you are, they can see your real name. This takes effect no matter what the nature of the material is (e.g. irrespective of the whether a thread is owned or not owned by a group).
  2. (Obviously, in all situations, if no display name is set, always show the real name.)

(We recognised there was one scenario where there would be a kind of inconsistency: if a discussion thread owned by a group is set to open to people outside the group to join, e.g. http://camcycle.cyclescape.org/threads/644 then some people would be able to see other people's names, and some not. The only problem this might create is when someone replies and says "John Smith above said blah" but to some users, John Smith would be shown as koolbiker1. However, we thought that inconsistency would arise whatever design was come up with, and the above solution was the most understandable and therefore effective for the user.)

2. Name settings page

The form where the Real name and Display name needs labels underneath to make clear when these are used. This might be slightly tricky to do clearly. Perhaps something like:

"If you set a display name, it will be shown to people who are not in any group(s) you have joined."

3. Visibility of user profile pages

i.e. the pages at /users/<id>-<name-as-moniker>/profile

Even though this might then show non-identifiable names to 'outsiders' (i.e. people outside your group, if you are in a group and want to operate as privately as possible), we felt there was still a need to hide the profile. Therefore, there should be a setting:

My profile page [include link to it] is: (•) Visible to anyone ( ) Visible only to members of groups I'm in

Probably 'Anyone' would be the default, because the display name stuff above already adds a degree of privacy.

Additional implementation would be needed:

4. Future implementation: listing of individuals subscribed to a thread

There is a general ticket at #267 which discusses the listing. One question is whether people should be able to control their visibility there; again, though, the display name system already adds sufficient privacy anywhere. No action needed on this at this time.

davidearl commented 10 years ago

Please don't forget the need for the status of a thread to be made clear, particularly in emails.

And if you're going to put a 404 up for profiles, please say on it why you can't see it and what you would have to do to be able to see it (with links), e.g. request to join (one of several) groups.

If you're adding options, why not have a third option to never display profile (or only to group admins)?

nigeldeakin commented 10 years ago

Thanks for writing that up, Martin. That reflects what we agreed.

Issues We also discussed the fact that all issues are currently visible to anyone. It is not possible to create an issue that could only be seen by people in a particular group.

Martin explained that this was deliberate. Issues in Cyclescape are intended to relate to physical problems in the real world, which by their nature are visible to everyone. An issue in Cyclescape is a statement that a problem exists, and there is therefore no reason why the author should not be happy for it to be public. In fact it is positively beneficial for non-members to be able to see what Issues have been reported, even if they cannot view the subsequent discussion threads, since it will draw them into the issue and perhaps encourage them to join the appropriate group and participate. It will also avoid non-members accidentally creating duplicate issues.

We agreed that the web form for creating an issue needs to make clear that the title and description of the issue will be visible to anyone, and so they might want to keep the issue description fairly short and simple. The web form should encourage users who want to make a non-public personal statement about the issue to do so as the first posting to a group-private thread on the issue.

An issue would always be public and would show the name of the user who reported it. Users who were members of the same group would see their real name. Other people would see the display name (if set) or the real name (if not).

Profiles Group administrators need to be able to see the real name of anyone applying to become a member of a group. This will need special handling since they would otherwise only see the display name (since they are by definition not a member of the group yet)

Visibility of subscribers to threads Currently every thread has a list of users subscribed to it. This is something of a privacy vulnerability since a non-member could create an issue in a popular location, start a public thread on it, and immediately see the names of all the people who have automatically been subscribed to it. By creating a few issues around Cambridge you could soon find out the names of all the local Cyclescape members. I discussed this with Martin and we agreed this needed some more thought.

Email notifications of thread Users who receive thread postings by email need to be reminded in every email whether the thread is public or group-private.

Privacy policy In addition to software changes, there needs to be a document which explains exactly who is able to see content contributed by users (issues, thread postings etc), and who is able to see personal information about the user (name, profile text, photo etc), and how they can control this.

mvl22 commented 10 years ago

Thank you for filling in the gaps, Nigel - sorry I forgot to note those points.

gravitystorm commented 10 years ago

Two of the requests above are already implemented:

I'll be creating separate issues for the other points raised and work through them.

georgio8 commented 9 years ago

As far as I can see, these plans will do a good job of ensuring that people can control the privacy of their real names while allowing members of particular groups to see them. But they don't address the problem that I raised in #323 - which has become a crucial issue for us in LCC now that we are using Cyclescape to mediate discussion of TfL consultation across all LCC members and other supporters.

To reiterate, we are using public threads for the discussion of consultations (because it will be a long time, if ever, before all LCC members and supporters are in the LCC Group on Cyclescape). But we want to ensure that we can identify the contributors to these discussions by their real names.

My suggested solution is to enable the initiator of a thread to set an option 'comments only from users with public real names'. If this is too simplistic a solution, I'd like to discuss other options to achieve what we need.

nikolai-b commented 9 years ago

hi @georgio8, I've just started doing development work on cyclescape (which means I would like to understand a bit but also I might ask things that have already been answered). I don't understand how it would be decided that contributors are using their real names? Are you just saying you'd like the ability to only allow users with two names given to be able to comment on a thread (e.g. "Jean Green" can comment but "Jean" cannot). That would be simple to implement and when commenting there could be a little notice saying "Please use your real name" but then a person called "NotMyName RealName" can also comment.

Personally, I like your suggestion in #323 about having the ability to send a direct message to a user. This could be limited to members of the group the user has commented on.

georgio8 commented 9 years ago

Hi Nikolai, How about changing the form to have 'First Name', 'Last Name' and 'Display Name' fields? In my opinion we should require that the complete them all, but others may disagree. In that case, it should be an option for a thread creator to set the thread to 'no anonymous comments', meaning that comments can only be posted by people who have filled all the name fields in their profile. Glad that you think the 'Direct Mail' facility is needed. Cyclescape is about the only forum/social network that doesn't provide it at present.

mvl22 commented 9 years ago

Glad that you think the 'Direct Mail' facility is needed

Yes. Direct messaging was always part of the original spec - see section 26, where it was marked as a Priority 3 level thing to implement. http://blog.cyclescape.org/images/ToolkitSpecificationFull.pdf

Issue 48 is the direct messaging thread: https://github.com/cyclestreets/cyclescape/issues/48 so can we discuss that particular issue there.

mvl22 commented 9 years ago

How about changing the form to have 'First Name', 'Last Name' and 'Display Name' fields?

There is a bit of an issue here which is that not everyone has both a forename and surname. There is certainly active camcycle member for instance who doesn't.

nikolai-b commented 8 years ago

This has been done in #369, can we have an parts of this that are still outstanding opened as new issues

mvl22 commented 8 years ago

Yes; I will try to migrate the residual points to fresh issues.

I think the main one is reworking of the layout of the e-mails, which don't make things like this anything like clear enough. The information is all in them, but it needs to be made much clearer.

mvl22 commented 7 years ago

My suggested solution is to enable the initiator of a thread to set an option 'comments only from users with public real names'.

For ease of reference, this is separately discussed as issue #392.

mvl22 commented 7 years ago

Personally, I like your suggestion in #323 about having the ability to send a direct message to a user.

To confirm: this has been implemented a while back as issue #48.

mvl22 commented 7 years ago

can we have any parts of this that are still outstanding opened as new issues

Just to confirm that I've reviewed the full discussion in this issue, and all aspects are implemented, except where noted as a separate issue.