From the discussion in #3718 it sounds like it should be dropped.

Scripting being disabled is a state that web content can opt into (e.g. with sandbox), even if users don't disable JS.

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13806

Currently Chrome and Safari don't show UI and don't disable ping when scripting is disabled.

Without JS, the only alternative mechanism for link auditing, AFAIK, is redirects.

Maybe the spec can say that UAs may disable ping or show some UI when scripting is disabled.

I think dropping the privacy requirements just because they haven't been implemented isn't a good approach. Instead, we should add tests and address compliance by implementers.

Yes, there are other ways to accomplish link-tracking, like redirects or blocking unload, but those alternatives have expenses and may be visible to the user, whereas ping is typically done completely in the background, at a privacy and resources cost to the user, without any possible visibility.

I agree that users might be confused by bad UI implementations. On the other hand, I believe virtually all users are mislead under the status quo, where link tracking is done ubiquitously with no transparency or control.

I think we should update the specification to match reality, and if someone wants to propose changes to browsers, it can go through our normal working mode.

I think dropping the privacy requirements just because they haven't been implemented isn't a good approach

"they haven't been implemented" wasn't in my list of reasons why I think a UI is a bad idea.

The changes have been proposed to some browsers:
https://issues.chromium.org/issues/41452280
https://bugzilla.mozilla.org/show_bug.cgi?id=401352
and proposed for testing:
web-platform-tests/wpt#42690

The reality is that some browsers implement this without any privacy protections normatively recommended in the spec and some browsers don't implement it because of the privacy harm. I agree we should bring implementations and spec into agreement, I just don't agree that the way we should do that is to remove the privacy requirements to match the implementations that don't have any of the privacy features.

@npdoty you can also use sendBeacon(), an <img>, the new fetchLater(), or service workers, and not delay unload. It's not clear to me there is privacy harm here. I can kinda see it when scripting is disabled, but even there it's not immediately clear that forcing redirects or some such is better. It's not like these tracking links can do much in browsers with a modern cookie story.

The privacy risks of silent background requests are not solely limited to this one feature. Nonetheless, they do exist, and we should address them in each case.

The reality is that some browsers implement this without any privacy protections

This is incorrect. See https://webkit.org/blog/8821/link-click-analytics-and-privacy/

and some browsers don't implement it because of the privacy harm.

If you're referring to Firefox, then this is also incorrect. We believe there is no particular privacy harm, see mozilla/standards-positions#1212

The reality is that some browsers implement this without any privacy protections

This is incorrect. See https://webkit.org/blog/8821/link-click-analytics-and-privacy/

Apologies, I was writing quickly and meant to refer to the privacy protections normatively required by the specification, including UI and user control. There are other types of mitigations not normatively described in the spec (like I believe Brave treats them differently based on whether it's cross origin, or filters requests based on lists of known trackers, and WebKit limits cookies and headers when it's cross origin).

and some browsers don't implement it because of the privacy harm.

If you're referring to Firefox, then this is also incorrect. We believe there is no particular privacy harm, see mozilla/standards-positions#1212

Having followed these bugs for many years, I believe it's still correct to conclude that it hasn't already been implemented by default in Firefox because of privacy and security concerns. But different Firefox engineers have had different opinions and you can certainly change your minds. (As a Firefox user myself I personally hope that you'll still fix the associated bugs as part of the ongoing implementation process, but hey, I also hoped that Chrome would fix the associated bugs.)

I'm sure many are tired of repeating this debate, but just to quickly answer the substantive points on why transparency is a privacy benefit here, I've tried to be brief inline:

Chrome and Safari support ping but don't show any UI. I think it's probably a bad idea to do so, for a few reasons:

• Other hyperlink auditing mechanisms exist that don't show UI. If site owners are bothered by browsers showing UI, it's a disincentive to using ping.

If site owners are comfortable tracking their users' clicks, then I don't see why they would be bothered by transparency about that to the end user.

However, if they are bothered and choose not to use ping, then they'll have to pay the development, performance and UX costs of not having dedicated browser infrastructure to send their extra tracking information. Sites that aren't tracking user click activity can be distinguished from sites that are, and sites that aren't tracking users also see a performance benefit. Providing the feature completely silently provides a performance benefit to the sites that want to do this kind of click tracking without any user awareness.

• The new UI might be abused, e.g. to trick users that a malicious link is trustworthy.

I'm not sure how this abuse would happen. Many links would have click-tracking, and the UI shouldn't indicate that there's something more trustworthy about clicks that are tracked.

• It might confuse users.

Yes, it's possible that some (at first, many) users might not understand UI. My expectation is that virtually no users inspect the HTML or DOM to check whether a background ping request is going to happen before clicking a link, and so the transparency to users is likely to be improved (over no transparency -- a very low bar).

There actually is some transparency when redirects are used instead: users who make use of tooltips or long presses can see where a URL will take them before they click on it, or the URL bar will indicate that the redirect is happening as it happens. Switching to ping attribute for browsers that support it by default decreases (admittedly limited) transparency for those users.

• It's possible to circumvent, by adding the ping attribute right before navigating.

Yes, it's possible to circumvent, by adding the attribute right before navigating, or by using an alternative mechanism (redirects, fetches, or other background mechanisms, although again, those mechanisms sometimes do provide transparency, or have different costs). We could recommend or update specifications to also provide transparency for background requests that are made in other ways.

I think this should be downgraded to a "may", or dropped completely.

As previously mentioned #3718 w3c/html#1456 w3c/html#369, I think we should retain the transparency requirement, if the feature is retained, and try out actually implementing it.

If site owners are comfortable tracking their users' clicks, then I don't see why they would be bothered by transparency about that to the end user.

Sites that use redirects are clearly not bothered. Whether they would be bothered by a new ping-specific UI might depend on the chosen UI.

However, if they are bothered and choose not to use ping, then they'll have to pay the development, performance and UX costs of not having dedicated browser infrastructure to send their extra tracking information.

Using sendBeacon() is basically the same.

Sites that aren't tracking user click activity can be distinguished from sites that are, and sites that aren't tracking users also see a performance benefit.

I don't follow.

Providing the feature completely silently provides a performance benefit to the sites that want to do this kind of click tracking without any user awareness.

It's a performance benefit over redirects or sync XHR or performing the navigation after a timeout, yes. It's not a performance benefit over sendBeacon().

I'm not sure how this abuse would happen. Many links would have click-tracking, and the UI shouldn't indicate that there's something more trustworthy about clicks that are tracked.

If the UI is that the status bar shows both the href URL and the ping hostname(s), then you could put in a trustworthy hostname in ping and hope that users think it has something to do with the target URL.

Yes, it's possible that some (at first, many) users might not understand UI. My expectation is that virtually no users inspect the HTML or DOM to check whether a background ping request is going to happen before clicking a link, and so the transparency to users is likely to be improved (over no transparency -- a very low bar).

There actually is some transparency when redirects are used instead: users who make use of tooltips or long presses can see where a URL will take them before they click on it, or the URL bar will indicate that the redirect is happening as it happens. Switching to ping attribute for browsers that support it by default decreases (admittedly limited) transparency for those users.

Indeed.

Yes, it's possible to circumvent, by adding the attribute right before navigating, or by using an alternative mechanism (redirects, fetches, or other background mechanisms, although again, those mechanisms sometimes do provide transparency, or have different costs). We could recommend or update specifications to also provide transparency for background requests that are made in other ways.

Websites do background requests a lot for various reasons. I think it would be noise for users to show UI indicating that background requests are happening.

As previously mentioned #3718 w3c/html#1456 w3c/html#369, I think we should retain the transparency requirement, if the feature is retained, and try out actually implementing it.

With #11329 the spec would still allow showing UI, if someone is interested in trying it.

Actually I think there's a more important point:

The privacy concern is only a concern if cross-site tracking is possible. With modern tracking mitigations browsers have for cross-origin fetches in general, I believe this is a solved problem. We shouldn't give users the false impression that ping is something to be concerned about, while img and other features are fine.

Yes, it's possible that some (at first, many) users might not understand UI. My expectation is that virtually no users inspect the HTML or DOM to check whether a background ping request is going to happen before clicking a link, and so the transparency to users is likely to be improved (over no transparency -- a very low bar).
There actually is some transparency when redirects are used instead: users who make use of tooltips or long presses can see where a URL will take them before they click on it, or the URL bar will indicate that the redirect is happening as it happens. Switching to ping attribute for browsers that support it by default decreases (admittedly limited) transparency for those users.

Indeed.

It sounds like you agree that recommending this feature be implemented without this requirement meaningfully decreases the little transparency that users have about click-tracking. That harms user privacy, to the benefit of sites that want to increase user tracking.

Yes, it's possible to circumvent, by adding the attribute right before navigating, or by using an alternative mechanism (redirects, fetches, or other background mechanisms, although again, those mechanisms sometimes do provide transparency, or have different costs). We could recommend or update specifications to also provide transparency for background requests that are made in other ways.

Websites do background requests a lot for various reasons. I think it would be noise for users to show UI indicating that background requests are happening.

As previously mentioned #3718 w3c/html#1456 w3c/html#369, I think we should retain the transparency requirement, if the feature is retained, and try out actually implementing it.

With #11329 the spec would still allow showing UI, if someone is interested in trying it.

Some browsers have bugs they are tracking for implementing this spec requirement. While it's gracious that you're not proposing to prohibit browsers from implementing transparency UI altogether, it seems unlikely that this will help either implementation progress or interoperability. If a browser implements UI after the requirement has specifically been removed, it will increase the surprise to site owners and the pressure against that browser to not expose that tracking to users.

This feature was originally justified as a privacy benefit because of the control and transparency requirements. Now that it's been implemented in ways that help sites that track their users, it seems you want to remove the pretense of privacy benefits, but continue to retain the tracking functionality. Keeping the feature with the transparency and control requirements is the compromise that the community has come to multiple times in the past.

The privacy concern is only a concern if cross-site tracking is possible. With modern tracking mitigations browsers have for cross-origin fetches in general, I believe this is a solved problem. We shouldn't give users the false impression that ping is something to be concerned about, while img and other features are fine.

While I find your conclusion that cross-site tracking is solved to be over-optimistic, users also have privacy concerns other than cross-site tracking. (This actually is another form of cross-site tracking, the ability to know where on another site the user is navigating away to, but anyway.) That there are some mechanisms where transparency isn't yet accomplished isn't a good reason not to provide users transparency and control where we can.