Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Privacy versus Transparency #218
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.
I think one solution to this is:
Together, these will prevent someone's real name being picked up by a search engine while meaning that community members will see
That sounds ok. Don't forget the emails need real names too.
On Wednesday, July 17, 2013, Martin wrote:
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:
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
(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:
(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
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:
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.
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)?
Thanks for writing that up, Martin. That reflects what we agreed.
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).
Visibility of subscribers to threads
Email notifications of thread
Two of the requests above are already implemented:
I'll be creating separate issues for the other points raised and work through them.
This was referenced
Apr 3, 2014
referenced this issue
Jul 2, 2014
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.
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).
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.
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.
Issue 48 is the direct messaging thread: