there is a new feature landing that will collect performance data and send back to a mozilla server for analysis. there could be some privacy sensitive data in the transmissions and we want to avoid any chance that an addon could highjack the data gathering or transmission. addons should also not add 'probes' to add to the data collection until we figure out best practices for that. the verifier and addon editors should be on the look out for any changes in this area and reject addons that engage in such behavior.
Jorge, can you break down what we are looking for here and then assign to basta? thanks
Assignee: nobody → jorge
Target Milestone: --- → 6.0.12
I think we need to look for modifications to two prefs toolkit.telemetry.enabled and toolkit.telemetry.server there is also an api call, or maybe a few, that we should look for to determine if any addon is inserting or modifying probes. taras, can you list the api call(s)?
Is there any documentation that indicates what is being sent, when and how? Which data sent here is considered private or sensitive?
Hardware: x86 → All
Summary: make verifier check for toolkit.telemetry.enabled, toolkit.telemetry.server changes to all.js. to ensure telemetry settings don't get highjacked → Add validator checks for telemetry API calls and telemetry preferences
Target Milestone: 6.0.12 → Q2 2011
(In reply to comment #2) > taras, can you list the api call(s)? Anything that uses nsITelemetry.newHistogram or has .telemetry. in the pref name should be banned. nsITelemetry.histogramSnapshots is how the data is retrieved. There might be some harmless uses for this, but it should probably be flagged too. There isn't any personal data in telemetry. It's just a bunch of performance stats. This is sent to mozilla on idle-daily if the user opts in. See bug 585196 for implementation details.
(In reply to comment #4) > (In reply to comment #2) > There isn't any personal data in telemetry. It's just a bunch of performance > stats. I would definitely be concerned about an add-on tampering with the data before it is sent to our servers. Is it possible without completely replacing the telemetry component? Other than that, I'm not sure why we would want to ban any access to these components.
if you share the concern about addon tampering of the data, then highjacking is just another form of of tampering. highjacking would be pretty easy to accomplish by just changing the location of the server where thedata is sent. sure it would be possible to replace the telemetry component, but there is a lot more work involved in that than just flipping a pref.
(In reply to comment #6) > if you share the concern about addon tampering of the data, then highjacking > is just another form of of tampering. highjacking would be pretty easy to > accomplish by just changing the location of the server where thedata is sent. My concern with the tampering of perf data is that an add-on could alter its own data (or another add-on's data) to make it appear like it has better/worse performance. Sending our data elsewhere is bad behavior, sure, and I would be OK with flagging the server pref. However, that an add-on gathers or sends telemetry data on other cases doesn't appear to be harmful to users, unless the add-on adds more data that makes the user identifiable. In those cases we should make it opt-in, but I don't think we should on others.
What do you want to do with this?
We want to flag all uses of the preference "toolkit.telemetry.server" as potentially insecure. The warning message should be something like "Extensions are not allowed to change the destination of telemetry data". Then we want to flag nsITelemetry, and also show a warning with something like "Tampering with telemetry data is potentially unsafe".
Assignee: jorge → nobody
Component: Admin/Editor Tools → Compatibility Tools
Priority: -- → P3
QA Contact: admin-tools → compatibility
Target Milestone: 4.x (triaged) → Q3 2011
Product: addons.mozilla.org → addons.mozilla.org Graveyard
Component: Compatibility Tools → Add-on Validation
You need to log in before you can comment on or make changes to this bug.