Data Safety/Data Safety Consultation Meeting Notes/2012-02-14

Data Safety Consultation Meeting Details

• Tuesday, 14 February 2012, 9.00-10.00 AM (Pacific)
• Location: SF / Vidyo

Project(s) for Review:

• Open Badges Infrastructure
• Mozilla Marketplace

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

This list includes all items from this initial Consultation meeting with the product teams and from all follow-up discussions (see Follow-up Discussions section below for additional meeting notes/details).

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

Project Reference: Open Badges Data Safety Questionnaire

About the Project:

• 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.

Data Requirements: 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.

Functionality / Design:

• We’re providing a mechanism that people will store ‘backpacks’ with their badges. 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.

Privacy Policy: Not right now. Need to create this. Plan was to copy Browser ID's for now. Jishnu is working with someone on this.

Backpack deletion?: Users can remove all badges, but not the account wholesale.

Launch strategy: Desire to move this to the Labs cluster.

Deadlines: 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.

Marketing / Engagement view: 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?

Legal view:

• 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.

Identity view:

• 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

Project Reference: Marketplace Data Safety Questionnaire

• Last discussion on Marketplace: 01 Sep 2011

Current status: 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.

Timing: First consume-facing beta at end of March. Launch by end of June.

Data requirements: 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.

Personalized recommendations: 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.

Data flows to developers: 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.

Vendor selection: 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.)

Follow-up Discussions

Meeting notes for discussions subsequent to the February Consultation meeting:

17 February 2012: Data Safety follow-up discussion for Marketplace.

23 February 2012: Data Safety follow-up discussion for Open Badges (1 of 2).

22 March 2012: Data Safety follow-up discussion for Open Badges (2 of 2).

Attendees

Ben Adida, Alex Fowler, Brendan Eich, Michael Coates, Chris Beard, David Ascher, Jishnu Menon, Jay Sullivan, Johnathan Nightingale, Sid Stamm, Brian Brennan (Open Badges), Justin Scott (Marketplace), Ragavan Srinivasan (Apps/Marketplace), Alina Hua, Tom Lowenthal, Harvey Anderson

Declined
N/A