1. 64
  1.  

  2. 13

    I had no idea this kinda thing even existed. It probably does make sense to disable it by default, as I’m not sure there is a good use case. But then again, you can achieve the same thing with JavaScript.

    1. 14

      IMO that makes this all the more pernicious - this is the kind of behavior people who go to the lengths of disabling Javascript are trying to avoid I’d think.

      1. 5

        That’s the thing: Google et al will try to track your clicks anyhow. They’ve always done that with Javascript and/or link rewriting – which works by default and has to be blocked on a site-by-site basis. You want them to do it with a standard feature instead because then you can block all of them the same way. But if they can expect the standard feature to be disabled by default then it’s useless to them and they’ll just keep right on doing what they were doing before. So for you to be able to meaningfully disable the standard click tracking feature, it must be enabled by default…

        I expect the whole idea to not work out in the long run because the incentive structure is metastable by a razor’s edge in the best case. It’s marginally more favourable but broadly similar to the Do Not Track header – which died a quiet death not long ago.

        1. 3

          You can still try to defend yourself: https://github.com/Rob--W/dont-track-me-google

          1. 2

            I use a different extension, “Avoid Google Search redirects” (Firefox Add-ons page). I hadn’t heard of the one you linked. There is probably no significant difference.

            1. 2

              … on a site-by-site basis, yes, as I already said. Getting them to use ping would mean there’d be no “try” about it and it’d be called “dont-track-me” instead of “dont-track-me-google”. And that is the point I was making – not that it’s impossible to defend yourself against the non-ping approaches. If they used ping exclusively, you’d have a cheap, reliable, broad defence, rather than the only intermittently reliable and hard-to-scale defences we have today.

            2. 3

              The Do Not Track header didn’t work out because it cost site authors to implement, and didn’t provide any direct benefit.

              This HTML5 link tracking costs site authors about the same as what they’re doing already (set up a server-side script to collect pings, swizzle elements on rendered pages), but provides them some benefits: it makes external links load quicker (because they don’t go through a redirection), so their site is more pleasant to use, and it doesn’t obscure the Referer header — which they don’t much care about for outgoing links, but they care very much about for incoming links.

              The fact that it can also be easily neutered by the browser is irrelevant to them, as long as not many installed browsers are doing it.

              1. 2

                It did provide some legal cover for tracking, so it did have some benefit, albeit a much weaker one. But that alone wasn’t its death knell. What did it in was when Microsoft flipped to sending it by default in their browsers, since that undermined its benefit (however weak) as a signal of conscious user intent.

                It had the same “asking sites to make their invasiveness easy to defend against by promising that users will have to consciously choose to defend themselves (which most won’t)” incentive structure. It was just worse – as I’d already said – for the reason you gave, that it was harder to implement than ping is, and had murkier benefits to site owners – which I skimmed over (as I was only referencing it tangentially as a parallel).

                I don’t expect ping to ever kill off or even broadly supplant non-ping click tracking techniques, even if it doesn’t vanish as quickly and completely as DNT did. I’m pretty sure it cannot serve its intended purpose because site owners will always have reason to agitate for less user control over it and users will always have reason to agitate for more, both of which undermine it – and I don’t see how that tug of war can ever settle into a stable configuration for long.

                1. 3

                  What did [the Do Not Track header] in was when Microsoft flipped to sending it by default in their browsers, since that undermined its benefit (however weak) as a signal of conscious user intent.

                  The second half of that sentence is partly wrong – the most important conscious user signal remained available. Advertisers lost a strong opt-out signal (DNT: 1 and DNT: null became indistinguishable), but the strong opt-in signal (DNT: 0) remained available and strong. Is opt-in required to track somebody, or is lack of opt-out sufficient? Advertisers were banally pushing for the latter, of course.

                  ‘User consciously opts in to tracking’ is famously the standard that the GDPR requires. The IE 10 DNT kerfuffle pre-dates the GDPR. It took place in late 2012; in 2015 Microsoft announced it would go back to null-DNT by default; the GDPR was adopted on 14 April 2016, and became enforceable beginning 25 May 2018. If the GDPR had already been in place to give Microsoft’s ‘opt-out is the default’ stance extra, legal, force, that might have been interesting in ways that this margin is too narrow to contain are too off-topic to type out on my phone.

          2. 9

            I haven’t found a free moment to build this into a browser extension just yet, but here’s the crux:

            Array.from(document.getElementsByTagName(‘a’)).map(a => { if (a.getAttribute(‘ping’) !== null) { a.removeAttribute(‘ping’); } })

            This will check the page for anchors with ping attributes and remove them.

            1. 7

              I’d really, really like to hear the justification for removing the “disable link tracking” configuration option in Safari and Chrome. I love the idea of link tracking, because it moves a privacy-invading behaviour from the server (out of my control) to the client where I can control it… but that only matters as long as the client actually lets me control it.

              The author says “I hope to raise awareness about this issue, with the ultimate goal of getting hyperlink auditing disabled by default in Safari.” but I kind of hope that link tracking is enabled everywhere by default, so that marketing companies are more likely to use it, so that when I turn it off I’ll be more protected.

              1. 4

                The author says “I hope to raise awareness about this issue, with the ultimate goal of getting hyperlink auditing disabled by default in Safari.” but I kind of hope that link tracking is enabled everywhere by default, so that marketing companies are more likely to use it, so that when I turn it off I’ll be more protected.

                Honestly this is really selfish. What about the millions of users who are oblivious to web standards? You’re saying you’re okay with them being tracked in this one way just so you won’t be?

                1. 4

                  If I could choose between “everybody gets privacy” or “nerds get privacy”, I’d pick “everybody” every time, for sure. But as far as I can tell, the choice here is between “nerds get privacy” (if HTML5 link tracking is adopted) or “nobody gets privacy” (the status quo, sites continue to rewrite external links to go through a redirector).

                  Given those options, I think it’s better that privacy be at least possible, rather than impossible.

                  If there is some third alternative where site owners voluntarily stop trying to track exit links, I’d love to hear about it!

              2. 7

                I’m glad I’ve switched to firefox.

                1. 5

                  The end of the article has a note indicating that this apparently may be an upcoming change for chrome too.

                  1. 4

                    so an interesting point here (that I haven’t seen mentioned yet) - do the URLs in the ping attribute also have to go via whatever content blockers are configured for the browser? I would assume yes, but would need to confirm I guess.

                    1. 7

                      So I just tried this. I setup a plain html page with two links (to an existing but empty file), each with a ‘ping’ attribute. One goes to a non-existent path in the same directory, another goes to ‘https://facebook.com/ping.foo’.

                      I have a rule in my Safari content blocker (I use 1Blocker) that blocks any ‘3rd party’ loads to facebook.com/net (and fbcdn or whatever the domain is).

                      I used Proxie and tried clicking each link - sure enough no request to Facebook. I then hit the pause button in 1Blocker (which reloads the page). Clicked each link again - and what do you know, a request to facebook.

                      So - this is honestly a storm in a teacup about fucking nothing. They can already do this via JS anyway, and if you’re at all privacy conscious you’re surely blocking the domains that would be ‘pinged’ anyway.

                    2. 4

                      Not sure I fully understand the privacy implications.

                      Right now I can do:

                      <a href="trackingurl?redirect=target">link</a>
                      

                      but that looks ugly, and it creates security risks for the website when done wrong (and it often is), so I do something like:

                      <a onclick="navigator.sendBeacon('trackingurl')" href="target">link</a>
                      

                      or even:

                      <style>
                      a:active{background-image:url(trackingurl);};
                      </style>
                      

                      why wouldn’t we treat ping at least the same way?

                      <a ping="trackingurl" href="target">link</a>
                      

                      Seems like if JavaScript is disabled, maybe you have a case to ignore the “ping” attribute (Again: I don’t fully understand the privacy implications, so I’m not trying to bury the lede here) and disable background image changing on a:active the same way we lost it for :visited, but if JavaScript is enabled, why wouldn’t anyone want to support ping?

                      I’ve tried to read a dig in the Mozilla docs around this subject, and most of the comments point nebulously to privacy concerns (which aren’t further explained) or seem to agree that “it’s a wash” as it seems to me.

                      What am I missing?

                      1. 2

                        I think the calculus is something like:

                        • Site owners do not automatically have the right to know what a user does with the information (including links) the site gives them
                        • The Web platform is now sophisticated enough that site owners that really, really want to know which links are clicked can figure it out, but it takes a bit of effort, there are often security implications, and it can degrade the user experience (messing up the URL in the status bar, pages slower to load)
                        • Although there are reasonable and quite legitimate reasons for sites to collect this information, there are also sketchy and underhanded reasons. It’s not so dangerous that it must be hard-limited, like :visited is, but people are comfortable with the idea that something a little bit sketchy for users is a little bit difficult to implement.
                        • On the other hand, providing built-in, first-class support for link tracking in HTML might send the message that this is 100% legitimate and acceptable behaviour in every possible situation.
                        1. 1

                          The main concept is: don’t force tracking down your user’s throat.

                        2. 3

                          Quite ironic given that Safari is sold as a privacy-preserving browser

                          https://webkit.org/blog/8718/new-webkit-features-in-safari-12-1/ -> https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

                          Although to be fair, Apple’s approach is to make decisions for all of their users. If you want a browser with configurability, Firefox is the Linux of the browsers.

                          1. 4

                            I use Safari with exclusively private windows full-time, for all browsing on iOS and macOS, because it’s the only browser whose private/incognito mode isolates tabs from each other. Unless I’ve missed something (very possible, but I’ve tested quite a lot), literally every window and tab is effectively a new client. I’d love to see that get tracked from session to by a site. Of course if they’re deliberately weakening tracking prevention in standard windows in the software itself that’s a bad sign, but for me, using Safari with a decent ad-blocker (I use Better) and always using private windows does mean I have to log in to things and say “yes cookies whatever” all the damn time, but it makes for a pretty clean and seemingly non-tracked web experience. Way more so than Chrome or Firefox.

                            1. 1

                              It’s unfortunate that Firefox is so slow on macOS that it takes the fun out of the web-browsing experience because it has a lot of awesome features like containers.

                            2. 1

                              This is the kind of shit IE was pulling when it was the dominant browser back in the days. And the frustration gave birth to Firefox and Chrome. I see the next browser war is already here. Firefox is at it again, but I think there will be a new contender. Brave, maybe. Or something else, maybe.

                              1. 1

                                Brave is based on chromium, and therefore subject to the whims of google, so I wouldn’t consider them to be a serious competitor in any ‘browser wars’.

                              2. 1

                                I was baffled at first but it makes sense. This is the sort of thing more appropriate for an extension. No reason to have it as a browser feature. And as mentioned by many, JS is a lot more powerful and convenient for tracking. I doubt that anyone is using this in the real world.

                                1. 1

                                  This is good. Really. It has no impact on privacy, and has a potential to improve performance.

                                  This is the lesser evil version of tracking that already happens. Sites that want to track clicks, track them via JavaScript and/or HTTP redirects (e.g. Google Search uses both, Twitter has t.co). Your clicks get tracked anyway, but they get messy JS and extra synchronous requests. OTOH ping makes asynchronous, low-priority requests.

                                  The problem with ping being optional is that nobody wants to use it. All the other tracking methods have better browser support and better reliability. So the only way to make sites use ping is to make it as reliable as other methods.

                                  Another problem with having an option is that it helps the worst of the worst trackers that use fingerprinting. They can detect that you’ve switched that option and it makes you stand out from other visitors. If it’s always on, they have one bit less in the fingerprint.

                                  1. 1

                                    Your clicks get tracked anyway, but they get messy JS and extra synchronous requests. OTOH ping makes asynchronous, low-priority requests.

                                    Not true. XMLHttpRequest does support async. And so is sendBeacon

                                    1. 1

                                      XHR is tied to the lifetime of the document it’s running on. It will be aborted, unless the page delays the navigation.

                                      sendBeacon is the ping on steroids.