Closed Bug 737601 Opened 8 years ago Closed 7 years ago

Require users to opt-in to downloading updates while on a billed connection (e.g. 3g network)

Categories

(Firefox OS Graveyard :: General, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

RESOLVED WORKSFORME
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: cjones, Assigned: marshall)

References

(Depends on 1 open bug)

Details

(Keywords: feature, Whiteboard: [LOE:M] [WebAPI:P3])

Attachments

(1 file, 1 obsolete file)

This is a pretty tricky one to get right.  It's also a general platform issue, not b2g specific.  Desktops, laptops, android phones etc. can be connected to the internet through billed pipes.

In the initial landing of bug 737368, updates will be automatically downloaded whenever they're ready.  That's good for security/stability fixes, but bad for wallets when there are say nightly builds downloaded while users are on billed pipes.

The simplest solution is to have users opt-in to downloading on 3g by flipping a setting.  There's no way in general for us to detect if gecko is connected to billed pipe, so probably better to err on the side of safety.  We might have some better options when carriers are more involved.
This work depends in general on the network information API that's under development, but we can hook up all the rest of the pieces right now.

Here's the goal for this bug
 - add a stub helper like dataMayBeBilled() to UpdatePrompt.js.  For this bug, have it always return false.
 - when an update is available, don't download it if dataMayBeBilled().
 - except, *do* download it if the user has flipped a setting to allow updates on billed connections.

Let's call this setting "updates.allowDownloadOnBilledPipe" for now.  That's good enough for this bug.
Summary: Let users disable downloading updates on 3g network → Require users to opt-in to downloading updates while on a billed connection (e.g. 3g network)
Did this in a slightly different manner.  It checks with nsINetworkinkService to see if the connection is 2G, 3G, or 4G (and also is up) and won't do the check unless app.update3g.enabled preference is set.  If we can determine if a pipe is billed, this can be changed later, but I don't believe other smartphones have a way to detect that and just allow users to not check for updates on radio connections.
Assignee: nobody → jstraus
Attachment #612587 - Flags: review?
Attachment #612587 - Flags: review? → review?(jones.chris.g)
Comment on attachment 612587 [details] [diff] [review]
Adds check for radio connections when checking for updates

I can't review code in this module, but feedback- because
 - this central updater logic shouldn't be gonk-specific
 - but making this cross-platform/product policy decision in the central updater means a UX change for all those platform/products, which is far too much to take on for this bug.  It's a discussion we should have in parallel.

I'm not sure how the request in comment 1 could have been made any clearer.  That's the route I prefer, for a first landing.  Continuing down the route of this patch means the disable-on-billed-channel behavior needs to be pref'able, off by default, on for the b2g product, need to figure out how nsINetworkLinkService fits in with DOM network-status API and which is right to use in the long term, and you need to request re-review on this patch from :rstrong (Rob Strong).
Attachment #612587 - Flags: review?(jones.chris.g) → feedback-
Ok, I made this B2G specific.  I did leave code that checks for the link type in, commented out as the link type isn't being returned due to bug 667980.
Attachment #612587 - Attachment is obsolete: true
Attachment #614420 - Flags: review?(jones.chris.g)
Comment on attachment 614420 [details] [diff] [review]
Changes just for B2G

How did you test this patch?
By injecting a hand constructed update object on a timer from shell.js and lots of prints to see where it went.  I'm sure it's not perfect, but it was the best I could think of.  Do you have an alternative suggestion?
 - Create an update package: |make gecko-update-full| in a b2g checkout
 - Create an update manifest: fill the values from above into this template: http://pastebin.mozilla.org/1575376
 - Host the update package and manifest behind a server, localhost is easiest
 - Point http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#494 at the URL to that manifest
Whiteboard: [b2g:blocking+]
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Whiteboard: [b2g:blocking+]
Jim, can you update this patch? I'll have some time to review
Comment on attachment 614420 [details] [diff] [review]
Changes just for B2G

Review of attachment 614420 [details] [diff] [review]:
-----------------------------------------------------------------

::: b2g/components/UpdatePrompt.js
@@ +14,5 @@
>  
> +const PREF_APP_UPDATE_CELLULAR_ENABLED = "app.update.cellular.enabled";
> +const PREF_APP_UPDATE_ALLOW_DOWNLOAD_ON_BILLED_PIPE
> +      = "app.update.allowDownloadOnBilledPipe";
> +

const PREF_APP_UPDATE_ALLOW_DOWNLOAD_ON_BILLED_PIPE = 
  "app.update.allowDownloadOnBilledPipe";

It seems that the name of the constant is too long.

@@ +35,5 @@
>    checkForUpdates: function UP_checkForUpdates() { },
> +  showUpdateAvailable: function UP_showUpdateAvailable(aUpdate) {
> +    if (this.dataMayBeBilled() && !getPref("getBoolPref",
> +        PREF_APP_UPDATE_ALLOW_DOWNLOAD_ON_BILLED_PIPE, true))
> +      return;

let isAllowed = Services.getBoolPref("app.update.allowDownloadOnBilledPipe", false);
if (!isAllowed && this.dataMaybeBilled())
  return;

getPref is not a method.

@@ +38,5 @@
> +        PREF_APP_UPDATE_ALLOW_DOWNLOAD_ON_BILLED_PIPE, true))
> +      return;
> +    let aus = Cc["@mozilla.org/updates/update-service;1"]
> +              .getService(Ci.nsIApplicationUpdateService);
> +    if (aus.downloadUpdate(aUpdate, true) != "failed") { }

You're doing nothing if the download works?

@@ +65,5 @@
>        );
>    },
>  
> +  dataMayBeBilled: function UP_dataMayBeBilled() {
> +    return false;

leftover?

@@ +77,5 @@
> +//    if (!getPref("getBoolPref", PREF_APP_UPDATE_CELLULAR_ENABLED, true) &&
> +//        (anls.linkType == anls.NS_NETWORK_LINK_TYPE_2G ||
> +//         anls.linkType == anls.NS_NETWORK_LINK_TYPE_3G ||
> +//         anls.linkType == anls.NS_NETWORK_LINK_TYPE_4G))
> +//       return;

All this code is commented, I will assume that the code you want to execute.

The method never return true and sometimes does not return false while a boolean is expected.

getPref is not a method (see the previous comment for showUpdateAvailable).
Attachment #614420 - Flags: review?(jones.chris.g) → review-
Assignee: jstraus → marshall
How are we doing here?
Priority: -- → P2
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following:

- Move the blocking-basecamp flag to ? for re-evaluation
- Indicate a rationale for why you disagree
blocking-basecamp: --- → ?
Based on product input this is a blocker for the Brazilian market.
Whiteboard: [blocked-on-input Chris Lee and Josh Carpenter]
This is a v1 requirement, but *only* for when the user is roaming.  

Would be good to get UX input on if we prompt the user when they are Roaming or just automatically begin the download when they hit WiFi or return to the in-network (non-roamning) connection.  

Product's recommendation is to not show any prompt and just wait til the user connects to a non-billed connection.
blocking-basecamp: ? → +
I've posted a draft update process proposal to the following:

https://wiki.mozilla.org/Gaia/System/Updates#Draft_process_for_atomic_Gecko.2BGaia_updates

See the "3. Check Connection" step:

https://wiki.mozilla.org/Gaia/System/Updates#3._Check_connection

Abridged flow diagram here (minus some details, and the Manual update flows):

https://wiki.mozilla.org/images/4/46/SystemUpdates_Flow1.pdf

> Would be good to get UX input on if we prompt the user when they are Roaming or just automatically begin the download when they hit WiFi or return to the in-network (non-roamning) connection.  
> Product's recommendation is to not show any prompt and just wait til the user connects to a non-billed connection.

If the update was initiated automatically (as seen in the Flow diagram), then I'm more inclined to not show a prompt, silently defer the download, and wait to retry until either a set time interval has elapsed (eg: try again 24 hours later), or the Update mechanism is alerted to a connection type change (to Free APN or WiFi), whereupon the Install process proceeds.
Whiteboard: [blocked-on-input Chris Lee and Josh Carpenter] → [blocked-on-input Chris Lee and Josh Carpenter] [LOE:M]
Whiteboard: [blocked-on-input Chris Lee and Josh Carpenter] [LOE:M] → [blocked-on-input Chris Lee and Josh Carpenter] [LOE:M] [WebAPI:P3]
Keywords: feature
Users always have to opt-in to download updates in the current UX.  They're given an indicator that shows what network type they're on.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [blocked-on-input Chris Lee and Josh Carpenter] [LOE:M] [WebAPI:P3] → [LOE:M] [WebAPI:P3]
You need to log in before you can comment on or make changes to this bug.