Data Safety/Data Safety Consultation Meeting Notes/2011-10-28

Data Safety Consultation Meeting Details

• Friday, 28 October 2011
• Location:

Project(s) for Review: BrowserID

Agenda

• BrowserID Design & Implementation Consultation

Action Items

Discussion Details

Data Safety Review - BrowserID

1) Current State of BrowserID

• Objectives & Requirements
  1. What are the goals behind BrowserID?
     • To let users log into web sites easily and quickly, by delivery of a verified email address. Over time, this should also let users easily deliver repeated attributes to web sites, when they so choose.
  2. Who are all the stakeholders involved in BrowserID?
     • The identity team, headed by Dan and Ben, lead the product
     • the apps team is an important customer
     • B2G is likely to be an important customer
     • Many Mozilla web properties will be customers, starting with AMO / Appstore, but also Mozillians, EtherPad, Bugzilla, etc. eventually

• User Data Requirements
  1. Identifiers?
     • email addresses (Stored on Mozilla server)
  2. Attributes?
     • BrowserID Password (decrypted)
     • Random user ID associated with email address
     • History of IDs and sites used
     • none yet, but soon profile photo, name, shipping address, and the like
  3. What about data related to sites and accounts?
     • Storing on our servers the sites that have verified your BrowserID (e.g., this person has a Google verified BrowserID)
  4. Justification for these identifiers and attributes? Are there alternatives?
     • We store only the data that users want to deliver to multiple web sites over time. We store it on the server so users can have that information on all of their machines. We could store this with a third-party provider instead of with us, though that seems worse. We could eventually store attributes encrypted, though this would likely require a second password for users to type. We could store email addresses hashed, which would provide *some* defense against simple perusing of a leaked dataset, but wouldn't be very much protection against a somewhat determined attacker. We have not come up with a solution to encrypt the email addresses, since an important use case is that a user should be able to log in with any of his email addresses.
  5. Anticipated volume?
     • The plan is to store plaintext passwords in our Mozilla hosted databases. Need to allow way in without any other data other than email address to use this data to log a user into a site.
     • Next 3 months is to add simple profile data (photo, etc) that would be at the user's control to add/use.
     • Ability of user to auto-authenticate to a particular site, e.g., "keep me signed in" (may be simultaneously activated on other devices using the same browserid account)

• User Choice & Control
  1. Privacy policy & contextual notices?
     • We have a privacy policy and ToS designed by the legal team, though they may need updating when BrowserID goes into the production environment and we ramp up the deployment.
  2. Account & data deletion?
     • Users can delete their account at anytime. No trace of their data remains in the database. We do not have a complete backup strategy yet, and we will need to consider the retention vs. deletion issue.

• Third Party Partnerships, Customers & Providers
  1. User data sharing and/or access?
     • A user email address is shared with a web site when it asks for it, and when the user consents by clicking "sign in". The user sees exactly which email they are disclosing. We may add a "remember me" feature that lets a specific web site request the user's email transparently until the user chooses to remove that web site from the list of automatic sign-ins.
  2. Customer risks (e.g., sites using BrowserID that create risks for Mozilla)?
     • Not sure I understand this question?
     • Rephrased: Can providing this service to third party sites open our customers/users to new risks?
  3. Jurisdictional considerations (e.g., transborder data flows)?
     • Need input from Policy folks on this point

• IT and Data Infrastructure Considerations
  1. Data retention plan?
     • Not sure what this is yet, will investigate
  2. Backup processes?
     • Not sure what this is yet, will investigate
  3. Access controls?
     • Moving to production environment with access control handled by the Service Ops team, only operations teams have access to the database.
  4. Jurisdictional considerations?
     • You tell us :)
  5. Security monitoring?
     • Service Ops production-level monitoring
     • Built-in application layer security monitoring from InfraSec
  6. Logging practices?
     • Service Ops logging, to be reviewed by Privacy
     • Our logging is limited, already reviewed by Privacy, yielding the following metrics: https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=metrics2&path=identity/&file=identity.wcdf

2) BrowserID Specific Questions

1. Are there design decisions being discussed that would materially change the user data picture presented above?
   • Yes. We are talking about adding attributes beyond the user's email address. Consent would remain the same, user opt-in at all times. We are also talking about remembering sites with which users want to be always logged in. We are discussing implementing these features by obfuscating the data as much as we can, e.g. keyed hashing of domains where a user is always loggedin. We have not yet considered full encryption of this data.
2. What, if anything, should we do to limit our visibility into implementing sites and users behavior during initial BrowserID implementation where we are running all parts of the system?
   • We have taken the approach that we know relying party activity, but we are very careful to discard user-level activity. So we know that X users have logged into an RP in a given hour. But we throw away the information about which users those are.
3. What's the timeline for a BrowserID Firefox add-on?
   • Beta this quarter.
4. What's the plan for including profiles with BrowserID?
   • Q1
5. Has BrowserID undergone privacy and security reviews?
   • Yes, ongoing
6. What's the plan for long-term governance of BrowserID?
   • The Identity Team will continue to own it, and will continue to make all decisions publicly. Our mailing list is public, our code is public, etc.

3) Links to BrowserID Documentation (please supply)

• Useful semi-technical intro: http://lloyd.io/how-browserid-works
• Protocol docs: ___
• Consumer facing site: http://browserid.org/
• Web-dev implementor facing site: https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site

• [DA: Not sure where this fits in this document or stage of the process, but I think it would be good to document the existing alternatives for users and web developers, so we understand the opportunity & the consequences of not going ahead w/ a particular project]
• Market context: Facebook Connect, Twitter Login, OpenID = solutions based on proving you are some kind of identifier. BrowserID aimed at fixing UX and limiting user data. Direct user value of BrowserID will be around managing multiple IDs. Just starting to talk with identity providers about ways to partner and provide support for BrowserID.
• Would be useful to conduct an analysis to compare and contrast BrowserID from other ID mechanisms on user data considerations, including data requirements, privacy and security.

Follow-up Discussions

Attendees

Ben Adida (BrowswerID), Dan Mills (BrowswerID), Alex Fowler, Tom Lowenthal

Declined
N/A