[Done] Notify the maintainer of the filter

[Hubird]

Ieven if there is no tick to mark the section as complete.

I don't think removing the ticks would be a very good idea, the user needs to be able to tell with no uncertainty what exactly is going on (what stage they are up to, what has been completed) and you can't get much better than ticks for this.

[Michael]

Hubird, I wasn't suggesting removing the ticks, only that the text should be central in the box regardless of whether or not it has been marked as complete. I probably should have worded my proposal better...

[Michael]

Is there a way to test the new feature while ensuring that the report is not needless forwarded to subscription authors?

[alberto]

This feature looks great. I have few comments and suggestions for improvement:

Wizard

* Step 3 - 'Next' button actually starts sending the report (was not expecting this!) and then obviously this action cannot be reversed. I think it will look better with a 'Send report' button instead .

* Step 4 - After completion, still displays that ABP is sending the report. This should probably display whether it succeeded or failed. [The server response indicates success/failure, but the text on the top from the extension is not updated]


Report data

* Extensions. It might be useful to collect this info. There are known issues with other extensions, and seems to be a question frequently asked for weird problems. If a new extension starts breaking ABP functionality (or it is suspected), it would be possible to analyse by correlating all reports and advice users accordingly.

* Filters - when there are custom filters applied, the source reads something like ~eh~ and ~fl~. Perhaps this should be more obvious.

* Subscription status. ABP only reports active subscriptions. If I had a disabled subscription, would the resolution be the same as if I had no subscription? If not, then this should list all subscriptions and show if enabled/disabled.

* Subscriptions - Last download. This currently shows the last *attempt* to download. If the last time it failed to download, it's not possible to know if subscription was refreshed recently or not (and know if a problem was already fixed). An edge case perhaps, but people with a download issue might be the ones will most likely report a problem! Can ABP report the last *successful* download time?

* Platform/OS details. Is it enough detail provided in the User Agent? For example, does it tell specific Linux distribution that have known issues?

* Errors console. Just noticed ABP was about to send this line. The path contains my username and this would have been a privacy concern. This error was a one-off after updating to a dev build, but just highlights that the error console could reveal private information in some specific cases -- perhaps you can filter out errors referencing files?

Warning: WARN addons.xpi: Ignoring file: C:\Documents and Settings\alberto.xxxxxxxx\Application Data\Mozilla\Firefox\Profiles\h6ennwui.default\extensions\staged\elemhidehelper@adblockplus.org.json

[Michael]

* Subscription status. ABP only reports active subscriptions. If I had a disabled subscription, would the resolution be the same as if I had no subscription? If not, then this should list all subscriptions and show if enabled/disabled.

A disabled subscription should have no effect on browsing.

* Platform/OS details. Is it enough detail provided in the User Agent? For example, does it tell specific Linux distribution that have known issues?

All Linux user agents I know of include the distro and version.

[Wladimir Palant]

@Michael, notifications aren't being sent out yet - this still needs implementing and some testing. So feel free to test as much as you want. The current reports will also probably be cleared out a bunch of times before things are mature.

@alberto: Thank you, very useful feedback. Yes, the button title on step 3 is suboptimal, I know. I'm simply not quite sure how to fix this, the wizard widget isn't very flexible.

Sending list of installed extensions - is something I considered but I'm not sure whether this is a good idea privacy-wise.

~eh~ & co. need translating on the server.

Disabled subscriptions should be irrelevant which is why they aren't being sent.

Last download attempt is currently all that Adblock Plus stores - time of last successful download isn't being saved. Maybe we should start now, this info is indeed useful.

User agent should provide pretty much all OS info that the browser is aware of. If something isn't listed there - I don't think we can get it.

Errors: I can probably censor file paths - replace the profile path by a placeholder. Maybe also the application path, just in case. That should be all as problematic cases go...

[alberto]

Sending list of installed extensions - is something I considered but I'm not sure whether this is a good idea privacy-wise.

I personally feel this does not disclose much personal information, however others may disagree.
You may want to consider the approach used in Test Pilot
https://mozillalabs.com/blog/2009/09/ca ... ots-to-be/
"It uploads a one-way hash of the extension ID, so if we're looking for a known add-on, we can identify data that comes from user with that add-on. But other than that, we can't see the names of the add-ons you have installed."

However anyone looking at the hash value in the XML will wonder if you are sending (private) obfuscated data!

Disabled subscriptions should be irrelevant which is why they aren't being sent.

I was looking at this more from the point of view of the user, and how to deliver an accurate response to resolve that particular scenario. For example, an inexperienced user may perceive he has already a valid subscription (but actually is disabled) and wonder why you want him to subscribe to a new one. Anyway, you can always advice to subscribe to a list and/or ensure the subscriptions are enabled.

@Michael, notifications aren't being sent out yet - this still needs implementing and some testing. So feel free to test as much as you want. The current reports will also probably be cleared out a bunch of times before things are mature.

It may still be required to trial / test on an ongoing basis. For example, a new ABP version introduces more features whilst ABP 1.3 had been released.
How about agreeing a convention for test reports? For example, reports with comment starting with TEST should be ignored and filtered out on notifications.

[alberto]

Couple of additional ideas (let me know if this starts getting annoying )

* Users insight

I think it will be good gain more insight into why and who run into common misconfigurations. Or at least collect the key data to enable further statistical analysis in the future if required. Understanding this can help improving the relevant user-interface / process.

Why someone does not have an active subscription? Because he did not subscribe at all, or because he mistakenly disabled an existing one (or a rogue extension did that)? Was he not reminded to add a subscription because he already had custom filters? Are these novice users that just installed the extension?

This is another way to look at the usefulness of collecting information regarding disabled subscriptions. BTW, the report could show only active ones for simplicity, but the information is still collected. Also, you could report (privacy concerns aside) on when ABP was installed first time, last upgraded, and number of custom filters (or if there are any).

* Disabled filters in an active subscription

May be a rare scenario / edge case, but difficult to troubleshoot unless you have the relevant information. I think the list of blockable items in ABP already shows disabled filters that would have matched (but not element hiding ones?). Should this be reported too? Alternatively, a first glance view on how many (or if there are) disabled filters are in an active subscription.

[Michael]

Also, you could report (privacy concerns aside) on when ABP was installed first time, last upgraded, and number of custom filters (or if there are any).

Personal data should not be transmitted unless there is a genuine need to do so; EasyPrivacy was created to remove tracking from the internet, and should hardly be implemented by an add-on that actively engages in such frivolous reporting.

[Hubird]

I have to agree with Michael, only the bare minimum of information should be collected. The idea behind this was not to gain user insight and not to collect statistical data such as the number of subscriptions a user has.

[fanboy]

If personal infomation were to be transmitted, have an option [x] Submit active rules/items (and any privacy infomation) ...because not having this sort of infomation doesn't help when with help fixing peoples issues. Notify the maintainer becomes useless when diagnosing false positives without this infomation.

[alberto]

@fanboy: this already sends the essential (personal) information to efficiently troubleshoot an issue. I have suggested few additional bits to cover edge cases. You can see the details in previous entries on this topic.

@Michael, hubird:

There are c9.5 million active users (according to AMO), and many new users every day. If you get hundreds/thousands of reports indicating a misconfiguration (e.g. no active subscription), you will want to know WHERE is going wrong. The statistical analysis of the key data can provide insight on why this is happening. Especially useful if you don't have a way to contact users and/or time to analyze all reports. (As an example, look how Mozilla uses Firefox crash reports -- statistical analysis and correlations)

Perhaps you will feel more comfortable waiting until that point (i.e. getting thousands of reports) to eventually collect additional pieces of information.

Alternatively, we could offer something like "[ ] Send additional information to help improve this product" (opt-out by default), which could collect the following (arguably non-essential) information
- Has user installed recently Y/N
- Has user upgraded recently Y/N
- Is using custom filters Y/N
- List of extensions

Note that each of these pieces of information is aimed towards gaining insight on common misconfigurations (e.g. no active subscription -- why?) and NOT for the sake of customer insight per se (e.g. average number of custom filters, etc)

[Wladimir Palant]

@fanboy: There isn't an option not to send potentially private data - because without this data the report is worthless. We can try to avoid unintentionally collecting sensitive data but that's as far as we get if this feature needs to stay useful.

@alberto: Gathering user insight is definitely not the goal of this feature and would be an unexpected side-effect that I would like to avoid. I have some thoughts on a separate feature to gather some user insight (which we do need indeed) - but it would be something very different. Already because getting insight only from users who report issues would distort the sample.

Getting disabled filters is a good idea - but not to attach them to the report. If the user reports a missed ad his attention can be brought to disabled filters that would have matched with an option to re-enable them. This is something that the extension can do automatically.

Attaching a list of extensions: this isn't useful for false positives or missed ads but it could be valuable if "Other issue" is selected. So attaching this data in this (probably rare) case only might be a good idea. Any opinions on that?

As to hashing extension IDs a la Test Pilot: it isn't as effective as it sounds. Getting all extension IDs out of addons.mozilla.org isn't hard. One can then calculate the hashes for all of them and deobfuscate the extensions in the report. So this feature is essentially useless, anybody who really wants to get extension names from a report can always do so.

[alberto]

Getting disabled filters is a good idea - but not to attach them to the report. If the user reports a missed ad his attention can be brought to disabled filters that would have matched with an option to re-enable them. This is something that the extension can do automatically.

This will only work with disabled blocking filters but not disabled element hiding filters (cannot tell if it would have matched or not). Also, this notification may not be always relevant. For example, if the user disabled a problematic filter in Easyprivacy, he may still want to report an issue with Easylist. Very specific case, I know, but just to highlight this scenario may not be as straightforward as it sounds.

I appreciate you want to send only essential information (and only if required), but if the user still decides to send a report, maintainers deserve to know if there were any disabled filters in their lists. It does not need to attach the disabled filters, but a flag that indicates if there were disabled filters. In any case, a comparison of filters between report and standard case will reveal which filters are these, so not sure how much you can do there privacy-wise.

I'm wondering how much "troubleshooting" logic (if any) should be placed in the client-side i.e. extension itself. I quite liked the idea of server-side analysis and feedback, because a) provides flexibility to tweak/evolve as you gain more insight in common issues b) same logic will be applied to all ABP versions going forward c) can provide many tips and sort by relevance.

[Wladimir Palant]

This will only work with disabled blocking filters but not disabled element hiding filters (cannot tell if it would have matched or not). Also, this notification may not be always relevant. For example, if the user disabled a problematic filter in Easyprivacy, he may still want to report an issue with Easylist.

Yes, both issues are true - but I think we can live with them.

I appreciate you want to send only essential information (and only if required), but if the user still decides to send a report, maintainers deserve to know if there were any disabled filters in their lists. It does not need to attach the disabled filters, but a flag that indicates if there were disabled filters.

Yes, sending the number of disabled filters sounds like a good idea.

I'm wondering how much "troubleshooting" logic (if any) should be placed in the client-side i.e. extension itself. I quite liked the idea of server-side analysis and feedback, because a) provides flexibility to tweak/evolve as you gain more insight in common issues b) same logic will be applied to all ABP versions going forward c) can provide many tips and sort by relevance.

The server has limitations - it can tell the user that disabled filters might be responsible for the issue but it will be up to the user to find a way to enable these filters again. The extension is more flexible - it can list these filters along with a checkmark to enable, it can even reload the original page automatically to see whether it fixes the problem. So common problems that can be addressed in the client definitely should be addressed in the client.