Pass subscription status to uninstall page

[erezson]

Background

As ABP team we would like to know if uninstalled users are AA opt-in/out so we can have better decisions based on data

What to change

Add s (for subscriptions) query string parameter to uninstall URL that represents the following information:

• Is Acceptable Ads filter list inactive and are all ad blocking filter lists inactive?
• Is Acceptable Ads filter list active and are all ad blocking filter lists inactive?
• Is Acceptable Ads filter list active and are some ad blocking filter lists active?
• Is Acceptable Ads filter list inactive and are some ad blocking filter lists active?

Active means filter list is installed and enabled.
Inactive means filter list is either not installed or disabled.

e.g.

• 0: AA inactive; ad blocking inactive
• 1: AA inactive; ad blocking active
• 2: AA active; ad blocking inactive
• 3: AA active: ad blocking active

Hints for testers

• The correct subscriptions state should be included in the uninstall URL regardless of whether the uninstall happens with or without changes to filter lists after the extension has been loaded.
• Only recommended ad blocking lists are considered for determining whether ad blocking is in-/active.
• The "Acceptable Ads without third-party tracking" list is not considered for determining whether Acceptable Ads is in-/active

[sebastian]

@sporz: Any chance we can already extrapolate these data?

[sporz]

TL;DR: No.

Explanation
We could match IP/UA combinations of users uninstalling with recently (same day) downloaded notification.json and exceptionrules.txt files. However, there would be a large number of users we'd be misinterpreting because they downloaded the day before (possibly on a different IP), but are still within the 24h interval.

Another way is assuming the same opt-out rate in uninstallations as in our active users.

Both ways are unfortunately unsuited to answer questions like "Do users with AA enabled uninstall more frequently than those with AA disabled?". @erezson is this about what you're aiming for?

[sebastian]

Alright, if we cannot extrapolate those data, fine with me adding a query string parameter like aa=0|1 (indicating whether Acceptable Ads was enabled) to the uninstall URL.

But keep in mind that the uninstall URL is limited to 255 characters, currently we have ~168 characters here, which leaves still enough space to add an aa parameter, but more complex data like a complete list of filter list subscriptions wouldn't be possible.

[erezson]

Replying to sebastian:

Alright, if we cannot extrapolate those data, fine with me adding a query string parameter like aa=0|1 (indicating whether Acceptable Ads was enabled) to the uninstall URL.

But keep in mind that the uninstall URL is limited to 255 characters, currently we have ~168 characters here, which leaves still enough space to add an aa parameter, but more complex data like a complete list of filter list subscriptions wouldn't be possible.

That's fine, for your example about list of filters we're going to do it via the telemetry. But anyway, if we will get to the maximum amount of characters, I would suggest to revise the data we really need. Thanks for letting me know about it.

Sebastian, Do you have any idea when we can have this feature implemented?

[greiner]

I updated the ticket description to reflect what has been agreed on so far but also added a third state to reflect whether the filter list is disabled to detect whether the filter list is in an invalid state.

Along those lines, we could also add further states, if there's any piece of information related to this filter list we're interested in, without increasing the size of the uninstall URL.

Examples:

• List is installed and enabled but it has always failed to download so far
• Acceptable Ads without third-party tracking list is installed, enabled, etc.

Presumably, however, the three states should be sufficient for now.

@erezson Do you agree with this assessment? If so, can you confirm that the Acceptable Ads without third-party tracking list should not be considered when determining whether a user has opted-in/out of Acceptable Ads? Otherwise we'll need to agree on how to represent that information without making it too hard to understand (i.e. intransparent) for users.

e.g. Representing AA being installed and enabled and AA3p being installed but disabled:

• In binary: aa=e (i.e. 1110 in hexadecimal)
• In decimal: aa=12

[erezson]

Agree. I don't think it's that important to know about 3rd party.

[sebastian]

Wasn't the Acceptable Ads list meant to never be disabled but can only be removed?

Also according to Winsley it would be good to know if any ad blocking list (i.e. EasyList or any EasyList bundle) is active, e.g. in order to identify the scenario when users might uninstall because effectively nothing is blocked. We could encode these information like following:

0	no known ad blocking list enabled
1	known ad blocking list enabled
2	known ad blocking list and Accapeble Ads enabled

[greiner]

Replying to sebastian:

Wasn't the Acceptable Ads list meant to never be disabled but can only be removed?

Yes, there are various invalid states the user could theoretically be in.

Some examples:

• AA installed but disabled, AA3p not installed
• AA not installed, AA3p installed but disabled
• AA installed and enabled, AA3p installed and enabled
• AA not installed, AA3p not installed

For that the aforementioned notations could help us identify the exact state the extension is in to make sure there are no users that are in such an invalid state (see also #5933).

Also according to Winsley it would be good to know if any ad blocking list (i.e. EasyList or any EasyList bundle) is active, e.g. in order to identify the scenario when users might uninstall because effectively nothing is blocked. We could encode these information like following:

0	no known ad blocking list enabled
1	known ad blocking list enabled
2	known ad blocking list and Accapeble Ads enabled

I'd argue 2 is redundant if we also have the aa parameter but yes, good point, such information could also end up being quite helpful in identifying problems with the extension state.

Referring back to the binary format I mentioned, we could encode all of that information in a single character (or a series of characters), if we want to keep the query string size at a minimum by instead representing the extension's state rather than only the Acceptable Ads state.

[sebastian]

Of course, I'm not suggesting to add yet another parameter, but instead of the aa parameter we could add an s (for subscriptions) parameter with the states suggested above. Yes, I don't distinguish between disabled and missing subscriptions, as I fail to see how that difference is relevant, as the effect is the same (and as mentioned before Acceptable Ads cannot be disabled anyway). Also I don't distinguish between no filter list and only Acceptable Ads, since the effect is the same there as well.

[greiner]

Replying to sebastian:

Of course, I'm not suggesting to add yet another parameter, but instead of the aa parameter we could add an s (for subscriptions) parameter with the states suggested above.

Ok, thanks for clarifying.

Yes, I don't distinguish between disabled and missing subscriptions, as I fail to see how that difference is relevant, as the effect is the same (and as mentioned before Acceptable Ads cannot be disabled anyway).

I was seeing it more from an analytical perspective since disabled filter lists would still lead to update requests to our servers. However, you're right that from a user experience perspective there's no difference between those.

Also I don't distinguish between no filter list and only Acceptable Ads, since the effect is the same there as well.

That's not accurate. The Acceptable Ads filter list also contains blocking and hiding rules which, at least in theory, could lead to some websites behaving differently.

Apart from that, the request states that we want to know whether the user "is AA opt-in/out" and for that it shouldn't make a difference whether a blacklist is en-/disabled. Although it would be good to have this kind of information in addition to it.

With that we'd at least have the following states:

• AA filter list inactive and all ad blocking filter lists inactive
• AA filter list active and all ad blocking filter lists inactive
• AA filter list active and some ad blocking filter lists active
• AA filter list inactive and some ad blocking filter lists active

We still wouldn't know any of the following information:

• Is AA filter list installed but disabled?
• Is AA3p filter list installed and/or enabled?
• Does the user have all the appropriate ad blocking lists? (e.g. user may only have plain EasyList enabled)

@erezson @sebastian Would that satisfy your requirements?

[sebastian]

Sounds good to me.

[greiner]

Updated ticket description accordingly.

[greiner]

FYI I got the change ready but will wait until the dependency update for #7371 is done (there's no ticket for it yet AFAIK) to avoid unnecessary work because it relies on subscriptions.xml to determine whether ad blocking is active.

[sebastian]

You could already submit a merge request, based on subscription.json, so that we can already review the changes in order to land it faster once the required dependency update is in. FWIW, we already have a couple other merge requests that already got approved but are currently blocked by that dependency update as well. But once the dependency update is in we can just go ahead and land them.

[greiner]

Good to know and sorry about the delay. I've now created the MR which includes a subscriptions.json file for testing that can easily be removed before merging it after the dependency update.

[abpbot]

A commit referencing this issue has landed:
​Issue 7302 - Added subscriptions parameter to uninstall URL

[greiner]

Added hints for testers.