Security/Reviews/Firefox6/ReviewNotes/telemetry

Date of Review: 2011.05.20

Item Reviewed:

• Telemetry (Feature Page)
• Telemetry Privacy Review

Notes

• API used to add probes can abort--must have test coverage on all these code paths, to prevent DoS attacks that force abort.

• Thread safety of API needs to be clearly documented for future callers.
  • No probes off the main thread right now
  • Might be races from multiple threads
• As we add probes to telemetry -- e.g. someone wants to measure number-of-tabs-open
  • security & privacy folks should have a chance to give input
• If a user has both Test Pilot and Telemetry enabled, will we [be able to] correlate between them?
• Is it a problem if web pages can fingerprint your telemetry, e.g. by causing a cycle collection pattern?
• How much data is being sent per day?
  • Currently 6 probes so only 6Kb (times 150million people?)
• What about addons (even our own) that want to participate in data collection?
• This data should include an assessment of privacy/sensitivity of data, a clear description of what data is actually sent to the server, and a pointer to the privacy review.
• Stats are not reset between private browsing mode changes - follow up bug. Clear recent history.
  • You can see the telemetry data in the UI, which is why the data needs to be reset.
• Assumption is that telemetry isn't present in crash-stats
• Timing attacks possible on key-matching/password-matching. Should document that probes are not to be used after a password/key-matching check.
• Addons may want to participate in this -- raises issues about getting them data, swamping our servers, etc.
• Addons can cause telemetry data to be redirected.
  • Need to add our telemetry prefs and the API for this to the AMO security review filter. Also for now should not want them to add probes until we work out the issues.
• Make verifier check for toolkit.telemetry.enabled, toolkit.telemetry.server changes to all.js. to ensure telemetry settings don't get highjacked -> bug 658735

• Data is all sent over HTTPS to a mozilla-controlled server.

First-run opt-in UI

• Infobars look like part of the page--that's why we're getting rid of them. It seems like it implies that the data collection is happening for that page only.
• The infobar is a one-time-ever one? Since everything else in the client has changed infobars into doorhangers the infobar looks even more like a spoof in the page rather than coming from the client.
• Infobar has the advantage over a doorhanger that it's easier to ignore
  • why is that an advantage?
  • Should get approval from Faaborg, who is trying to eliminate first-run distractions

• Pref to opt-out after opting in must be in privacy pane of UI--or, if it goes somewhere else, please send the new UI location to secteam@mozilla.com on Monday.
• Automated testing and paranoid sysadmins can set toolkit.telemetry.prompted=true to disable the prompt.

Actions:

• Follow-up bug: different (non-aborting) error handling strategy for future release.
• Follow-up bug: in future histogram collections should come from a single file that can be audited, rather than allow instantiation from any random part of the code.
• Code hosted on GitHub--like many other parts of Mozilla--will review policy at next joint secteam/infrasec-security meeting.
• Follow-up bug: Mobile data usage--must minimize the size of data sent--gzip, more-efficient-than-JSON encoding.
• Should review that there are no security-rated bugs in telemetry on Monday