Data Safety/Data Safety Consultation Meeting Notes/2012-03-15

Data Safety Consultation Meeting Details

• Thursday, 15 March 2012, Noon - 1.30PM (Pacific)
• Location: SF / Mountain View / Vidyo

Project(s) for Review:

• Lovebomb
• Betafarm
• Push Notifications

Agenda

• Intros / Process Overview (15 mins.) - Noon - 12.15PM
• Data Safety Review: Lovebomb.me (25 mins.) - 12.15 - 12.40PM
• Data Safety Review: Betafarm (25 mins) - 12.40 - 1.05PM
• Data Safety Review: Push Notifications (25 mins.) - 1.05 - 1.25PM
• Wrap-up / Confirm Action Items (5 mins.) - 1.25 - 1.30PM

Action Items

Start-Dt	Owner	Action Item	Due-Dt	Status	Comment
15-Mar	Lovebomb team	Search engine indexing: DISALLOW for search engines. Implement robots.txt to disallow indexing by search engines (except for landing page). This should ensure that all URLs pointing to user-generated cards are not indexed by robots.	n/a
15-Mar	Lovebomb team	Legal review: Follow up with Legal Review (Jishnu) and details / issues around COPPA.	n/a
15-Mar	Lovebomb team	Security improvements: Make improvements to public function (e.g., 10-minute grace period to UNDO after making card public). Lovebomb to figure this out with Security team (Michael).	n/a
15-Mar	Betafarm team	Create notification / text to ensure users know that their email may be used to contact them.	30-Mar	In progress	David/Ben drafting text.
15-Mar	Notifications team	Identify customers from BTG to help crystallize the requirement to help better define user benefit.	25-Apr
15-Mar	Notifications team	Determine whether to use encryption or not.	25-Apr
15-Mar	Notifications team	Need Security review	25-Apr	In progress	Sid to review
15-Mar	Notifications team	Need to determine audience / customer (i.e., who we're selling this project to) and attain more customer validations	25-Apr

Discussion Details

Data Safety Review - Lovebomb

Project Reference: Lovebomb Data Safety Questionnaire

Questions / comments from Privacy / Alex via email (and Lovebomb's response in italics):

• Can people upload/link to their own photos and images in making their cards?
  • I believe not -- that we'd figure out a library of photos/images (perhaps CC licensed or something) that we'd allow people to work with, rather than embedding their own.

• Is it possible for the major search engines to index these cards? If so, can we prevent that from happening? People may not appreciate these cards being found and linked to them via searches executed by others (e.g., coworkers, recruiters), and that could defeat our plans to remove the cards in the future.
  • Haven't a clue. David? - yes, need to setup robots.txt [bug to file]
    • Per DS Consultation: Yes, possible for search engines to index, but won't retain if online for onlyy 30 days. Unlikely to be linked to people's names. For further discussion: DISALLOW for search engines. Trivial to stand up, but question of whether to do this or not.

• I saw on the wiki that there's discussion of making a quilt from the cards. Are there implications if the photos are personal, depict young kids, or are inappropriate?
  • Hopefully this is dealt with from the first answer. The specific implementation of the gallery is definitely very TBD, though -- the basic idea of being able to see what others have done and fork it is what's important.

• For kids 13 and under who decide to make cards for their moms, we should not ask for their email address. An email address is considered PII under COPPA and their are specific restrictions we'll have to address to enable that feature. I think we have to seriously consider how this campaign may mostly attract kids and teens, as opposed to young adults and adults. As building our database appears to be a secondary objective, I'd strongly suggest we remove it. Perhaps we add a link to "Learn more about Mozilla" where people can find a way to subscribe to our mailing list.
  • Email won't be demanded in order to make or send the card -- is it really problematic to have it in the footer or at the end of the process just because some of the users might be under 13? Isn't that true of pretty much everything? The campaign is definitely designed for everyone (or, at least everyone with someone to send something to on Mother's Day), so I'm not really seeing why that's any more necessary here than with anything else we do.

• It would be good for the card making interface to include some guidance that reminds people that their cards will be public, and that they shouldn't use first and last names together or place other personal data in the body of the cards. Also, we should encourage people to keep the content clean. This could be a brief contextual privacy policy on the page or a confirmation step before sending/publishing the card.
  • Definitely.

• In terms of a go/no-go decision, if we take out the email signup and unless the discussion tomorrow uncovers other threats and/or back-end data collections of user data, then I am a GO with this as a Mozilla-sponsored activity and believe we are acting in an accountable, responsible and ethical manner from the perspective of user data, privacy and security.
  • The e-mail option is not so much secondary, as it is an additional goal of the program. We're trying to build a movement of people who want to become makers on the web, and giving them a way to connect so we can invite them to participate further in the future is an important part of it. If we can find a way to address the issues of PII, it would be ideal to keep the sign-up. Very open to suggestions to make it work.

Discussion
About the Project:

• If you email the URL around, anyone can access it. URLs are hard to guess - randomized.
• Anyone could fork it - just HTML - bottom of each card has a 'click here' to remix the card and make it your own. This could potentially toggle on / off.
• User gets template to edit a local copy and can publish it with custom URL that can be sent around. Works exactly same way as Hackasaurus.
• Once you publish, it can't be edited by the creator - it's a snapshot in time.
• Once it's public, it would publish to discoverable gallery to see what others have made.
• Expiration: After 30 days - can change if needed

Security Review: Not yet - hasn't been coded yet.

Legal Review: David contacted Legal already - in process

Concerns:

• Need to create some way for people to email us to request to have the card taken down. No option for this right no. No way to verify who made it. Could have a policy stating that
• Email: Hope to have a link to "email to my mom" - emailing the link only, not the card. This may collect email addresses. Potential issues:

1. footer - 'get updates / sign-up
2. sign-up for updates
3. mail-to link, but this wouldn't be designed as an email capture

COPPA: Is this product appealing to kids under 13? Theoretically, kids may want to use this to create cards for their mom.

Launch date: 01 May ideally (06 May is drop dead date) (Mother's Day is 13 May)

Technical info: Can edit HTML on the page - limited though - only certain pieces / sets to choose from.

• Javascript? NO.
• Arbitrary image tag? NO.

User Benefit:

• Educational - similar to Hackasauraus
• Empowerment - audience is pretty mainstream who have never touched code, helps to open the door that code is not scary, you can be an author of the web. Core to what they're trying to do.
• Make something cool for mom for Mother's Day and learn code along the way.
• Blogged in various places - universally positive feedback

Data Safety Review - Betafarm

Project Reference: Betafarm Data Safety Questionnaire

Questions / comments from Legal / Jishnu via email (and Betafarm's response in italics):

• You might have a bit of work to do implementing Persona from a compliance perspective as some of the kinks are still being worked out. Need Legal review.
  • (scheduled for monday with Jishnu)

Questions / comments from Privacy / Alex via email (and Betafarm's response in italics):

• I am basically fine with the way in which data about project participants is displayed in Betafarm. It does seem like a bit of shame that we can't connect this with the Mozillian phonebook, since it's likely that the same people will have to enter and maintain similar profile data twice, and it would be great if the Betafarm projects showed up in your Mozillian phonebook profile. Would that be possible? Sensible?
  • (mozillians not ready for this, double-checked with Aakash this morning.)

• Does the Betafarm site allow a prospective user to register to directly access, use, or engage with a piece of software or app? I don't think so, but am asking because that could lead to additional user data collection, etc.? I'm assuming profiles will link to project sites that may have their own user data, privacy and security considerations, but that isn't what we're focusing on with Betafarm, right?
  • (correct we do not allow this)

• We don't need a separate privacy policy for this, as the general Mozilla site policy should be adequate, assuming the answer to the second question above is "no." It would be good to include some language on the forms used to generate a profile that data will be public.
  • (agreed we can add)

• Assuming we're only focused on the limited profile data about the contributors working on a project, then I am a GO with this as a Mozilla-sponsored activity and believe we are acting in an accountable, responsible and ethical manner from the perspective of user data, privacy and security.
  • (Woo!)

Discussion

• Ben Sternthal is filling in for David Ascher.

About the Project:

• Replacement for MozillaLabs.com - called Betafarm, but still called Labs too
• To be a directory of projects to be linked from elsewhere
• Blog portion is moving to main Mozilla blog - actually keeping separate blog
• Sign in through Persona. Public could sign in as long as there's a Persona ID. Can create profile that can be displayed to the world. Active reason: For people to be associated with projects with ID / photo etc.

Data to be collected: avatar, display name, bio, etc. (see Questionnaire for more details)

• Collection of user email address through Persona: Possible David has some idea for this. Ben to check on this. If they ever intend to use email to notify users, must say this upfront.

Scope: Exposing labs, labs people, what they do, all public. Message to users will be that it's their public profile.

Security:

• Info entering on Betafarm site is double-entry if people have already entered info on Mozillians, to pull data from - but aiming for Q2 to do this. Issue is that Mozillian data is not public data.
• Only admins can create projects.

User Benefit:

• For Labs employees / community folks: Get word out to explain what they do, like public bragging page. Links to a lot of other important pieces of info (e.g., Github).
• For people who watch projects: Will be able to see all project through a dashboard - can collect all in one place. No collection of activity from 3rd parties. Fairly minimal now, but this may change.

Dates: Rollout at end of March / early April.

DST perspective: This project seems fairly non-controversial and is clear for what it's providing / doing.

Data Safety Review - Push Notifications

Project Reference: Push Notifications Data Safety Questionnaire

Questions / comments from Privacy / Alex via email (and Push Notification's response in italics):

• How customizable and personal can messages be? Could they include personal data that might surprise a user or another person using a friend's machine?
  • It's up to the site, but they can be highly personal. Our API exposes a 1:1 channel between the site and the user.
  • I believe it is certainly possible for a user to provide personal information after the URL is exchanged. We do not provide any user information outside of the link URL. It might be equivalent to having a Google Calendar event of "Punch Friend in Nose" appear. (IOW: It's certainly possible for people to do dumb things with our tools) What sort of scenarios are you thinking of?

• Could a site set a cookie via a push notification?
  • That should not be possible. A notification is a blob of text, not a full webpage.

• Could a photo or file be sent via a notification? I'm asking to just get a sense of the range of data types that could be sitting on our servers.
  • Notifications have a small size limit (1024 bytes) so there's not space for photos or files. You would send a notification with a link to a photo, not with the photo itself.
  • It is possible to pass a cookie along with the image link. The link should be a FavoriteIcon type image associated with the notification. Setting up a proxy to handle image fetches would increase the server requirements.

• Will push notifications work with In Private Browsing mode?
  • I don't know. If you're in Private Browsing do you still want to get notifications from your normal browser persona?
  • I would opt for no notifications during Private Browsing. --jr

• What is "archival residue?"
  • Server logs. It's always possible to datamine associations from server logs. This is why we offer the ability for users to run their own server.

• What would happen if our server storing messages was compromised? What impact would that have to the user and to Mozilla, especially if we may not have a good idea of all the use cases and message types running through our system? Are there things we can do from a technical perspective to obfuscate message content stored on our servers that limit our ability to access and read it?
  • The attacker would be able to see:
  1. Messages from websites to users
  2. The secret URLs used to connect websites to users
  • #2 would be the most concerning issue, since the attacker would be able to send messages to users posing as a website they trust.
  • The original specification include the ability to encrypt message for delivery to a specific reciever. Encrypted messages were not made default because of third party transfer issues (e.g. sending a notification to iOS or Android would require decrypting the message before transmission)

• From a data retention perspective, 3 days seems reasonable, but how did you arrive at that length of time?
  • We needed a number and 3 sounded reasonable. We're presuming that the messages are somewhat time-sensitive, and that their usefulness drops off as they sit in storage. 3 days is an arbitrary cutoff.

• How will authentication data (users' email addresses) be stored together with the messages? Are their other risks to the user and Mozilla because we run both the Persona and push notifications systems that we should consider?
  • Your auth data will link you to the bucket with your messages inside. Tokens are generated from the Token Server https://wiki.mozilla.org/Services/Sagrada/TokenServer.
  • If the token server is also compromized, it would be possible to determine associations.

• Is there an opportunity to surface data and privacy controls for the user related to this service?
  • We will have a pref pane that lets you mute or disable messages from any of the sites you have authorized. Changing to use your own notifications server would be an about:config change.

• For messages that we send to a mobile device, do we need any other data types to make that connection (e.g., device IDs, carrier information, phone number)?
  • No. On devices like B2G and Android, our client will connect to the server. On iOS we get an opaque token that maps our service to a device.

• What,if any, relationship will we have with the third party sites using this service? Will there be a TOS or other contractual mechanism to limit certain use cases?
  • For most sites, there will not be any setup flow; they'll just start sending messages to us.
  • For large sites like Twitter and Facebook who could be sending tons of messages through us, we may need to set up special flows to handle their load. That could involve contracts and money to help us support the service, but that's only speculation at this point.

• From a security perspective, who will have access to the servers storing messages? Should there by access control mechanisms?
  • Services Ops would have access to the servers. They don't give devs access to production servers.

• In terms of a go/no-go decision, I will need to hear more about the Data Safety Team's reactions and feedback before I can confirm that I'm a "GO." From what I understand at this moment, I do believe this is useful service and that we can address user data, privacy and security considerations in a meaningful way that will be consistent with our principles.

Discussion

• Jeff = principal engineer

Data collected:

• Based on Firefox sign-in through Persona. We'll give site a URL where they can contact user. Each site will get a different URL. Biggest piece is authentication URLs. We would have email address for user.
• Site would probably know who you are because you're signed into FB when providing push notifications

Notifications:

• Do we do anything to avoid coming into contact with notifications? NO. they come to us directly.
• Notifications usages examples: From Github, would want to test / fail, for games,, etc.
• Text of notifications is non-content, used as a hook to follow link to something. Think of it like Twitter. Could use it like content of the message.

Hand-off issue: iOS and Android can't handle encrypted content. We'd have to decrypt the message and pass it on to iOS and Android. Not necessarily Firefox.

Current customers: 2 channel customers: BTG and WebApps

• What is the product driving this architecture? Not generic.
• Push Notifications for BTG and Firefox.
• On iOS, we'd push to Firefox Home - whatever that user agent looks like on that platform.
• This may be hard to get adopted on desktop.

Encryption: Not really interested in introducing a whole lot of encryption on this because it'll hinder developers.

• Team should consider encryption so they don't have access to raw data. A year ago, the original concept did have encryption from end-to-end. If going back to this, need to make UI simple enough for adoption.
• Risk analysis: If we don't use encryption, need to talk with Legal. It's 3rd party provided data.
• Encryption issue: Potential option - PersonaID scaffolding service.

Scope: Delivery of data to non-Firefox endpoints in scope? If so, this changes requirements. For Jeff, it's not in scope. JR agrees with Jeff, happy to take it out of scope for now.

Data retention: Up to 3 days if not connected. Only purpose for holding data is to transmit it to the user.

User Benefit:

• Get notifications from sites rather than via email (e.g., Groupon could be brought to the web rather than native apps to achieve notification alerts).
• No need to have direct web page, no longer have lag, privacy concerns, security benefits (e.g., don't have to stay logged in to FB all the time).
• Open standard / open web compatible.
• Benefit for web sites - can make an API for every platform.

Customer on BTG:

• Who's helping to drive this? NONE right now. Need to fix this to get more customer validations. Chrome put out a video yetserday about what their intent to send notifications for Chrome. Has been validated for iOS and Android, Ubuntu
• Are there discussions with developers for running this for Telefonica?
• JR views this as the way email was originally created - very platform specific at the start. There is no value from major stakeholders to create platform independent effort.

Dates / Timeline: End of Q2 - developer preview state (pending resolution to other issues today).

DST perspective: Very concerned that this isn't a product. It's hard to determine who we're selling this to and whether there's enough product direction or not. Need to have coherent product idea.

Follow-up Discussions

• N/A

Attendees

Data Safety: Ben Adida, Sid Stamm, Tom Lowenthal, Alina Hua, Michael Coates
Betafarm: Ben Sternthal
Push Notifications: JR Conlin, Jeff Balogh
Lovebomb: Ben Simon, Ryan Merkley

Declined
David Ascher, Alex Fowler, Jishnu Menon, Mitchell Baker, Johnathan Nightingale, Chris Beard