844269 - Privacy Product Review: Mozillians Profile Privacy Controls

Status: RESOLVED FIXED

(Privacy Graveyard :: Product Review, task)

Description

[Justin Crawford [:hoosteeno] [:jcrawford]]

We used the new project kickoff form to build bug 843870, but it wasn't able to create the blocking bugs. So I'm creating them manually.

Can you look at bug 843870 and advise whether legal review of this feature is necessary?

Comment 1

[Justin Crawford [:hoosteeno] [:jcrawford]]

In the above comment, I meant "privacy review", not "legal review".

Comment 2

[Stacy Martin [:stacy]]

Hi Justin - yes, this will need a privacy review.

Comment 3

[Stacy Martin [:stacy]]

Oops, meant to add my notes from our meeting yesterday as well:

*goal is to allow promoting various fields to be more public than they currently are
*not changing any privacy levels for users, but they can opt-in to make it more public; none will be public by default
*users have asked for showing people how they are involved 
* opt-in for name and picture to be public, IRC name or email address, etc.
*if at least one item is marked as public, will appear in public search results
* may want to add notice on the downfalls - per field caveats - ex - making email public can lead to increased spam, etc.
*may make some fields ineligible
* next step - file a privacy bug using kickoff form (done)
*timing - Q1 goal - end of March
*feedback that people want these features - won't be a surprise
*do have newsgroup list to post the discussion

Comment 4

[Justin Crawford [:hoosteeno] [:jcrawford]]

Thanks Stacy. 

This bug relates to the technical review -- I opened a separate one for the policy review. Let me know what information I can provide.

Our target launch date is 3/28/13. It's a tight timeline; if there's any part of the review we can do prior to the code being built, I'll be quick to help with it!

Comment 5

[Stacy Martin [:stacy]]

Ah OK, I'll reassign to Tom then.  Do you recall the bug # for the policy review?

Comment 6

[Justin Crawford [:hoosteeno] [:jcrawford]]

The policy review bug is here: bug 844272

Comment 7

[Justin Crawford [:hoosteeno] [:jcrawford]]

This project is moving forward. We hope to have code done by mid-to-late next week (3/17/13) in the hopes of a launch the following week. Please get in touch if there is any information I can provide in the meantime to help with this review.

Thanks!

Comment 8

[Justin Crawford [:hoosteeno] [:jcrawford]]

The interface for privacy controls has landed on the dev server. This is just the interface: The backend code is not complete. In other words, you can't actually submit changes and have them be saved in the database or have them apply to viewers. However, I think the backend functionality is explained fairly well by the interface.

1) Here is the interface where users will edit their privacy settings. There are settings on several tabs:

https://mozillians-dev.allizom.org/en-US/user/edit

2) You'll also want to see the profile view interface; we added a dropdown there that lets users see their profile as if they were members of a particular group. To get there, click on your username at the top right and choose "View Profile".

Your feedback is welcome!

Comment 9

[Stacy Martin [:stacy]]

Thank you for providing the visuals.  They look great - very intuitive.  A couple questions.
1) My profile view doesn't change when I switch between myself, Mozillians, and public.  Is that just because it's still on the dev site? What will public look like if I have all my profile fields set to Mozillians?  Will it be a blank page?
2) It looks like there's a privacy setting where you can change all the fields at once to either Mozillians or Public.  It also has a setting called "No Change" - is that the default, and also the setting if I have some fields set to public and others set to Mozillians?  It's a little unclear what's considered a profile field and what isn't.  (for example vouches and invites), but it can be inferred as the fields that have the choice boxes next to them.
3) If I had anything in the Vouched section, it would be the name of the person who vouched me, right? I assume we don't enable making that public (to protect the other person's privacy), is that correct?  

As an aside, I noticed that the "file a bug" link for Developers under the Services tab goes to product "data safety" which we are eliminating.  I think it should go to our new Project Kickoff form at https://bugzilla.mozilla.org/form.moz-project-review, but I'll check with Michael Coates to be sure.

Comment 10

[Stacy Martin [:stacy]]

Per Michael Coates: Yes, please update this to point to the project kickoff form.

Comment 11

[Justin Crawford [:hoosteeno] [:jcrawford]]

Great comments/questions. Thanks!

Regarding questions in comment 9:

1) There is no backend functionality now to enable this. It will be on the dev site soon! If you change it to public and have no fields visible, your profile will look quite empty. There will be some headers for the data that is not visible.
2) Your assumptions are all correct. That's good feedback!
3) The vouched data will be visible to all Mozillians. It cannot be modified.

Regarding comment 10: 

We're going to create a new component in the Community Tools module for API requests.

Comment 12

[Stacy Martin [:stacy]]

I'm going to close out this bug for the privacy controls.  I've reviewed the UX, and have added an update for the privacy policy (website policy - contributor section).  Functionality is opt-in.  This is fine to implement by end of Q1 from a privacy perspective.

A central way that your contact information is collected and made available is through your profile on the Mozilla Community Directory [https://mozillians.org/en-US/]. All vouched Mozillians have access to the Mozilla Community Directory and you can enable greater visibility through your Profile Settings [https://mozillians.org/user/edit].