855257 - Remove all parameters related to metrics from blocklist URLs

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Since the dawn of time, the blocklist URL has included parameters that aren't absolutely essential to blocklist functionality - acting as a poor-mans telemetry/healthreport, so we could collect essential aggregate data points. 

However, now days we have Telemetry and Health Report - they're more complete, and offer better user-control. So I'm hoping those are in a position to entirely fulfill the metrics role, so we can decouple metrics from the blocklist ping and remove all the extra parameters that aren't essential to blocklist functionality.

For reference, this is the URL that Firefox desktop currently uses:
https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/

And currently, this is the URL that contains everything needed for the blocklist to function:
https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/
(AFAIK, the app ID and version are needed only because of AMO's URL rules - they're not actually used. So those should be removable with an AMO bugfix.)

Comment 1

[Daniel Einspanjer [:dre] [:deinspanjer]]

I agree with the intent of this bug. I think we still need another quarter with the existing format to ensure pairity with FHR,  but when that vetting is complete,  I would like to see us trim it down.


I do think we should leave app ID,  version, channel and build ID in the url though because those are useful when investigating potential issues with blocklist as well as providing the most likely avenues for future enhancements to the discrimination capabilities of the feature.

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #1)
> I think we still need another quarter
> with the existing format to ensure pairity with FHR

Ok, fair enough.

> useful when investigating potential issues with blocklist

Hm, I guess it's the only way of seeing what isn't there (clients that aren't requesting blocklist uppdates).

> as well as providing the most likely avenues for future
> enhancements to the discrimination capabilities of the feature.

Bug 782261 is the way forward, I rather hope we don't need to add or change much with the blocklist service before that arrives (no timeframe yet, however).

Comment 3

[Mike Connor [:mconnor]]

To be honest, I think we can be incredibly minimal here.  As of bug 850483, FHR is collecting blocklist ping success such that we should be able to check that data to detect problems.  If we need to directly analyze traffic to the blocklist URL, we should get sufficient fidelity from the user agent to narrow things down, without needing to disclose channel/build ID.

I'm open to per-app lists if we believe the bandwidth delta is significant for mobile clients, but that's the only piece I think is potentially necessary to include as API args.

I don't know about the web side, but I assume we could get away with:

https://<domain>/<version>/<app> as a simple request.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.