Revisit the setting "Disable hyperlink auditing/beacon"

[gorhill]

I find that with Chromium 54, the tab id of network requests of type beacon (those fired as a result of using navigator.sendBeacon) is now properly set. This means it is now possible to identify from which tab a beacon request originates, and thus it can now be plainly filtered like any other network request.

This means I should revisit the "Disable hyperlink auditing/beacon" setting:

• Rename "Disable hyperlink auditing".
• Add "Disable beacons" (enabled by default).

[gorhill]

Observations:

• [beacon bad]: Loading https://medium.com/@ageitgey/machine-learning-is-fun-part-4-modern-face-recognition-with-deep-learning-c3cffc121d78, a network request of type beacon is fired. This is a csp-report, which is fired as a result of uBO redirecting Google Analytics script to uBO's neutralized, data:-URI based script (the page's CSP does not allow data:). Not blocking this request causes information to leak.

[VanguardLH]

I was just about to open a new ticket about navigator.sendBeacon. I came across an old 2012 article at http://www.wilderssecurity.com/threads/hyperlink-auditing-aka-a-ping-and-beacon-aka-navigator-sendbeacon.364904/ that mentions this method of sending info back to the server. It refers to https://bugs.chromium.org/p/chromium/issues/detail?id=360603 that describes the Beacon API.

In Firefox, I didn't have to change beacon.enable since it was already disabled (False). In Google Chrome, I had to go into chrome:flags and click on Disable (which then became Enable) for the Hyperlink Auditing setting.

I noticed with uBlock Origin installed in Firefox that in about:config the beacon.enabled settings is set to False (disabled). I don't know if uBO did that or if the setting got added but was initially coded to be disabled until later when it might be enabled by default. I found no obvious setting in uBO that would disable this beacon function in Firefox.

Google Chrome has its chrome:flags setting of "Hyperlink auditing" that I can disable (it no longer has the "Disable prefix" so you don't enable the disable but instead disable the enable). Is that the same as the Beacon API?

Would be nice if uBlock added a "Disable tab beacons" option so users don't have to delve into about:config or chrome:flags. Seems Google added this to augment their Analytics service. Don't know why Mozilla is "working" for Google to add this, um, anti-privacy feature.

[gorhill]

Details about the fix:

uBO will no longer blanket-block network request of type beacon -- these will now go through the filtering engine like any other network requests.

Two exceptions in the handling of beacon requests:

• "Tabless" (a.k.a. "behind-the-scene") beacon requests will still be blanket-blocked, with the assumption that these are used as some sort of hyperlink auditing or similar purpose. This means that for Chromium 52 and earlier, the handling of beacon requests is unchanged, because they were always reported as behind-the-scene network requests (related: Chromium issue 522124).
• CSP-report related beacon requests will be blocked as "spurious CSP report" if uBO internally redirected at least one resource on the page. If a CSP report is fired and uBO did not internally redirect any resource on a page, the beacon request will be filtered according to the active filters/rules. There is Chromium issue 637577 being worked on which will simplify a bit uBO's Chromium-specific code for for this specific scenario.

I did not add an option "Disable beacon", because now these will go through the filtering engine as any other network requests -- and there are many legitimate use for beacon requests. For this reason, I removed the code tampering with Firefox's beacon.enabled setting, which purpose was merely to align uBO's behavior on Firefox with that of Chromium.