Closed Bug 616835 Opened 14 years ago Closed 14 years ago

Implement blocklist parameter for days since last check to allow counting unique installations without a unique identifier

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b10

People

(Reporter: dre, Assigned: robert.strong.bugs)

References

Details

The new "times checked" parameter makes it possible to perform several calculations without having to identify users, but it can't reliably count how many unique installations reported in over a given time period.  This new parameter allows us to do that while still retaining anonymity.

If blocklist has never been checked with this profile (can be checked by the lack of app.update.lastUpdateTime.blocklist-background-update-timer I believe?) then this parameter should be "new"

Else if the appChanged flag has been set because other parameters have been modified, this parameter should be "reset".

Else, this parameter should be an integer value containing the number of elapsed days since the last check with the remainder truncated.

This means that if blocklist is checked more than once in 24 hours, it will report.  If it has been exactly 24 hours, then it would report 1.



When we want to calculate number of unique active installations in a time range, we will begin by counting all the records on the first day with an age parameter greater than or equal to 1.  We will then count all the records on the second day with an age greater than or equal to 2.  Every day in the time range only counts pings in that day great than or equal to the rank of that day in the range.
After counting all integer parameters, we then need to deal with the two out of band values.

We add the number of records in the time range with a value of "new" to our sum.

If we want to count only installations for a particular version, locale, etc. then we will also add the number of records in the time range with the value of "reset".
I believe that for a future version of Firefox, we should break out this data into a separate "metrics" ping that can be configured outside blocklist.

With this new method of extremely anonymous counting, we could probably safely add a few more metrics to give richer data, and it is possible that we could even explore alternate methods of submitting the data rather than straight HTTP request which could potentially even eliminate fingerprintable information such as user agent string and IP address.  I'll write up a proposal for that system and submit it as a separate bug.
Credit is given to Mark Tomasik and Frank Poulin for their help in coming up with this new method given the constraints of not adding any identifiers or other tracking information.
Just for clarity and information sharing, the state we are currently in without this feature is that our privacy policy indicates that we have a cookie on AUS and Blocklist requests.  It doesn't identify a user, but it is unique.

I want to be able to calculate this metric without needing the cookie so we can kill that cookie entirely and enhance our user's privacy even further.
Couple of notes to work from
pingCount is 0 on first run with a new profile.
pingCount is reset to 1 when there is an app version change.
The blocklist service only downloads a new blocklist once every 24 hours with the 24 hour counter starting from the last download.

The description in comment #0 and the pingCount as I described have overlapping functionality. Daniel, could you further define the behavior / functionality in comment #0 to include the functionality of pingCount? Also, I don't have a problem with verifying that the blocklist doesn't ping more than once in 24 hours as it is coded to do but I am quite certain that it isn't something to be concerned about.
The daysSinceLast parameter needs to have some value in the cases of a new profile or an app version change.  We could say that 0 is an accurate answer for how many days since the last check if there was never a previous check, but it doesn't feel as good of an answer as in the pingCount parameter, "how many times have I pinged with this version?".

I considered using guard values such as -1 and -2, but the strings "new" and "reset" seemed to be a lot more clear from a readability point of view.  The fact that it frees up 0 to mean "less than one day since last ping" is a freebee although I agree with you that it is unlikely that more than a handful of people would ever invoke it. (It would be nice to be able to verify that assumption though... ;)

With this new parameter having a clearer definition of new and reset, the argument could be made that it now makes sense to change pingCount to use the 0 value on appChange instead of 1. I'm not going to push for that though as it doesn't really hurt anything to leave it as is.  It just obfuscates the meaning slightly.
Each condition in the blocklist params requires code to provide the condition and if this new param is added I would want the no longer useful code removed.

So, how about the following:
pingCount = pings since last reset and will always start at 1 for the first ping for readability since that is somewhat of concern (e.g. pingCount=1 equals 1 ping vs. pingCount=0 equals 1 ping).
daysSinceLast = "new" when this is the first ping, "reset" when the count is reset, and an integer representing the number of days rounded down since the last ping.

Does that cover everything?
(In reply to comment #6)
>...
> pingCount = pings since last reset and will always start at 1 for the first
> ping for readability since that is somewhat of concern (e.g. pingCount=1 equals
Should be pings since new or last reset etc.
Yes, that description sounds fine to me.
pingCount starts at 1
daysSinceLast starts at "new"
pingCount resets to 1
daysSinceLast resets to "reset"
Fixed by bug 620837.
Depends on: 620837
Flags: in-testsuite+
Flags: in-litmus-
Target Milestone: --- → mozilla2.0b10
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
That is because the timer manager hasn't set the last update time which is used to calculate how many days it has been since the last blocklist ping. See bug 620837 comment #8
So setting the pref is decoupled from the blocklist notification, or why can't we set it immediately when we send the notification? How long could it take until the pref will be set?
It is set by the code but it isn't set by the method you used to test. The timer manager itself sets the last update time and not the blocklist. If you test it by just running the client you would see that it does so. The amount of time before the pref gets set for the first time is anywhere from 2 minutes after startup to around 20 minutes after startup.
btw: with a new profile you can wait until the app.update.lastUpdateTime.blocklist-background-update-timer pref is added to test using the method you used
Looks to work fine. Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110209 Firefox/4.0b12pre ID:20110209030359

Set my system date to Feb 12th and manually fired a blocklist ping. As request we send:

https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/4.0b12pre/Firefox/20110210030400/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/nightly/Darwin%2010.6.0/default/default/3/1/2/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.