Bug: Set default by UserChoice is often rejected on clients from China
Status: NEW
Priority: --
Created: 2021-08-12 23:20:25+00:00
Resolved: 2021-09-07 22:41:30+00:00

Summary: This is strongly correlated with Qihoo 360 Safeguard.

(Apologizes as always that the links to data are internal-only.)

[Early results](https://sql.telemetry.mozilla.org/queries/81420/source#201944) for UserChoice (aka one-click set default) in release 91.0 are 2% ErrExeRejected: we were able to check and overwrite the hash, but we weren't successful in setting ourselves as default. This is surprisingly high, and worrisome because it might leave the user without a default browser. In this case (or any other error) we show Default App Settings to allow the user to manually set the default, but this is not ideal, especially on Windows 11 (bug 1719832).

95% of clients reporting ErrExeRejected have normalized_country_code = CN, this is 20% of all CN clients reporting UserChoice results, while the percentage is negligible for all other country codes. Most of these ErrExeRejected results come with OS locale = zh-Hans-CN, Firefox locale = zh-CN, distribution id = MozillaOnline (the repack for China), but the same is true for Success, so it doesn't seem to be directly related to locale.

I suspect a security (antivirus, antimalware) product that watches or intercepts shell32 or registry activity and thus interferes with the check/set. I ran a [query](https://sql.telemetry.mozilla.org/queries/81470/source#202035) looking at UserChoice result by antivirus, there's a very strong correlation to Qihoo 360 Safeguard (not to be confused with Norton 360, or with the worldwide Qihoo 360 Total Security product, which logs but doesn't block changing default browser). We missed this in our early testing with antivirus and antimalware products, likely because it is only available in Chinese.

Consider [this query](https://sql.telemetry.mozilla.org/queries/81472/source#202040) looking just at CN: Over half of the users who tried to set default (52%) with 360 Safeguard installed had a ErrExeRejected result, versus 2% with the default Microsoft/Windows Defender (which had a similar total to 360), 12% with other AV, 15% with no AV (likely some malware or other AV that disabled Defender without registering itself with Windows).

I tested out 360 Safeguard and it is definitely getting in the way when we try to set the default browser. I was able to get ErrExeTimeout when a prompt was shown asking whether to allow changing the default (default-browser-agent.exe couldn't return until the prompt finished), and ErrExeOther when I told 360 to disallow changes (likely a registry write error), however I did not see ErrExeRejected. It's possible that 360 Safeguard often appears alongside a browser that aggressively forces itself back to default, but the most likely candidate (360 Secure Browser) doesn't seem to do that currently. QQ Browser does something like this (in connection with its own antivirus product, QQ管家), but in a way that seems to bypass the registry altogether.

I'm going to keep my eye on this over the next week, but I don't think there's much we can do. At most we might want to never attempt setting UserChoice if we detect this particular antivirus.