Chrome, Safari, and Edge to Prevent Disabling of Click Tracking Privacy Risk | Hacker News Reader

Chrome, Safari, and Edge to Prevent Disabling of Click Tracking Privacy Risk

bleepingcomputer.com

222 pointsAthas74 comments

> Firefox 66, Firefox Beta 67, and Firefox Nightly 68 disable Hyperlink auditing by default

In the same vein, with Chromium-based browsers, web sites have priority in deciding whether a connection can be made for pre-fetching purpose, even when the user explicitly disable pre-fetching in browser settings.[1]

Firefox properly respects the disabling of pre-fetching.[2]

* * *

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=785125

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=785125...

Similar to some others here, I always thought that most sites used JavaScript click handlers that send the host which links are clicked (where the target is visited directly and not through a redirect link).

Firefox with extensions is the solution we should evangelize as some browsers become hostile to user privacy or just change things and pretend it’s not a big deal (cough Chrome cough).

Is it really a privacy risk if there is no escalation? Exactly the same thing can be done, guaranteed, if JavaScript is enable. The UX is just objectively worse without this feature due to lag leaving the page.

So why make the UX worse for a callback function when the site can do it no matter what?

The only argument I can think of is that if the callback is slower, then sites may decide they don’t want the data because it slows down a user leaving their site by maybe a few hundred milliseconds.

Is that really the mentality of a site which is going to track you without permission? And if they have your permission, we should provide the JavaScript tools to make it fast.

A couple of reasons, in order of what I believe to be the strongest to most controversial:

First, hyperlink auditing works without Javascript enabled. Even if most users will have Javascript enabled, some won't. This moves auditing from "a thing that you could disable if you were willing to block JS" to "a thing that's always on no matter what."

Secondly, to quote Chrome's dev team, you want developers to fall into a "pit of success."

The ping link is so easy to use that it's something a developer can add without thinking. This encourages its inclusion in copy-paste code/tutorials. You're right that a site that wants to make use of something like this is probably not thrown off just because they need to add a click handler. But for someone who's newer to web development, it might make a difference.

Developer friction can add up -- if tracking is universally more complicated than writing normal code, more developers will do the "right" thing purely by virtue of laziness.

Finally, and most controversially, there is a line of thought that says that end user experience ought to be better on sites that are doing the right thing. You're right that a site that wants to track users is not going to be deterred by a hundred millisecond delay. But users might notice.

If performance on "good" and "bad" sites are the same, the theory is that companies that respect users are at a strict disadvantage to companies that take advantage of them. Over time, users will migrate to the services that don't respect their privacy because of the extra resources being poured into those sites.

Again, not everyone agrees with this -- but the idea is that if you're building an ethical site, you should have at least a few competitive advantages build in that might influence users to stick with you -- for instance, a snappier site.

If you're willing to block JS, you can also trivially run an extension that strips all `ping` attributes from the page. And without JS you don't have to worry about the attributes being added back after the stripping.

> Developer friction can add up -- if tracking is universally more complicated than writing normal code, more developers will do the "right" thing purely by virtue of laziness.

Developers don't add ping attributes because it's easy. They add them because they're required to for analytics reasons. They will do this no matter what, so what we want to optimize for here is the user experience.

You say that users will naturally migrate to sites that don't have the bad UX inherent in javascript-based or redirect-based link tracking, but experience shows that's not true. Some of the most popular sites on the planet do this and users haven't been driven away.

I'm not here to argue which of these reasons are correct; I'm only here to explain some of the arguments that exist. That being said,

> If you're willing to block JS, you can also trivially run an extension that strips all `ping` attributes.

Sure. Ublock Origin already does this today at the request level, so you don't even need to worry about pages re-adding the attributes. But we could just as easily use this argument to get rid of every privacy-protecting decision in the browser. Why should Firefox care about Canvas fingerprinting if an extension can block it instead?

For better or worse (some would argue worse) browsers have been slowly pulling privacy/tracking improvements from extensions into their core. I don't think they're close enough to a full solution that anyone should skip extensions like Ublock Origin or UMatrix, but I don't fault them for trying.

> Developers don't add ping attributes because it's easy.

Like you correctly mentioned above, ping attributes are trivial to block. If a developer is being forced to implement tracking, even with ping attributes available more broadly, they're still gonna use an additional method that gets through the most widely used ad blockers on the market -- and that means Javascript click events. Force-enabling the ping attribute will not change a single thing about that developer's approach.

The only developers who are going to be influenced by this change are hobbyists and engineers for small-time businesses that don't already have a massive analytics concern. I think it's reasonable to focus on its impact to them.

> You say that users will naturally migrate to sites that don't have the bad UX... but experience shows that's not true.

Don't be too pessimistic, loading speed is one of the primary reasons why the average person installs an adblocker to begin with. It is very hard to get people to care about privacy, but lots of people are still installing ad blockers purely because they improve the UX experience. That's a success story.

Of course, 100 milliseconds on its own is not going to make someone abandon a site. But when you make a lot of tiny compromises, they add up to big ones. And as of 2018, Google is still publishing statistics that say a 3 second load time will lose you 53% of your potential visitors.[0]

I know it seems like users don't care about this, but there's a nontrivial amount of data that suggests they do.

[0]: https://www.thinkwithgoogle.com/marketing-resources/data-mea...

> Sure. Ublock Origin already does this today at the request level, so you don't even need to worry about pages re-adding the attributes. But we could just as easily use this argument to get rid of every privacy-protecting decision in the browser. Why should Firefox care about Canvas fingerprinting if an extension can block it instead?

I view browsers supporting ping as absolutely a privacy-protecting measure. As long as the browser can be relied-upon to support it, developers will use it instead of more invasive techniques, which means not only is it a better UX for the users, but the amount of information collected by each ping is a known quantity, and browsers can also do things like defer executing ping requests for battery reasons or to reduce the amount of timing information given to the recipient.

I would have no objection to browsers disabling pings if JavaScript is also disabled at the browser level, but that's a fairly niche edge case and I don't have any strong opinions there (and of course even with JS disabled a site could still serve up a static page where all outbound links go through a redirect domain anyway; supporting pings by default even with JS disabled encourages developers to just always use it, and then the people who really care can run an extension to disable it).

> Like you correctly mentioned above, ping attributes are trivial to block. If a developer is being forced to implement tracking, even with ping attributes available more broadly, they're still gonna use an additional method that gets through the most widely used ad blockers on the market -- and that means Javascript click events. Force-enabling the ping attribute will not change a single thing about that developer's approach.

The more privacy-protecting measures browsers have by default, the less aggressive people will be about using third-party extensions to do the same thing. And given what I said above, it might be a good idea fo adblockers to allow pings by default and only disable them upon request. As you said, if ping isn't reliable developers will use something else, so the goal here is make ping reliable. If it's reliable, people will use it, and using ping is far better than the other techniques available.

> Don't be too pessimistic, loading speed is one of the primary reasons why the average person installs an adblocker to begin with. It is very hard to get people to care about privacy, but lots of people are still installing ad blockers purely because they improve the UX experience. That's a success story.

We're talking about delays clicking on outbound links though. If a big site adds 100ms to the loading time of outbound links, most users are going to blame the external site for that because they don't understand that the delay is being added before the request is made. This means that big sites can add outbound link tracking with very little penalty, and in fact the additional delay, if anything, is going to encourage users to stay on the site instead of visiting external sites.

:reading the title: Why doesn’t they mention the stance of Firefox on this?

> 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.

Oh, that's why.

<a ping> was disabled in Firefox back in 2008 [1]. The rationale was that navigator.sendBeacon() (which wasn't enabled until 2014 [2]) would be a more general solution, not for privacy reasons. Without <a ping> or navigator.sendBeacon(), websites will still use redirects or other JavaScript ping scripts. With <a ping> or navigator.sendBeacon(), the browser can delay or deprioritize those ping requests (to reduce performance impact on page loading) or allow extensions to block them.

But if popular websites are using <a ping> for other browsers, then perhaps Firefox should re-enable support to avoid the performance overhead of link redirects.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=415168

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=990220

This further solidifies my choice to remain with Firefox.

Indeed. Until Firefox pulls a dick move, that is. And I wonder what then...

Yes, Firefox is the good one here but it seems we're slowly being squeezed on all sides as browsers gradually become dumbed-down and noncustomisable "consumption portals".

Firefox started gaining over IE6 when techies started installing it on their friends PCs. It was faster and it got traction instantaneously despite all those made for IE web sites.

Selling privacy is not as easy as to sell speed but if we start installing Firefox again it can gain back some of its former share.

I guess I’ll have to inject some JS to delete ping attributes while browsing in Safari.

This move is very counter to Apple’s privacy stance.

That could be countered by other JS on the page.

Indeed, but I just learned about the DOM mutation API[1], that can be used here. This also makes sense when additional content is loaded later via AJAX (was achieving that with setInterval).

1: https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

I wonder if whoever sets these attributes has also set appropriate DOM mutation listeners therefore creating and endless tug-of-war.

No one cares enough to bother with the 0.0001% of people who would do this.

> This move is very counter to Apple’s privacy stance.

Apple are in a firm position unlike anyone in the industry to not suffer losses by taking a strong stance on privacy, and that's why its believable... but that doesn't make it true?

Can’t you just add click event listeners in JavaScript to do the same thing? Honestly I never knew the ping spec existed and thought that was what people were using to accomplish this.

I thought what people did to accomplish this was to make links that go to the tracking page, and have the tracking page redirect to the real destination. That seems to be what happens when you click on a google result.

uBlock origin blocks some of these and gives you the target link with the option to go directly to it. But it misses a lot of them.

I see a POST + GET when clicking on a Google SERP URL. [0]

I saw another variation of this the other day [1] where an advertisement would spoof the href so that the "hover preview" was misleading, and an onMouseOver event handler would swap the href before you click it.

[0] https://pasteboard.co/I93MWvH.png

[1] https://pasteboard.co/I93NKsG.png

Yes, unless JS is disabled, now even disabling JS isn't enough. This move sucks hard. Please, everyone, move to Firefox now, even if it's only for personal browsing (use what you must for work), and write a strongly worded message to the maker of the browser you are leaving.

If you have JavaScript disabled they can still redirect you through a portal page to capture your visit and then send you to the actual link.

not if your computer's off tho

But that means they have to send links to the tracking page, that will show the tracking page on hover as the link destination etc.

That is much more noticeable than sending a link that shows www.google.com but instead goes somewhere else on click.

That's transparent. They're claiming this is more transparent when it's not transparent at all. The browser is supposed to be a user agent, not a corporate lackey.

You may also need to disable CSS.

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

I just tested this in Firefox. If the request isn't cached, it just immediately times out as soon as the page load begins. I haven't tested to see if it still gets delivered to the server. If the browser is sending out the request and just not waiting for a response, then it would still be usable.

It's still worth noting though that in either case this is a way more complicated attack than adding a ping attribute.

With the ping attribute, you don't have to worry about browser caching because you're using a post request. If you want to get rid of caching with the CSS method, you either need to switch to serverside rendering (which blocks you from using static hosts like Github pages) or have Javascript enabled so you can generate the CSS on the fly.

You also need to worry about false positives and false negatives -- a user clicking on a link and then dragging off of it without visiting will still trigger your tracking code, and a user navigating via keyboard controls won't trigger this at all.

None of that is to say that CSS tracking isn't something we should worry about (for instance, I really wish Firefox disabled `visited` styling by default), but I don't think this is an effective argument for saying that we should just give up and make tracking even easier (not that parent is claiming this).

And in any case, it's also not like it would be exactly hard for a future version of Firefox to add an option that disabled `active` styling specifically for link tags. Tracking protection is a game of cat and mouse. We patch things as we go.

> I haven't tested to see if it still gets delivered to the server.

I have, and it does.

> If you want to get rid of caching with the CSS method, you either need to switch to serverside rendering (which blocks you from using static hosts like Github pages) or have Javascript enabled so you can generate the CSS on the fly.

Or serve Cache-Control: no-cache?

Correct, this is a good catch.

If you're serving your background image from a server that lets you set headers (which you would want to since it's a tracking beacon) then using headers makes this a lot easier.

Who thought this feature would be a good idea seriously? It will be abused to no-end by trackers and script kiddies.

> It will be abused to no-end by trackers and script kiddies.

It is being …. This is not a new practice; the only thing new about it is that you can no longer disable it. (Even before, on Safari at least, I'm pretty sure it was opt out rather than opt in.)

How is it abusing the feature to use it exactly as intended? The standard is literally called "hyperlink auditing." Tracking clicks is the entire point.

>Who thought this feature would be a good idea seriously?

every single ad tech bro

So how is the long-term outlook for Firefox? I believe that the Yahoo deal is (or already has) set to expire, so how will the browser keep afloat financially? I fear Google boxing out Firefox into a small corner of the market somehow.

Despite the shrinking userbase Firefox is still quite a decently sized market.

With both Bing and Google still existing I don’t see why Mozilla wouldn’t continue being able to negotiate a good sized contract from one or the other for default search placements.

Am I reading this wrong or are the browser vendors making it seem like this is a good feature for privacy?

Without knowing the specifics, I think it's one instance where any variance from the default, when intentionally set by an user, is an additional signal for fingerprinting.

(It's becoming a nice excuse to clamp down on configurability, without considering if the APIs really should be available to authors.)

The argument is that it's privacy neutral since this kind of tracking can already happen with JS or no JS with redirects both of which are widely deployed already.

* There's now a spec/standard for the data exchange.

* Users get faster websites, can see the actual destination URL on hover, and maybe a slight security improvement in the event that the server component performing the tracking redirects is compromised.

* It's easier to find the ping attributes on links than untangle all the JS on a page.

* For extension developers this actually increases privacy (assuming it's adopted en mass) because now you can just remove all the ping attributes on links rather than unbind click handlers which might end up breaking the page.

End users can at least disable JS to solve JS-based privacy concerns. So the act of removing methods to disable this is at least a tiny bit on the anti-privacy side of things.

There still needs to be a way for people to disable it.

I endorse this: if devs use this my rewrite proxy that manages all my port 80 and 443 traffic can filter them out. If it's a weird blob of javascript I can't reliably do this.

What is the intended use case for this feature?

It's for sites like Google who want to know which search result you click on. Previously, this involved adding an on click handler to the link. The JavaScript in the handler then delayed the navigation to the next page, as unloading the page would stop the JS&the ping request would not get sent.

With this feature, the browser could immediately navigate to the link target and simultaneously make the ping request in the background.

that's already solved with navigator.sendBeacon - no need to stop unloading the page to make sure the ping gets through

WhatWG says it exists because it's more performant and transparent to end users than js or redirect based tracking.

It also says the end user can disable it. Guess that bit is being dropped?:

"The ping attribute is redundant with pre-existing technologies like HTTP redirects and JavaScript in allowing Web pages to track which off-site links are most popular or allowing advertisers to track click-through rates.

However, the ping attribute provides these advantages to the user over those alternatives:

It allows the user to see the final target URL unobscured. It allows the UA to inform the user about the out-of-band notifications. It allows the user to disable the notifications without losing the underlying link functionality. It allows the UA to optimize the use of available network bandwidth so that the target page loads faster.

Thus, while it is possible to track users without this feature, authors are encouraged to use the ping attribute so that the user agent can make the user experience more transparent."

https://html.spec.whatwg.org/multipage/links.html#hyperlink-...

It's also a space separated list, so you can ping multiple endpoints for one click.

Oh, so we're going back to the age of `/track_exit.php?base64_url=aHR0cHM6Ly9leGFtcGxlLm9yZy8=`?

I've just released an extension for blocking ping requests: https://github.com/dessant/ping-blocker

It will be available on the Chrome Web Store once the listing is reviewed: https://chrome.google.com/webstore/detail/jkpocifanmihboebfh...

The extension is not needed if you already use uBlock Origin, because the latter disables hyperlink auditing by default.

"A HTML standard called hyperlink auditing that allows sites to track link clicks is enabled by default on Safari, Chrome, Opera, and Microsoft Edge, but will soon have no way to disable it."

With "standards" like these, it does not sound like end users are involved in the "standards-making" process.

Maybe users need their own set of "standards" and browser authors can decide whether or not they want to implement them.

For example, one (implemented) standard might be the ability to disable automatic loading of images.

Another standard might be the option to disable CSS.

Another might be the ability to disable DNS prefetch.

And so on.

I was involved in W3C and WHATWG when ping was specified. Not sure if I meet your definition of "end user", but I'm a web developer, and I use websites, too…

This feature was specced, because sites use JS and HTTP redirects to do click tracking anyway. HTTP-based tracking (like t.co) can't even be bypassed.

With or without ping you get the exact same amount of tracking, but with ping at least the tracking can be made more transparent, lower priority and not delaying the navigation.

The problem is that as long as ping is less reliable than JS and HTTP, sites will continue to use JS and HTTP. You don't get less tracking, you only get less performant tracking.

Part of me wonders if the big push for tls everywhere was less about privacy and more about making it harder to filter out stuff like this. But regardless I can see some utilitarian aspects to this feature, it is all the Sneaky Pete stuff I object to. Why not be transparent and open about this feature being used? Because they know people object if they knew. It might not even be legal to use this in the EU.

No kidding. If you look at the vehement opposition against even "border" MITM proxies, it's not surprising to make such an assumption. They want to use the "security" argument to force users into consuming all the crap they don't want too (a form of "anti-user security".)

(Disclaimer: I use one, and it works very well at filtering stuff out before it even gets to the browser.)

If only the Firefox devtools were as good as Chrome’s.

I’ve switched to Firefox but somethings are blockers for me. Webpack hot reloading doesn’t work :(

Other than that, it’s a very solid browser. The only way someone’s gonna win against chrome is by keeping the user first.

Super sad to see Apple privacy double speak when Safari isn’t even walking the talk.

Pretty user-hostile. Time to install Firefox.

But see this: https://news.ycombinator.com/item?id=19597268

Still user-hostile, because it reduces user choice.

There should be some better control around this feature. For example you might feel ok about first party click tracking but not third party. Or you may just want to shut the feature off completely. You shouldn’t need a browser extension to do this for you.

I can agree with this. The option to disable or prevent cross-domain posts sounds like an entirely reasonable request.

There is all other problem in many webbrowser too and I wrote a document how to better.

Better is design (anything!) by UNIX philosophy, which is: you have enough ropes to hang yourself, and also a few more just in case.

What would be interesting is that we move away from domain blacklists (e.g. adblocks, /etc/hosts, pi hole, etc.) to domain/ips whitelists (like firewalls).

Can't you just make/use a browser plugin that removes all ping="" attributes from anchor tags?

I'm guessing an extension could search-and-replace the DOM pretty easily?

do any major websites use this ping= attribute?

Google search results. Great way to see which results are popular, and still allow users to copy links straight from the search results.

I don't see it when I inspect Google Search results. Instead I see a mouse down handler that rewrites the link's href to go through a google.com redirector. How did you spot the use of `ping`? Maybe they are running an A/B test.

i see it in chrome on google.com

Must have been an A/B test or something else specific to my setup. Saw it on google.co.uk in Chrome in the source.

Just turn off JavaScript when using a browser. It does break a lot of things, but you can whitelist domains where you feel the JavaScript provides additional value (e.g., your banking website may require JS for login).

It makes the first week or so of web browsing a little mechanical, having to manually whitelist. But it's worth it. The Web is so performant with JavaScript disabled.

The ping feature does not require JavaScript.

Not to mention that css is Turing Complete.

... and then you have Javascript at the edge (e.g. Cloud flare workers, etc).

The act of circumventing tracking can ironically make you more identifiable. How many users toggle Do Not Track, how many disable Javascript and share the same user agent and ip block...

Until there are strong privacy defaults used by the masses, one has to go through ridiculous lengths to get anything more than the illusion of privacy.

Reply on news.ycombinator.com