Closed Bug 679431 Opened 13 years ago Closed 13 years ago

Make telemetry opt-out

Categories

(Toolkit :: Telemetry, defect)

Product:
Toolkit
Component:
Telemetry
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: taras.mozilla, Unassigned)

References

(
URL
)

Details

We need to switch telemetry from opt-in to opt-out
Does this require changes to the privacy policy? Is this even legal in the EU?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Does this require changes to the privacy policy? Is this even legal in the
> EU?

Good question
First off, can you elaborate on your rationale? Since we just launched telemetry as an opt-in feature (it shipped, right?), wouldn't it make sense to be patient and see how many people opt-in? Or if the opt-ins are slow, come up with some other ways to encourage people to join the program?

To move to an opt-out, we will need to:

Determine if telemetry data is covered by the newly minted ePrivacy Directive in the EU. That is probably the only regulatory mandate that applies to this situation. Each country may implement the Directive a bit differently, but here's what the drafters of the legislation intended for the Directive to cover:

"the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent."

From my reading, it isn't clear if "information" is defined to mean specific personal data elements or if it's broadly defined. Most of the focus on the Directive has been on cookies and LSOs, and not this type of statistical user data.

If the Directive does apply, then we have our answer. If it doesn't, then we have our next set of questions related to how this conforms with Mozilla's Privacy Principles and user expectations.

Our principles state:

1) No Surprises: Only use and share information about our users for their benefit and as disclosed in our notices.

[This clearly applies and I think a decent block of users would be surprised to learn that usage tracking was on by default.]

2) Real Choices: Give our users actionable and informed choices by informing and educating at the point of collection and providing a choice to opt-out whenever possible.

[Our stated preference is to be opt-out whenever possible. See the next one, though.]

3) Sensible Settings: Establish default settings in our products and services that balance safety and user experience as appropriate for the context of the transaction.

[This might be an opportunity to pitch opt-out as "appropriate for the context," perhaps considering how usage statistics are nearly universal across software products today. Weak, yes, but perhaps acceptable.]

4) Limited Data: Collect and retain the least amount of information necessary for the feature or task. Try to share anonymous aggregate data whenever possible, and then only when it benefits the web, users, or developers.

[I think we're good here today, as the usage statistics are not personally identifiable or tied to unique users. If we expand telemetry, though, then this could change and become a factor.]

5) User Control: Do not disclose personal user information without the user’s consent. Advocate, develop and innovate for privacy enhancements that put people in control over their information and online experiences.

[Control is undermined by moving to opt-out, although we aren't collecting or disclosing personal user data for telemetry.]

How would you like to proceed?
(In reply to Alex Fowler from comment #3)
> First off, can you elaborate on your rationale? Since we just launched
> telemetry as an opt-in feature (it shipped, right?), wouldn't it make sense
> to be patient and see how many people opt-in?

<4% of users opt-in to telemetry on the nightly and aurora builds (we should expect less on release builds). This is a huge data representative usage, that makes telemetry almost completely redundant to (or worse than) Test Pilot.

Alex, I'm under the impression that you and Gilbert have moved fairly far along in discussing this topic, as he has with Jay and others. I'd prefer to leave this bug mainly for 'to-dos' once the opt-out decision is made (or not..), and continue to discuss this decision 'live'.
You've got "live" in scare quotes, but I want to note that this is the kind of discussion that needs community involvement/scrutiny, so if "live" discussions happen in person or otherwise 1-on-1, I hope to see their results here or in a newsgroup thread.
I've got to agree that this feels like the kind of thing that needs broader discussion... Had the default been opt-out, I'd definitely have raised more questions about bug 668392 which imo added some pretty user-identifying information. Where's the right place to discuss this?
(In reply to Johnathan Nightingale [:johnath] from comment #5)
> You've got "live" in scare quotes, but I want to note that this is the kind
> of discussion that needs community involvement/scrutiny, so if "live"
> discussions happen in person or otherwise 1-on-1, I hope to see their
> results here or in a newsgroup thread.

Sure, your note is well received - you can expect to see any results in the open. My main point is that this is an on-going conversion with 3+ months of history; I don't think it makes sense to start a new discussion here.
Addon ID's are already being sent in the with start up times. Not sure how one gets out of that.

What confuses me is why the satisfaction with opt- in (where the user is by default not in the collection) - this results in low response rates /and/ biased data.

If opt-out is a go, we definitely need a prominent UI element upon install/upgrade that introduces the user to data collection with default 'yes'. The current state (a preference) would not conform to 'least surprise' (agree with Alex here) if we were to go with Opt-Out.
I'm sure I'm stepping into a long-running conversation.

However, this touches on our approach to user data. With the recent refocus around Identity and User Data, we're working to improve our approach to what user data we store and how. So, let's sync up on this ASAP. Who should be involved from the Telemetry side?

All notes from this conversation will be publicly available, of course.
By (In reply to Saptarshi Guha from comment #8)
> Addon ID's are already being sent in the with start up times. Not sure how
> one gets out of that.

To clarify, this from the AMO ping that OS, start up times and addon ids.
(In reply to Christopher Jung from comment #7)
> Sure, your note is well received - you can expect to see any results in the
> open. My main point is that this is an on-going conversion with 3+ months of
> history; I don't think it makes sense to start a new discussion here.

I agree, this bug is to track technical details of switching telemetry to opt-out. Any policy discussions on whether this can go ahead should happen on the governance mailing list.
(In reply to Taras Glek (:taras) from comment #11)
> I agree, this bug is to track technical details of switching telemetry to
> opt-out. Any policy discussions on whether this can go ahead should happen
> on the governance mailing list.

I think this strict governance/tech split would be a mistake that leads to potentially larger conflict. We're specifically trying to fix that by taking a more complete approach to user data that involves product needs, mozilla principles, etc.

So, let's have this conversation. I understand the pain of rehashing existing discussions, and I apologize that I didn't / couldn't poke my head in earlier. That said, we need to do this.

Who should I bring into this conversation: Taras, Chris, others?
> I think this strict governance/tech split would be a mistake that leads to
> potentially larger conflict.

I agree, but bugzilla is not conducive to this sort of conversation and there's no need to obfuscate an implementation bug with policy debates. I'll setup an open call to discuss the entire range of issues in the next week or so and update this bug with more info.

Taras, once the decision is made (one way or the other), lets open a new bug for the actual implementation.
I strongly recommend that discussion on this be async if possible (i.e. newsgroup or mailing list).  Comment 5 is right on: this sort of thing is a community-wide issue, and even open calls exclude parts of the community simply by being in the middle of the night.
A discussion has been started in mozilla.governance.

Gerv
There wont be opt-out telemetry. This was a misunderstanding.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.