Identify issues with 3rd party software

[adamopenweb]

We see many issues similar to: https://github.com/webcompat/web-bugs/issues/20319. Where it's likely there is a 3rd party software causing issues with Firefox for users. In most cases we can't help and the report is anonymous so further investigation doesn't happen.

Hypothesis Grouping these types of issues by label and collecting available information about the registered Antivirus vendor would allow us to aggregate reports and use as an indicator that the software is causing issues for Firefox users. We could then use our established relationships to ask the vendor to investigate and remedy the issue.

We have anecdotal evidence from about:support which could be used to make a decision about data collection, or prompting the user to provide more information.

It's also likely we can detect if the report happened on a page with a Cert error. Which would minimize data collection further, to only issues / reports where we think there's value.

To be clear I would expect that if we explored this, we would make it known in the webcompat report that we are collecting the AV vendor and any other related information.

[miketaylr]

We have anecdotal evidence from about:support which could be used to make a decision about data collection, or prompting the user to provide more information.

I think this is a good idea. The more environment data we have access to, the better.

Do you know what it would look like from about:support if someone had AV software installed? Do you have an example?

[adamopenweb]

@miketaylr

[miketaylr]

Ah, cool! Makes sense that I didn't see that... because I don't have anything installed.

[rtestard]

Great idea, I'll just add more info about related activities for context:

• AVs can break HTTPs on Firefox (we previously saw instances with large impact where AVs poorly integrated with our cert store meaning HTTPs broke on Firefox but worked on other browsers since all others integrate with OS cert stores). I raised this bug to help quantify and address since right now we're telemetry blind on such occurences https://bugzilla.mozilla.org/show_bug.cgi?id=1494571
• https://webcompat.com/ is served over HTTPs, if HTTPs is broken on Firefox it's much harder for users to submit such issues since they'd have to open another browser, we may undercount these instances
• The about:support data on AV is available on telemetry (see an example here https://sql.telemetry.mozilla.org/queries/58995/source#152810). In the example https://github.com/webcompat/web-bugs/issues/20319 the user would not be submitting telemetry since telemetry is sent over HTTPs that is blocked for him so asking him to inform us about what he sees in about:support would work best

If we can prove with https://bugzilla.mozilla.org/show_bug.cgi?id=1494571 that the population size encountering such issues is large then we'd implement a HTTP fall-back for telemetry that would allow quantifying, trending and correlating such issues with AV vendors, we're probably 6 months away from that. In the mean time if you have evidence of such issues in the wild it would be super useful to help push https://bugzilla.mozilla.org/show_bug.cgi?id=1494571 forward since we're currently debating value of doing it VS our policy that currently makes it hard to bring HTTP end-points to our infrastructure. SO thanks for commenting on the bug if you could share how many such reports you saw or what share of web compat reports it may represent.