Closed Bug 813837 Opened 12 years ago Closed 12 years ago

Only submit Telemetry data on mobile via wifi (B2G)

Categories

(Core :: Networking, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED WORKSFORME
B2G C3 (12dec-1jan)
blocking-basecamp +

People

(Reporter: lmandel, Assigned: froydnj)

References

Details

Due to data plan restrictions (limited monthly usage caps), we don't want to submit Telemetry data over cellular data connections on B2G. We should prevent Telemetry from submitting pings via a data connection. Ideally Telemetry pings should be queued and sent if and when the client connects via wifi.

Note that any way to prevent Telemetry pings from being sent via a data connection should be acceptable for v1. This includes disabling Telemetry on B2G if this is the only reasonable path. (We can leave the pref but simply not submit Telemetry data until we can limit it to wifi.) 

Dougt notes that similar work took place for Firefox for Android in bug 667980 but did not land due to the requirement to add a network query permission on app install. (There is a patch in the bug that can be used as a reference for this bug.) Please keep the Android use case in mind when fixing this bug.
Component: General → Networking
Product: Boot2Gecko → Core
Nomming for a Product call here. We should probably hang off the same policy/pref as bug 811778.
blocking-basecamp: + → ?
Depends on: 811778
Chris, should we utilize the same policy as bug 811778?
Flags: needinfo?(clee)
How much data/what frequency are we talking about for telemetry data?

JP, yes, we'd ideally utilize the same policy as bug 811778.
Flags: needinfo?(clee)
A single sample ping from Vladan Djeric's machine looks like it is ~10Kb / day. This does include data that will not be collected on B2G like tab switch, preference, or, more generally, anything that has to do with browser chrome. 

Telemetry will attempt to submit a ping once per day. However, Telemetry will continue to collect data in a single ping for the duration of a session. On desktop, a session is marked by browser shutdown. AFAIK, if a phone is not shutdown for many days, the session data will continue to grow and a larger packet will be submitted each day. 

As well, the 10Kb / day that I mentioned above is the compressed packet size. Telemetry is collected uncompressed. In the sample from Vlad's machines this means that the space used on disk while collecting Telemetry data is 5x that which is sent. Either keeping the phone up for extreme periods of time or preventing Telemetry from submitting pings may end up in extreme cases consuming some sizable amount of disk space.

We need to revisit Telemetry assumptions about session lifetimes and when data should be submitted for B2G.
blocking-basecamp: ? → +
Do we have a plan for what to do with the B2Gv1 telemetry data? IOW, if we don't intend to use the data we collect between v1 and v2, let's just turn this off.
I'm also not entirely sure telemetry works as expected with the multi-process bits of B2G.  If all processes are sending in telemetry data, we might wind up sending significantly more than we do on desktop.
toolkit.telemetry.enabled is false by default, so there's no additional work to turn it off for B2G.
(In reply to Jet Villegas (:jet) from comment #7)
> toolkit.telemetry.enabled is false by default, so there's no additional work
> to turn it off for B2G.

A toggle for the Telemetry preference is included in the first run experience and in the settings app. We want to encourage people to enable Telemetry even if we're not sending any data initially. (The hard part is getting people to opt-in.) If we are to disable Telemetry on B2G, I think we want to either simply discard the data that is collected or have some other way of setting Telemetry to the disabled state that maintains the user's preference.
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
Assignee: bugs → lmandel
Priority: -- → P3
cjones, clee - Unless there is a product requirement for Telemetry in v1, I suggest that we disable it (leaving the preferences in tact) as we've discussed in this bug. We should sort out the data collection and submission issues from comment 4 for a subsequent release.
Flags: needinfo?(clee)
What's the drawback of just discarding this data for now until we get the right probes set up?  If you believe there is an easy way for us to disable it, but keep the pref intact, let's just do that for v1.  Thanks.
Flags: needinfo?(clee)
The drawback is we won't get Telemetry data for v1. At this point I agree that that is acceptable. Thanks for the confirmation.

Nathan - Can you take care of disabling Telemetry on B2G? The Telemetry preferences, which a user can set via a prompt on B2G first run and through the settings app, should remain functional. (We should record their preference.) We are going to go without collection and submission of Telemetry data in v1.
Assignee: lmandel → nfroyd
For avoidance of doubt: we do or do not have the prompt/settings bit already in B2G?  Comment 8 makes it sound like we do (and I'm pretty sure I recall seeing a prompt on my phone), but comment 12 makes it sound like we do not.

If we do, then I don't think there's anything to be done here.  The pref is flipped to off by default and can be flipped to on by users.  MOZ_TELEMETRY_REPORTING needs to be set at build time to enable actual sending of the data, but it's not set in the b2g mozconfigs.  So that sounds like everything works as desired.
Also, I'm going to be away through the new year, so you might want to find somebody else to do thing if there's actually anything to be done. :)
Lawrence and I talked offline about this and agreed there's nothing to be done here; we prompt users to see if they want Telemetry to be enabled, but nothing gets sent due to how B2G is built currently.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.