Address "Hyperlink auditing"

[gorhill]

What an horrible "feature" from a user perspective. Sigh.

References:

• http://www.wilderssecurity.com/threads/hyperlink-auditing-aka-a-ping-and-beacon-aka-navigator-sendbeacon.364904/
• http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing

Possible solutions:

• https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action

[gorhill]

Solution: https://github.com/gorhill/httpswitchboard/wiki/On-privacy#hyperlink-auditing

Having to blacklist the other column might not always be practical though. Need to look to also implement a solution to globally disable hyperlink-auditing.

[jonvuri]

I'm sure you're already aware but there is a Chrome flag to disable it: chrome://flags/#disable-hyperlink-auditing

It might be easier to just recommend that people turn that on.

I'm sure you're already aware but there is a Chrome flag to disable it:
chrome://flags/#disable-hyperlink-auditing

I wonder if that switch really works. Regardless if I enable or disable it,
chrome://version/ doesn't display it. And that switch is not listed on
http://peter.sh/experiments/chromium-command-line-switches/ which is
normally
complete. There is a --no-pings switch, though.

[gorhill]

I'm sure you're already aware but there is a Chrome flag to disable it: chrome://flags/#disable-hyperlink-auditing

No I wasn't aware. I looked at it and it says it's not enabled, and yet the jsfiddle above showed that hyperlink auditing was working.

[gorhill]

Turns out it is easy to detect and block globally: outgoing headers will have:

• Ping-From: value is the URL where the auditing occurred (just like an HTTP referrer)
• Ping-To: value is the URL where the auditing is reported (can be a third-party...)
• Content-Type: value is text/ping

So the request can be canceled at that point, as chrome.webRequest.OnBeforeSendHeaders() is one of the only three API which can be executed in blocking mode.

The Ping-From header is interesting because this may allow me to actually bind the hyperlink-auditing to the page where it occurred, and hence the user can be informed more conveniently. As said, it's currently reported in the behind-the-scene matrix because the reported tab id is -1, but now the value of Ping-From can be used to find the proper tab entry here it can be recorded.

So at this point this is the work to be done:

• Put code in there to foil hyperlink-auditing attempts.
• Add a checkbox so that hyperlink-auditing can be foiled globally
• Whenever possible, report hyperlink-auditing into the matrix of the page where it occurred.
• Count and report to the user the number of foiled hyperlink-auditing attempt (just like HTTP referer, etc)
• Record an entry in the request log so that hyperlink-auditing occurrence are visible

[jonvuri]

I looked at it and it says it's not enabled, and yet the jsfiddle above showed that hyperlink auditing was working.

@gorhill Are you sure you had the flag on? The effect of the flag being enabled is to disable hyperlink auditing. The "enable" and "disable" link below it is to turn the flag itself off and on. So if it looks like this:

That means that the flag is currently enabled, so no hyperlink auditing pings will be sent, while if it looks like this:

That means that the flag is disabled, so hyperlink auditing pings will be sent. This is the default.

When I enable the flag and run that Jsfiddle (http://jsfiddle.net/Ronny/5ntzw/), I don't see any hyperlink auditing pings sent.

[gorhill]

Oh I see, I understood it was doing the opposite.

I will still leave the option there as it's more user-friendly, and I like the ability to be able that there were attempts at hyperlink-auditing. So far I haven't seen any though.