380377 - Mechanism preventing counting downloads twice is flawed

Status: RESOLVED INVALID

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Wladimir Palant]

Currently, the download controller would set a cookie named "count" with expiration time DL_COUNT_DELAY to duplicate downloads from being counted. There is a number of issues there:

1. DL_COUNT_DELAY has the value 10. That's 10 *seconds*. The idea probably was to have 10 *minutes* expiration time - so either multiply the value with 60 when using it or change the constant to 600.
2. User's clock might be skewed. It isn't a problem for time intervals of a few days, but 10 minutes should be problematic. The difference between my clock and AMO's clock is currently 6 minutes (and that's actually a clock skew on AMO's side) so that the 10 seconds cookie isn't set at all. Solution: don't rely on expiration times, put the download time into the cookie and compare the value to the current time for next download. The cookie itself should have a reasonably long expiration time.
3. The cookie doesn't depend on the extension being downloaded. This means that if you download several extensions within 10 minutes, only the first download will be counted. The name of the cookie should be something like "count1865" where 1865 is the extension ID.

Finally, something else to consider: does this cookie have an influence on caching? I am not sure how NetScalers are configured, but having a cookie set might degrade your performance because you are no longer served the cached pages. If that's the case, the cookie should probably be limited to a path so that only the downloads controller gets it.

Comment 1

[:Gijs (he/him)]

I'm pretty sure this feature only exists to work around the fact that the installation process will request the xpi twice, and I'm also pretty sure that that won't take 10 minutes in 99.99% of cases. 

Comment 2

[Fred Wenzel [:wenzel]]

A few notes:
- 10 seconds were in fact the intended length: It was chosen to avoid multiple counts of the same download, because in our tests, Firefox queried the download URL more than once during one installation process. (Gijs is right)
- your second point (clock skew) is valid and needs further investigation, thanks.

Regarding caching: No, it does not have an influence (whereas the login cookie does). Also, we may not cache the download request, otherwise it won't reach the app server and will therefore not be counted.

Comment 3

[Wladimir Palant]

So this isn't about users who generally click twice? Because I am pretty sure there are lots of them.

Comment 4

[Wladimir Palant]

I just checked this just to be sure - XPInstall sends the first request before the intallation window is shown and the second when the user clicks "Install". There is *at least* 5 seconds in between, and it could easily become more than 10 seconds - e.g. if the user isn't fast enough clicking "Install" or if he simply has a slow connection.

Btw, I was wrong about AMO's clock skew being 6 minutes, that was a NetScaler. The actual server only has ~15 seconds difference to my computer, but the effect is the same.

Comment 5

[Michael Morgan [:morgamic]]

This should be "fixed" by the download count script.  Please reopen if you disagree.