chris hofmann Reporter
	Description • 14 years ago

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.

	Wil Clouser [:clouserw]
	Comment 1 • 14 years ago

Jorge, can you break down what we are looking for here and then assign to basta?  thanks

	chris hofmann Reporter
	Comment 2 • 14 years ago

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)?

	Jorge Villalobos [:jorgev] (he/him)
	Comment 3 • 14 years ago

Is there any documentation that indicates what is being sent, when and how? Which data sent here is considered private or sensitive?

	(dormant account)
	Comment 4 • 14 years ago

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

	Jorge Villalobos [:jorgev] (he/him)
	Comment 5 • 14 years ago

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

	chris hofmann Reporter
	Comment 6 • 14 years ago

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.

	Jorge Villalobos [:jorgev] (he/him)
	Comment 7 • 14 years ago

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

	Wil Clouser [:clouserw]
	Comment 8 • 13 years ago

What do you want to do with this?

	Jorge Villalobos [:jorgev] (he/him)
	Comment 9 • 13 years ago

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