New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy versus Transparency #218

Closed
davidearl opened this Issue Jul 4, 2013 · 18 comments

Comments

Projects
None yet
6 participants
@davidearl

davidearl commented Jul 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Jul 10, 2013

Member

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.

Member

mvl22 commented Jul 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Jul 17, 2013

Member

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

Member

mvl22 commented Jul 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@davidearl

davidearl Jul 17, 2013

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//issues/218#issuecomment-21097903
.

davidearl commented Jul 17, 2013

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//issues/218#issuecomment-21097903
.

@mvl22

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Nov 27, 2013

Member

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:

  • Profile page should behave like a standard 404 when not viewable, rather than give some indication that someone might be present
  • The <name-as-moniker> in the URL should probably be based on the display name when set.
  • When the profile page is not active, mentions of the visible name around the site should be text, non-hyperlinked.

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.

Member

mvl22 commented Nov 27, 2013

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:

  • Profile page should behave like a standard 404 when not viewable, rather than give some indication that someone might be present
  • The <name-as-moniker> in the URL should probably be based on the display name when set.
  • When the profile page is not active, mentions of the visible name around the site should be text, non-hyperlinked.

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

This comment has been minimized.

Show comment
Hide comment
@davidearl

davidearl Nov 27, 2013

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)?

davidearl commented Nov 27, 2013

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

This comment has been minimized.

Show comment
Hide comment
@nigeldeakin

nigeldeakin Nov 27, 2013

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.

nigeldeakin commented Nov 27, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Nov 29, 2013

Member

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

Member

mvl22 commented Nov 29, 2013

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

@gravitystorm gravitystorm added this to the Iteration Twelvty-eight milestone Mar 31, 2014

@gravitystorm

This comment has been minimized.

Show comment
Hide comment
@gravitystorm

gravitystorm Apr 3, 2014

Member

Two of the requests above are already implemented:

  • "The in the URL should probably be based on the display name when set."
  • "Group administrators need to be able to see the real name of anyone applying to become a member of a group."

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

Member

gravitystorm commented Apr 3, 2014

Two of the requests above are already implemented:

  • "The in the URL should probably be based on the display name when set."
  • "Group administrators need to be able to see the real name of anyone applying to become a member of a group."

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

@georgio8

This comment has been minimized.

Show comment
Hide comment
@georgio8

georgio8 Feb 27, 2015

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.

georgio8 commented Feb 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nikolai-b

nikolai-b Feb 28, 2015

Contributor

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.

Contributor

nikolai-b commented Feb 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@georgio8

georgio8 Feb 28, 2015

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.

georgio8 commented Feb 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Feb 28, 2015

Member

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:
#48
so can we discuss that particular issue there.

Member

mvl22 commented Feb 28, 2015

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:
#48
so can we discuss that particular issue there.

@mvl22

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Mar 18, 2015

Member

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.

Member

mvl22 commented Mar 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nikolai-b

nikolai-b Oct 7, 2015

Contributor

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

Contributor

nikolai-b commented Oct 7, 2015

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

@nikolai-b nikolai-b closed this Oct 7, 2015

@mvl22

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Oct 7, 2015

Member

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.

Member

mvl22 commented Oct 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Jul 15, 2017

Member

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.

Member

mvl22 commented Jul 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Jul 15, 2017

Member

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.

Member

mvl22 commented Jul 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mvl22

mvl22 Jul 15, 2017

Member

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.

Member

mvl22 commented Jul 15, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment