PrivacyBadger is missing blocking of HTML5 cookieless tracking (ping attributes)

[charlesprogrammr]

With HTML5 came a new attribute to allow tracking of which links on a page are followed, which means we don't even have to click them. The attribute in question is called the _'ping' attribute_, and I don't see anything anywhere that addresses its abilities. PrivacyBadger should strip these attributes from each and every page to stop the use before its use becomes widespread.

[michael-oneill]

A very good point. Here is a description of it http://www.w3schools.com/TAGs/att_a_ping.asp

From: charlesprogrammr [mailto:notifications@github.com]
Sent: 25 August 2015 19:37
To: EFForg/privacybadgerchrome privacybadgerchrome@noreply.github.com
Subject: [privacybadgerchrome] PrivacyBadger is missing blocking of HTML5 cookieless tracking (#587)

With HTML5 came a new attribute to allow tracking of which links on a page are followed, which means we don't even have to click them. The attribute in question is called the 'ping' attribute, and I don't see anything anywhere that addresses its abilities. PrivacyBadger should strip these attributes from each and every page to stop the use before its use becomes widespread.

—
Reply to this email directly or view it on GitHub #587 .

[cooperq]

Seems worth doing, I doubt this would even break anything we care about.

[charlesprogrammr]

Thanks, Michael. Thanks, Cooper.

[gunesacar]

I checked how ping requests appear in onBeforeRequest listeners and found that tabID and the frameID of the ping requests are set to -1.

So PB can't know which tab and frame the pings belong to and thinks that they come from an internal tab since they satisfy the tabId < 0 condition in _isTabChromeInternal.

Ping requests have details.type = ping, so it's easy to distinguish them from other requests. PB could block all pings to tracking domains, but I can't think of a way to exclude pings of tabs that PB is disabled on.

Following Chrome bugs should be the root cause:
https://crbug.com/522124
https://crbug.com/522129

Not sure, what to do about that.

[cooperq]

Hmm interesting. Another option would be to block all ping requests. @gunesacar @michael-oneill how much do you think this would break stuff?

[michael-oneill]

I doubt if it would break anything the user would care about, though it might stop some data going to the collectors. This is another situation where per-site user consent would work. If DNT header is not 0 in the beacon request, block it.

[gunesacar]

Here are some use cases I ran into:

• https://crbug.com/611453 (first comment)
• Ignoring ping filters gorhill/uBlock#1493 (comment)

Yet, I agree with @michael-oneill; blocking pings shouldn't break any critical functionality.

[gunesacar]

This block-all-the-pings approach only needs to be there until the Chrome bugs are fixed (then we'll know which tab/frame/origin is the initiator).

The good news is, one of the Chrome bugs is already fixed and landed in the dev channel. Motivated me to send a PR, but feel free to ignore if you think we better wait or not happy with the following behavior:

1. PB will block all pings sent by open tabs until #522124 is landed (already landed in Chrome dev)
2. PB will block all pings sent on onunload events until #522129 is landed
3. Once the fixes are landed, PB will treat pings as any other request