Add "share filters" option to the "Add Filter(s)?" dialog box in ABP for Chrome

[nicole]

Background

Currently, when users add manual filters we don't track this. In order to proactively improve the quality of filter lists, when a user manually adds a filter we offer the user an option to share with Eyeo, and the manual filter add is captured and stored.

Meta Issue: #2535

What to change

• Add checkbox to the "Add Filter(s)?" dialog box to allow users to share the filter information with ABP.
  • Text by checkbox: "share filter info with Adblock Plus"
  • Location: bottom left corner (see attached image​)
  • The checkbox should be unchecked by default
  • There should be a link to ​https://adblockplus.org/redirect?link=addfilter_privacy&lang=en-US (addfilter_privacy doc link) next to the checkbox, link title should be "Privacy policy."

• When the checkbox is checked, clicking "Add" should capture and transmit the following information in addition to adding the filter:
  • Filter text of newly created filters separated by newline character
  • Active filter subscriptions
  • Webpage URL (should be anonymized by removing parameter values)
  • Extension, browser and platform info

• Fail silently if an error occurs but make sure to log the error nevertheless.

The data should be transmitted to the existing issue reports backend (report_submiturl preference: https://reports.adblockplus.org/submitReport?version=1&guid=%GUID%&lang=%LANG% where %GUID% is generated randomly). Method is POST, with headers Content-Type: text/xml and X-Adblock-Plus: 1. The data should look like this:

<report type="addfilter">
<adblock-plus name="adblockpluschrome" version="1.9" locale="en-US"/>
<application name="chrome" vendor="Google Inc." version="43.0" userAgent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36"/>
<platform name="chromium" version="43.0"/>
<subscriptions>
<subscription id="https://easylist-downloads.adblockplus.org/ruadlist+easylist.txt" disabledFilters="0" version="201506101551" lastDownloadAttempt="-77705" lastDownloadSuccess="-77705" softExpiration="203473" hardExpiration="613495" downloadStatus="synchronize_ok"/>
<subscription id="https://easylist-downloads.adblockplus.org/antiadblockfilters.txt" disabledFilters="0" version="201506100930" lastDownloadAttempt="-101133" lastDownloadSuccess="-101133" softExpiration="-5815" hardExpiration="71667" downloadStatus="synchronize_ok"/>
</subscriptions>
<window url="http://example.info/?param1=*&param2=*" referrer="http://example.info/"/>
<comment>||example.com^</comment>
</report>

[nicole]

Dialog Box

[greiner]

What's the reason for including which browser a filter was created on? Note that we're automatically getting that information anyway but depending on your use-case, other environment information might be more useful.

@sven What do you think about the suggested UI? I'd imagine there might be issues with other languages.

[sven]

@greiner, thats right.

I created a quick mock-up which should solve the problem.

(The buttons don't need to be blue, but i saw that they are in a grey which could be seen as inactive. We will tackle this problem in another issue)

[trev]

I added some more info to the description - this data is supposed to be sent to the existing reports backend, consequently the format is fixed. The example data is mostly identical to what the issue reporter in Firefox is sending (note that all timestamps related to subscriptions are being sent as relative values). The difference is that some data is missing, also the name attribute on the <adblock-plus> tag is new.

[greiner]

I got a couple more questions:

• How is the data supposed to look if multiple filters are added at the same time? Should we include multiple <comment> tags?
• What should happen if we fail to send the data? Should we show an error message, try to send the data at a later point again or not send it at all?
• Users can also add custom filters via the options page. Is the plan to create a separate ticket for adding that checkbox to the new options page as well or was this intentionally left out?

[nicole]

Multiple filters should be split into separate records.

If the data send fails, I think we should just not send it at all. Since this is optional information, we don't want to bother the user if the send fails, unless we could have the send try again somehow in the background (not impacting user).

That's a good idea for the new options page, should I create a new issue and link to this as the meta issue? Or should the new options page be the meta?

[trev]

Not so sure, I'd rather generate a single report for multiple filters - these belong together. I'd simply create a multi-line comment then.

I agree that a failure to send the data isn't important here.

Adding filters on the options page is a different thing - we don't have any context information whatsoever, meaning that the report won't be of much value. IMHO not worth doing.

[greiner]

Modified the description accordingly. I think a multi-line comment makes sense, agreed, to keep the payload size low.

@nicole Could you please find out whether there's value in having this in the options page or whether the lack of context makes those filters useless for us? Feel free to create a separate issue if it turns out to be sufficient.

[greiner]

Closing this ticket in favor of ​ui#36.