809272 - Data usage in notification bar is incorrect, could cause user major $$$ loss

Status: RESOLVED DUPLICATE of bug 816110

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P1)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

Trying to download an update. Started in the notification bar with 3G data usage (nevermind that I've only got EDGE capability) marked at 0MB, I'm connected to wifi so I can download the update.

When I touch the data usage bar, I get taken over to the data usage app that shows 0MB on 3G and 22MB on wifi, but then when I go back to the notification bar, it shows 16MB of 3G data usage.  This persists even as more of the update downloads (wifi in data app now at 32MB).

(on the 11-01 stable build)

Comment 1

[Dietrich Ayala (:dietrich)]

Salva, when can you have a fix for this?

Comment 2

[Salvador de la Puente González [:salva]]

I'm immersed in the re factor to avoid the BG service in Cost Control application. One of the things I'm checking is how data usage is retrieved, post processed and stored in the app.

So, working on it.

Comment 3

[Daniel Coloma:dcoloma]

Anyhow, should not we include a disclaimer stating that the stats may not be up-to-date and not be 100% inline with the data metered by the carrier?

Comment 4

[Salvador de la Puente González [:salva]]

I think so. More counting with possibly free URLs or changes between SIMsFurthermore if we are handling gaps then we need that disclaimer. Furthermore

Comment 5

[Salvador de la Puente González [:salva]]

I want to say: "I think so. More counting with possibly free URLs or changes between SIMs"
But I don't know what happened.

Comment 6

[marcoc]

This bug is about the consistency between Data module in notification tray and Data Usage view in app, which is really important to achieve to avoid any confusion.

Re: Data stats, In brazil with vivo if a user surpasses a data usage limit their connection speed reduces, there is no additional charge incurred. This is also the typical scenario in Spain. That said, when a user sets an alert level for data usage, there is already this note that acts as a small disclaimer:

Enter a mobile data limit alert
Connection speeds reduce after the limit is reached. Check with your data provider to set an appropriate alert level. 
https://bugzilla.mozilla.org/show_bug.cgi?id=806062

We could rephrase it to be:
Enter a mobile data limit alert
Check with your data provider to set an appropriate alert level. Phone data statistics are indicative, and may not be fully accurate with those of data provider.

Comment 7

[Daniel Coloma:dcoloma]

(In reply to marcoc from comment #6)
> This bug is about the consistency between Data module in notification tray
> and Data Usage view in app, which is really important to achieve to avoid
> any confusion.
> 
> Re: Data stats, In brazil with vivo if a user surpasses a data usage limit
> their connection speed reduces, there is no additional charge incurred. This
> is also the typical scenario in Spain. That said, when a user sets an alert
> level for data usage, there is already this note that acts as a small
> disclaimer:
>

Data Usage is not only shown in VIVO Brazil but in any operator, so we should be very cautious about it and use a safe wording.

Comment 8

[marcoc]

This possible 'inaccuracy' is only for data.. correct?
If so, i can write up a short note and place it the first time set-up of cost control to clarify how the data statistics are collected.

Comment 9

[marcoc]

This possible 'inaccuracy' is only for data.. correct?
If so, i can write up a short note and place it the first time set-up of cost control to clarify how the data statistics are collected.

Comment 10

[Salvador de la Puente González [:salva]]

Nop. :cjones realized that if you use your SIM in other device and send some messages, then counting is inaccurate as well (see bug 816110). We should say something like

"Statistics measurements based on your device. For more accurate information consult your operator"

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I thought we "counted" SMS usage by sending messages to the operator and parsed the returned message to see how much money the user has on the account. So that number should be correct as long as the operator provides an SMS-based API for getting remaining amount of money.

Is that not the case?

Or are there plans where the amount of money remaining is different from the amount of SMSs remaining (this is common in the US, but I was under the impression that it wasn't the case in the markets where we launch).

Comment 12

[Salvador de la Puente González [:salva]]

Please, I'm going to briefly explain how CC works. It is not bound to VIVO but note VIVO is our testing operator:

There is 3 kinds of users:
 - PREPAID - You have a credit to spend in telephony services
 - POSTPAID - You use telephony services and then your are billed at the end of the billing cycle
 - DATA-ONLY - If the user don't belong to one of the authorized networks, only data usage statistics are count.

The APIs VIVO provide for this are:
 - Credit control - human focused SMS
 - Telephony use (SMS & duration billed) - Absolutely nothing
 - Data statistics - Absolutely nothing

So you see in one gaze the limitations that Cost Control have.

Now, credit control is implemented be sending (not "counting", just sending) a request SMS and waiting for the response.

Telephony use is tried to keep accurate by just counting how many SMS have been sent and how much time you spend in call. This is inaccurate by nature because we do not have any control when the SIM is out of the device.

Data statistics is more the same. We don't have total control because we can not control how much non-free data have been transferred.

Comment 13

[marcoc]

Just wanted to post an update to the disclaimer comment for Cost Control - I am working on it with our copywriter, and suggest placing it in the Welcome screen in the Cost Control app set-up, so it is seen as soon as user chooses to set-up the app.

Comment 14

[David Scravaglieri [:scravag]]

Moved to C3 because the app is in refactoring process.

Comment 15

[Dietrich Ayala (:dietrich)]

Driver retriage: Daniel said bug 816110 will wholly fix this, so duping against that.