[Desktop] consider removing list of fingerprint attempts blocked from shields

[LaurenWags]

Description

While testing #10000 I noticed that using 1.11.x I could not get any FP attempts listed as blocked in shields (it was always 0), even when expected and the setting was set to the highest level of "strict".

Comparatively, using the highest FP setting on 1.10.x did show a number for FP attempts listed as blocked (2 in my example below).

I asked @pes10k about this and he mentioned that this list was not all that useful and often resulted in a a lot of false positives. He recommended removing this list since it's not all that useful.

Steps to Reproduce

1. Using 1.10.x, set default shields setting for FP to block fingerprinting.
2. Visit https://dev-pages.bravesoftware.com/farbling.html and generate fingerprints. Note shields lists 2 blocked and you can view them.
3. Using 1.11.x, set default shields setting for FP to strict.
4. Visit https://dev-pages.bravesoftware.com/farbling.html and generate fingerprints. Note shields lists 0 blocked.

Actual result:

1.11.x on the left, 1.10.x on the right

Expected result:

Remove list of blocked items per recommendation from @pes10k

Reproduces how often:

Brave version (brave://version info)

Brave	1.11.85 Chromium: 83.0.4103.116 (Official Build) dev (64-bit)
Revision	8f0c18b4dca9b6699eb629be0f51810c24fb6428-refs/branch-heads/4103@{#716}
OS	macOS Version 10.14.6 (Build 18G3020)

Version/Channel Information:

• Can you reproduce this issue with the current release? no
• Can you reproduce this issue with the beta channel? yes
• Can you reproduce this issue with the dev channel? yes
• Can you reproduce this issue with the nightly channel? yes

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields?
• Does the issue resolve itself when disabling Brave Rewards?
• Is the issue reproducible on the latest version of Chrome?

Miscellaneous Information:

cc @rebron

[pes10k]

Just seconding @LaurenWags above. The "FP attempts" list was never very useful, bc of the high number of false positives. And now that we deploy protections in all frames by default, and cover even more APIs, it'll be even worse noise-to-signal. My vote is to remove the dropdown for fingerprinting attempts all together

[ryanbr]

Could it be useful for debugging purposes?

[pes10k]

I think if we'd like to add it for debugging purposes we could think about integrating it with the devtools, but right now, its not doing anything (i.e. that field will always be empty), and if we reported all touches to those APIs there, we'd have an enormous number of false positives. I still vote for removing, but would be a-ok with another follow up issue adding debugging information to the console

[cjwijtmans]

I like to keep it. Especially if there are "false-positives", more reason to.

[pes10k]

@cjwijtmans it will always be empty currently. We don't think we can confidently distinguish FP from actual fingerprinting, which is part of the reason we moved to the farbling / randomization approach for defenses too

[pes10k]

Closing bc we not longer report any fingerprinting information in shields (since the false positive rate is too high to be useful)