Data Safety Consultation/2012-02-14: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "'''Data Safety Consultation Meeting Details''' <BR> * Tuesday, 14 February 2012, 9.00-10.00 AM (Pacific) * Location: SF / Vidyo == Agenda == * Review Process Update (10 mins.)...")
 
(Blanked the page)
Line 1: Line 1:
'''Data Safety Consultation Meeting Details''' <BR>
* Tuesday, 14 February 2012, 9.00-10.00 AM (Pacific)
* Location: SF / Vidyo


== Agenda ==
* Review Process Update (10 mins.) - 9.00 - 9.10AM
* Data Safety Review: Apps Marketplace (25 mins.)  - 9.10 - 9.35AM
* Data Safety Review: Open Badges (25 mins.) - 9.35 - 10.00AM
== Action Items ==
Data Safety Team:
* Discuss as a group follow-up activities that will be helpful to Open Badges. Continue to work with them for further development.
* Discuss as a group additional clarifications needed and follow-up with Justin and Ragavan with action items for Marketplace team.
* Finalize notes and post to Governance for input.
== Discussion Details ==
=== Review Process Update ===
* Post summary of minutes to wiki / Governance for public comment for 2 weeks. Clean up wiki, but continue moving with Governance.
* Assuming people are comfortable, then move forward.
* Alex to write blog post and pair this with documentation.
* Both projects are in development - how to go to Governance at this point. Need to think about:
** How to capture / document decisions made based on best practices: We're at point of needing to retroactively document decisions made, problem statement, options available to us, criteria imposed, privacy policy, legal considerations, etc.
** How to communicate in a way that gets buy-in, doesn't ignore people's opinions and doesn't set us back.
=== Data Safety Review - Open Badges ===
<u>About the Project:</u>
* What is this:  Infrastructure to award achievement online
* Current status: 
** Private beta: 3-4 parties involved
** Not many users in the system now. Probably in the 10's. 
** Currently, managing one identity per dashboard.
<u>Data Requirements:</u> Data collected is user email address, using BrowserID for authentication, and in the badge, there’s one URL that can have PII.
* Criteria URL – tells where the end points are, don’t really know what’s there.
* Trying to store as little data as possible.
<u>Functionality / Design:</u>
* We’re providing a mechanism that people will store ‘backpacks’ with... No way to control what the issuer is putting in the backpack
* All badges go in as private and user has to make the badge public to say it’s okay to share.  Nothing is public by default.
* Metadata about the achievement is encoded inside of the image.
* Designed so that anyone can run this anywhere.
* Even if badges are public, there's the possibility that one can have 3 separate identities on the web. If there's any way for those personas to be correlated, that could be problematic. Does this risk exist? Your achievements over time provide a lot of info.
<u>Privacy Policy:</u> Not right now. Need to create this. Plan was to copy Browser ID's for now. Jishnu is working with someone on this.
<u>Backpack deletion?:</u> Users can remove all badges, but not the account wholesale.
<u>Launch strategy:</u> Desire to move this to the Labs cluster. 
<u>Deadlines:</u>  None that are set. People are going to start looking a little more closely at this toward the end of March. Desire to get this up as fast as possible.
<u>Marketing / Engagement view:</u>  Doesn't sound like there's sensitive user data, thus potentially low risk.
* Q: To the extent that badges are available to kids 13 and under - need to  have set of permissioning that involve parents. Do we take this as a compliance issue for 13 and under in the US? Or 18 and under?
<u>Legal view:</u>
* COPPA  strategy for Badges in process. Not doing under 13 b/c infrastructure would need to be built out. Would need to think about whether Browser ID would be the best service. Timeframe for the launch would not match up. Education is just one use case, but Badges could be issued for anything.
* Other  big issue that came up:  FERPA - privacy law for financial info for  college students. Applies to the large institutions that want to  implement OB. If they violate law, they can lose funding.
<u>Identity view:</u>
* Correlation across DBs is maybe one of the biggest issues we're going to deal with.
* Need to above and beyond to communicate to users about what we're doing with data.
=== Data Safety Review - Marketplace ===
* Last discussion on Marketplace:  01 Sep 2011
<u>Current status:</u> Goal: Bring HTML5 apps to the world. Running AMO for 6-7 yrs as a free apps store of sorts. Leveraging knowledge /experience to build apps store with payments feature / capability. Planning a developer reg milestone for a week from now where developers can reg and submit apps for real. Will be a much better experience for developers.
<u>Timing:</u> First consume-facing beta at end of March. Launch by end of June.
<u>Data requirements:</u> User can give little / lot of info about themselves (e.g., bio, location, create content, write reviews - spectrum of participation levels). 
* Data collected behind the scenes:  Add-on usage - number of pings / data in aggregate is collected. Pings are not correlated and stored with user account info right now. We do offer personalized recommendations to Firefox users, but not tied to user accounts.
<u>Personalized recommendations:</u> List of users' AddOns installed are used to personalize recommendations. For Add-ons, no plan to change process.
* In the case of average Firefox user - we currently offer recommendations
* For users who are logged in, we will start recording purchases and can make recommendations based on that * Can download Add-ons w/out an account. Can't download Apps w/out an account.
* Q: Similar to Amazon, can we give user the ability to forget an association? Give the user control over what profile data is available?
* Q: Are we using same DB infrastructure for Marketplace as what we're using for AMO? 
** YES.  Everything AMO is becoming Marketplace - it'll be all the same. 
* Q:  Concerns about migration (e.g., for people who have existing accounts on AMO being opted into Marketplace)? 
** Privacy policy change in process. 
** We're collecting less data in general. Browser ID used for Marketplace - users don't have to fill out anything else.
** For existing members converted to new system - they won't have Browser ID accounts by default. They'll still have their AMO accounts, but will need to upgrade to a Browser ID account eventually.
** If anything, data collection will be reduced.
<u>Data flows to developers:</u>  Our difference - like a farmer's market - developers themselves are selling their apps (e.g., users visit the developer's stall). Reflected in financial and visual aspects. Users have direct relationship with developers who serve as merchant of record.
* If it's a paid app, developer will know info from PayPal or other payment system: email, shipping address, name. Receipt is validated with email.
* Aggregate stats for number of users, which type of device is used, etc.
<u>Vendor selection:</u>  Working with Legal now.  PayPal is confirmed - agreed to privacy addendum and contract. Zong - potential provider (PayPal company). Stripe - local web 2.0 payment startup (not far along with them yet) would not come into play until after launch.
* Concerns for earlier review (e.g., PayPal: They have a bad reputation of mishandling their merchants, lots of people unhappy with them.)
== Attendees ==
Ben Adida, Alex Fowler, Brendan Eich, Michael Coates, Chris Beard, David Ascher, Jishnu Menon, Jay Sullivan, Johnathan Nightingale, Sid Stamm, Brian Brennan, Justin Scott, Ragavan Srinivasan, Alina Hua, Tom Lowenthal, Harvey Anderson
'''Declined'''<BR>
N/A

Revision as of 02:42, 29 February 2012

Retrieved from "https://wiki.allizom.org/index.php?title=Data_Safety_Consultation/2012-02-14&oldid=402205"