Safari Link Tracking Can No Longer Be Disabled
Notice that when you hover over the “Ping Me” link, you only see the
href
URL, you don’t see theping
URL, so you don’t even know that the attribute exists unless you look at the HTML page source. When you click the link, it loads the pagehttp://lapcatsoftware.com/
as expected. But it also sends an HTTP POST request tohttp://underpassapp.com/
without any visible indication to the user. You can only see it if you do a packet trace. It should come as no surprise that the primary usage of hyperlink auditing is for tracking of link clicks.[…]
Apple shipped Safari 12.1 last week to the public with no way to disable hyperlink auditing. I hope to raise awareness about this issue, with the ultimate goal of getting hyperlink auditing disabled by default in Safari. Apple claims that Safari is supposed to protect your privacy and prevent cross-site tracking, but hyperlink auditing is a wide open door to cross-site tracking that still exists.
If anyone is curious why this attribute was introduced: it’s supposed to be an alternative to those chains of redirects that publishers often put in front of outbound links.
User gets a direct link to destination instead of redirects (good), publishers and advertisers still get their data async (creepy, but arguably better than the alternative)
Imo is fine as long as there’s an opt-out, which chrome and ff have but oddly Safari just dropped.
Is Apple’s reasoning that making it an option would prevent sites from using ping
? It’s better to have access to the real URL with a compulsory ping
than to be forced to use a redirect chain that’s slower and no more private.
Previously:
Update (2019-04-08): Lawrence Abrams (via Hacker News):
With privacy and online tracking being such a large problem and major concern for many users, you would think that browser developers would give you the option to disable anything that could affect your privacy.
Unfortunately, this seems to be going in the reverse direction when it comes to hyperlink auditing.
[…]
Of all the browsers I tested, only Brave and Firefox currently disable it by default and do not appear to have any plans on enabling it in the future.
[…]
It turns out that Google uses hyperlink auditing in their search result pages. Every time you click on a search result link, your browser will also send HTTPS POST request back to a Google url in order to track the click.
Anchor ping is not an alternative form of tracking, it’s an additional form of tracking. We still have all the other forms of tracking along with this one. It may be true that if advertisers don’t have anchor ping, they’ll just use alternative methods, but the belief that advertisers won’t use alternative methods of tracking if they have anchor ping has proven to be completely false. Anchor ping also turns out to be an advertiser’s dream feature. It’s completely invisible to the user, and it’s more powerful and reliable than the other tracking methods.
[…]
Anchor ping was supposed to be transparent as in easily perceived by the user. Instead, anchor ping has become “transparent” as in invisible to the user. The browsers never informed the user about the ping notifications. And now browsers such as Safari and Chrome are removing the ability of the user to disable the notifications. As far as privacy is concerned, this is not “a wash” compared to previous tracking methods. It’s a cover-up.
Update (2019-04-09): Nick Heer:
I still can’t figure out what users gain by not being informed of both the target URL and the redirect. When links are being used for tracking purposes, it makes sense to show the contents of the
href
so that users aren’t misled; but, if we start assuming all browser features will be used maliciously, it is easy to see why theping
attribute should also be visible to the user.
Update (2019-04-11): Lawrence Abrams:
Researchers have found that the HTML feature called hyperlink auditing, or pings, is being used to perform DDoS attacks against various sites. This feature is normally used by sites to track link clicks, but is now found to be abused by attackers to send a massive amount of web requests to sites in order to take them offline.
[…]
The yo.js script, shown below, would randomly select one of the above sites and create a HTML ping URL with that site as the ping target. It would then programmatically click on the link as shown by the link.click() command.
The JavaScript would then create a new HTML ping URL and click every second. So the long a user was on this page, the most clicks they would generate.
Update (2019-04-12): John Wilander:
Just turning off the Ping attribute or the Beacon API doesn’t solve the privacy implications of link click analytics. Instead, it creates an incentive for websites to adopt tracking techniques that hurt the user experience. In effect, the choice between supporting Ping and not is not one of privacy, rather it is a choice between a good user experience and a bad one.
[…]
Until recently, Safari supported an internal User Defaults flag to disable support for the Ping attribute. It was never our intention to surface this flag as a customer setting. We think it’s misguided to offer users the ability to disable web-facing features if doing so doesn’t disable or prevent the ends of that technology. Instead, Intelligent Tracking Prevention and Content Blockers offer users different levels of support for categorically affecting link click analytics.
However, currently it seems like neither can be used to categorically block pings.
The Chromium team is finally coming around[…]
[…]
I think Apple just found itself on the wrong side of history, now as the only browser vendor defending a user tracking technology.
We agree that
<a ping>
should be more transparent. I publicly filed this bug to track improving this for WebKit and Safari[…]
This is weird because his bug notes that Safari is not to spec, yet Wilander’s blog post makes it sound like the Safari team likes the current behavior.
Update (2019-04-16): Jeff Johnson (tweet):
Fortunately, I have a solution for you now! Last night (as soon as I could get approved by Apple) I released StopTheMadness 6.0 in the Mac App Store. If you click on a link with the “ping” attribute, StopTheMadness 6.0 will now remove that “ping” attribute, thereby preventing your clicks from getting tracked by hyperlink auditing.
Lawrence Abrams (via Hacker News):
Mozilla has told BleepingComputer that they will be enabling the tracking feature called hyperlink auditing, or Pings, by default in Firefox.
[…]
After Mozilla’s response, we also contacted Brave Software to ask if they had any plans to enable hyperlink auditing in their browser.
“Disabling hyperlink auditing is a crucial privacy feature, and Brave has always disabled this by default,” Catherine Corre, Head of Communications at Brave Software, told BleepingComputer via email. “Brave users expect this protection from our browser.”
Today, Google shipped Chrome 74 to the public, and this hidden preference is now indeed gone for everyone. The change log for Chrome 74 includes the removal of
disable-hyperlink-auditing
from Chromium.
3 Comments RSS · Twitter
From a privacy point of view, it's better to let site use ping.
When using redirect, the browser don't know before hand that the link point to a tracking URL with a redirect, while with the ping, it perfectly knows what the URL intent is, and can limit the amount of data it send to it to limit user tracking.
Moreover, developing an extension that remove ping attribute should be quite easy to do.
Is Apple’s reasoning that making it an option would prevent sites from using ping? It’s better to have access to the real URL with a compulsory ping than to be forced to use a redirect chain that’s slower and no more private.
I do not agree. The latter is at least obvious to the user and, because of the need to maintain transparency of URLs when hovering over links or for robots, can at least generally be clobbered by disabling JS. For the company that believes privacy is a fundamental human right * to support what is clearly a privacy-violating feature and leave no way to disable it is a great disappointment.
I wonder whether the "raw" filter of the content-blocking API can be used to mask these URLs. I shall have to test, when I can be arsed.