807327 - [OTA Update] Restrict updates to wifi only, not carrier data

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Tony Chung [:tchung]]

You can currently detect and download a system update over carrier networks (I'm on Edge).    I'm not sure if this is a certification or v1, but we should really prohibit downloading the update if over Carrier data.

Repro:
1) install 10-30-2012 unagi daily build
2) enable data connection, disable wifi (Edge in the US)
3) settings > check for updates
4) Verify an update is available and downloadable over Edge

Expected:
- we should disable system updates over carrier, and restrict to Wifi only

Actual:
- carrier system updates is expensive and large

Comment 1

[Andrew Overholt [:overholt]]

Chris, I think we need product's call here.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

There's no reason that FOTA updates would be larger in general than gecko/gaia updates.

Comment 3

[Tony Chung [:tchung]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> There's no reason that FOTA updates would be larger in general than
> gecko/gaia updates.

Why is this invalid? my concern here is that users will be serving updates over carrier data, and that will eat up their paid data plan.   We should have a way to restrict system updates to Wifi only.

Likely need product's call.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

OK, it wasn't clear what this bug is filed about.

OTA updates always have to be confirmed by the user, so I'm still not sure what you're looking for here.  Can you be more specific?

Comment 5

[Doug Turner (:dougt)]

renom if this is an issue that should block.

Comment 6

[Tony Chung [:tchung]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> OK, it wasn't clear what this bug is filed about.
> 
> OTA updates always have to be confirmed by the user, so I'm still not sure
> what you're looking for here.  Can you be more specific?

sorry i missed replying to this.   my complaint is we should not even do aus:svc pings if a user is on carrier data, and not wifi.   A couple of reasons:
- large data size of download, 'nuff said.
- you can't dismiss the update notification right now  (that might just be a bug)
- we dont show users how big these updates are, in fact, the new UI is just munging all updates (3rd party, system), into the same UI.    Users will not know how much they are downloading if they say yes
- costcontrol app helps users see their activity, but they also have the ability to cap it.  So even if a user is downloading over carrier, it could fail due to their cap, and meanwhile they wasted X number of data usage.

if in wifi, we can detect what they have and use it there. its safer, makes more sense to ping and download then, and brings peace of mind to my data plan.

On a comparative note, i know Apple Iphones now restrict app updates if you've accidently floated from wifi into carrier data.   and i think android has an setting to restrict it altogether, although i'm not 100% sure about that.

Feel free to needinfo product if they need to chime in.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Tony Chung [:tchung] from comment #6)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> > OK, it wasn't clear what this bug is filed about.
> > 
> > OTA updates always have to be confirmed by the user, so I'm still not sure
> > what you're looking for here.  Can you be more specific?
> 
> sorry i missed replying to this.   my complaint is we should not even do
> aus:svc pings if a user is on carrier data, and not wifi.   A couple of
> reasons:

Wifi can be billed too.

> - large data size of download, 'nuff said.

Note, you're conflating two things here: the update ping, which is a small HTTP request, and the download of the update itself.  Current updates are vastly unrepresentatively large because we're not shipping delta updates.  But yes, in general they can be large.

> - we dont show users how big these updates are, in fact, the new UI is just
> munging all updates (3rd party, system), into the same UI.    Users will not
> know how much they are downloading if they say yes

This was part of the UX spec.  Maybe Marshall or Etienne knows if there's a bug on file?

As I recall, the tentative agreement with TF was to poll for updates over any connection, and the UX was to always require user consent before downloading over any connection type.  Definitely something we need to nail down sooner rather than later :).

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

basecamp-. B2G prompts the user to update and gives them the control to choose to do this via wifi or data connection.

Comment 9

[Robert Kaiser]

FYI, bug 811778 is restricting the sending of crash reports to wifi, and there's a bug dependent on that to do the same for telemetry. For both, we also have this restriction in the spec. Of course, the difference is that we don't prompt for every submission of that data to us, but by default only once for getting automatic submission turned on.

Comment 10

[BMO Automation]

Firefox OS is not being worked on