Opened 6 years ago

Closed 6 years ago

#1757 closed bug (fixed)

Privacy problem on places page

Reported by: jeanyves Owned by: crumbking
Priority: critical Milestone: 1.3
Component: BW Geo Keywords: privacy places
Cc: mahouni

Description

Try the following:

Logoff from BW.

go on page http://www.bewelcome.org/places/FR/Bretagne/Vitr%C3%A9 (the place I live)

You will see all username of BW member living there.

My picture is display because I have a public profile. The one of my wife (cathy) is hidden (she has not a public profile).

The point here is that Usernames should not appear because they are indexed by google.

I think this is a regression. The places page should have a condition depending if there is a logged in user or not to decide to hide username of public profile.

The test seems to be partly existing since the not public profile picture are not display.

The counters should alway be the real ones, regardless if the user is using a public session or a logged in session. In case of public session, if not all Username are display a message could inform the user that he should create a profile or logged in to see more results.

I set this to critical because this will be consider as a high privacy problem

This is very certainly easy to solve but I have no running environment so I will not do it by myself for now

Change History (26)

comment:1 Changed 6 years ago by crumbking

I may do not understand it.

But you mean your username is visible with your geo information in case you have a non public profile?

Is that the privacy issue here?

If we wanna repair this we should leave the user not confused. Means we should display the public profiles and we should add a box in the end with "+X additional profiles. Login to view these profiles"

Off topic:

Your profile username will be visible in the forum/groups anyway. If you participate in publlic discussions.

End off topic

comment:2 Changed 6 years ago by lantti

As I understood it the privacy issue was just that. Namely should the username be considered part of the data to be displayed only to logged in members in case of a non-public profile. If the consensus is that it should then your proposed box with a new word and a counter sounds easy and clean.

comment:3 Changed 6 years ago by jeanyves

This has been discussed before and username which can sometime consist (or not) with identity of people, are considered as sensitive for some people.

This can be seen as a way to tell publically (pure theory) barrackobama place Chicago is member of bewelcome. In matter of privacy we always have such consideration.

I agree this is not as severe as displaying a private message between two members but they are people who don't expect BW to do so.

About forum displaying Username, I think it is a bit different. A member who does not want to have his username display for public session can choose to post with the option "for members only", however, may be it should be stated more explicitely, at the first post a member does, that his username can be display on public session

comment:4 Changed 6 years ago by crumbking

Summary:

Issue: place application shows profile usernames with a dummy picture of members who choose to hide there profile.

Solution: Remove the non public profiles from the list and add a userbox at the end of every list with "+X additional profiles. Login to view these profiles" if there are hidden profiles on this location.

Note: Don't show the "userbox with counter" while logged in. Instead simply show all members of a place.

Okay with that?

comment:5 Changed 6 years ago by jeanyves

@Manuel: yes, OK with your Summary

comment:6 Changed 6 years ago by crumbking

I guess I have fixed this locally.

There was already a seperation in the code to filter out the non public members. It simply wasn't working (some space in the sql)

I added a userbox at the end with a link: "Log in to see more friedly members"

"X additional profiles" I skipped the idea...

Minor thing: Not sure if the box appears while there are no members in a place.

comment:7 Changed 6 years ago by shevek

Just found the same while working on places rewrite to use geonames (instead of geonames_cache). Could you provide the fix somewhere? (I got rid of the spaces already ;-))

comment:8 Changed 6 years ago by crumbking

  • Milestone changed from unassigned to 1.3
  • Owner set to crumbking
  • Status changed from new to accepted

okay try to push the stuff.

comment:10 Changed 6 years ago by crumbking

There are 2 problems:

1.

  • on regions/places with all members non public profiles: The box does not show up at all.

I need more members in my local copy ;-)

comment:11 Changed 6 years ago by shevek

I don't see any box telling me to login to see more members on neither Chrome nor Firefox (Windows).

comment:12 Changed 6 years ago by crumbking

I see the box on chrome. Make sure you are logged out:

See

comment:13 Changed 6 years ago by shevek

Okay, got it. I didn't understand that you added an extra user that tells you to login to see more.

Nice idea, but I guess the visibility of that is too low to actually work.

comment:14 Changed 6 years ago by crumbking

@Shevek: We had often user confusion why the numbers are wrong. This box will help them to understand why the number is higher. Also as a side effect this will courage potential members to signup ;-)

Replying to crumbking:

There are 2 problems:

1.

should be fixed with:

  • on regions/places with all members non public profiles: The box does not show up at all.

I need more members in my local copy ;-)

should be fixed with:

Please review and move to alpha.

comment:15 Changed 6 years ago by shevek

I didn't say we shouldn't add one. Just that it is not visible enough to gain the effect you hope for.

But what happens if a place has exactly 15 public members?

comment:16 Changed 6 years ago by crumbking

Well don't know. A very unlikely event ;-) Nope you are right.

Do you have an idea for such case in mind?

Again not 15 public members in a place ;-)

comment:17 Changed 6 years ago by crumbking

I found out even 2 more related issues to places:

  • no floating cites
  • we show empty countries, but why?

comment:18 Changed 6 years ago by shevek

Floating cities has been like that since ages and is fix for the geonames update already. Please don't touch that.

Well, 15 or 30 or 45... I'd not add the member on the front end but in the backend. So that the result always contains one member more (the login to see more member).

But that doesn't fix the visibility...

comment:19 Changed 6 years ago by jsfan

Deployed on alpha.

comment:20 Changed 6 years ago by shevek

  • Resolution set to fixed
  • Status changed from accepted to closed

The 'login in...' user shows up only on the last page now.

(Checked locally only: If a list should contain exactly a multiple of 15 a 16th user is added. Doesn't look to nice but isn't outright ugly as well.)

comment:21 follow-up: Changed 6 years ago by planetcruiser

i got to say i am also not a big fan of the "Log in" user. also the hover button frame is a visual element that we don't use anywhere else on the site. talking about ui inconsistency in rox.. ;)

on http://alpha.bewelcome.org/places/FR/Provence-Alpes-C%C3%B4te%20d'Azur for example the link is hardly noticeable. it looks like a bug in fact.

a big button at the bottom with [Log in to see more members] would be much more obvious.

reopen?

comment:22 in reply to: ↑ 21 Changed 6 years ago by crumbking

Replying to planetcruiser:

i got to say i am also not a big fan of the "Log in" user. also the hover button frame is a visual element that we don't use anywhere else on the site. talking about ui inconsistency in rox.. ;)

thought about that, too I will remove the frame and hover effect. easy.

on http://alpha.bewelcome.org/places/FR/Provence-Alpes-C%C3%B4te%20d'Azur for example the link is hardly noticeable. it looks like a bug in fact.

This is another bug because of not floating cities.

a big button at the bottom with [Log in to see more members] would be much more obvious.

just leave it for now as shevek reworks the whole places app anyway...

reopen?

yeah but just for the styles

comment:24 Changed 6 years ago by shevek

  • Resolution set to fixed
  • Status changed from reopened to closed

Deployed on alpha. Styles are removed. Closing.

comment:25 Changed 6 years ago by planetcruiser

  • Cc mahouni added
  • Milestone 1.3 deleted
  • Resolution fixed deleted
  • Status changed from closed to reopened

i still think this is very bad usability. it's kind of funny, but it can be too easily overlooked. one quick fix would be a big question mark instead of the teddy and linking all 3 lines, so it's easily distinguishable.

i suggest to fix this for 1.4.

comment:26 Changed 6 years ago by planetcruiser

  • Milestone set to 1.3
  • Resolution set to fixed
  • Status changed from reopened to closed

ok, since the original issue of this ticket is fixed, i created a new one for the usability bug: #1881

Note: See TracTickets for help on using tickets.