You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was raised as w3c/html#1456, after the ping attribute was put back into W3C HTML (based on a recommendation from @adrianba in w3c/html#369).
When this was discussed in the past, I believe privacy concerns were specifically cited as a reason not to include this in the updated HTML5 spec, but
it seems to have gone ahead on this draft, based on increased implementation experience.
When it was discussed with the Privacy Interest Group in April 2017, a specific comment was noted:
<"Note that if we have a requirement that user agents clarify to the user that the link will ping other sites, we need to test whether that happens in real implementations."<
That concern stands.
Here is the relevant text from the spec (present in both WHATWG HTML and HTML 5.3 WD):
<"user agents should make it clear to the user that following the hyperlink will also cause secondary requests to be sent in the background."<
Has anyone tested the real implementations to verify that user agents clarify to the user that the link will also cause secondary requests to be sent in
the background? In my quick checks on current versions of Chrome and Safari on Mac OS clicking on links from a google.com search results page, I couldn't determine that secondary requests were being sent in the background short of opening the network inspector and observing
HTTP POST requests. I trust that we don't believe that is "clear to the user". (The spec includes an example suggesting use of a tooltip; I'm not sure
that's very clear either, but I haven't seen that in existing implementations anyway.) Do others have tests/screenshots/etc. documenting implementations
that fulfill this requirement?
Indeed, the question of implementing the clarity requirement was raised in 2007, with the suggestion that if sufficient UI wasn't being implemented within a year, then the feature should be revisited:
If there haven't been compliant implementations developed in the past 10 or 11 years, then I question whether there is sufficient implementation experience
or whether implementers believe that feasible UI is possible to meet that requirement.
I believe there are good motivations for the ping attribute feature in a way that could help user privacy. However, I think we need to be cautious about
a feature where the privacy UI hasn't been developed for this long. Indeed, this might be a step backward in transparency for end users, who in some cases
now can no longer use the status bar to observe that they're being redirected through a tracking link, and might conclude that tracking isn't happening,
that they're navigating to a site by clicking a link without any background communications. In neither browser I tested could I find a setting to disable
sending these background requests, as was proposed as an advantage of the feature.
If implementers believe that the clarity requirement is actually unnecessary and that it's still better for user privacy, that would be a separate question
to discuss. That approach might better match the reality of implementations, but I'm not sure what the privacy advantage is if users have neither awareness
nor control of background tracking requests.
The text was updated successfully, but these errors were encountered:
So the reduction in privacy is only there if you have scripting disabled and user agents would not disable the ping attribute under such circumstances. Perhaps we should require that if scripting is disabled the ping attribute gets disabled too.
I would not expect UAs to implement the UI currently required as it would be rather misleading. Users might come to expect it to be accurate and be led astray due to all the sites that use scripting to do equivalent things without UI. (This is an argument to change the standard, to be clear.)
In addition to what @annevk describes, it's worth noting several more issues:
Today, there are even more ways to cause something like the ping attribute behaviour to occur without UI.
Disabling scripting is also increasingly rare (I don't think we provide a built-in way to do this in Edge).
Users shouldn't rely on the current UI indicating where a link will take them anyway (commonly a tooltip on hover) because sites frequently try to spoof this.
The conclusion I reach is that the ping attribute results in no meaningful reduction in privacy but does allow a UA to optimise for the case when a ping is explicitly indicated in markup. This potentially improves navigation performance for a user.
This was raised as w3c/html#1456, after the ping attribute was put back into W3C HTML (based on a recommendation from @adrianba in w3c/html#369).
When this was discussed in the past, I believe privacy concerns were specifically cited as a reason not to include this in the updated HTML5 spec, but
it seems to have gone ahead on this draft, based on increased implementation experience.
When it was discussed with the Privacy Interest Group in April 2017, a specific comment was noted:
<"Note that if we have a requirement that user agents clarify to the user that the link will ping other sites, we need to test whether that happens in real implementations."<
That concern stands.
Here is the relevant text from the spec (present in both WHATWG HTML and HTML 5.3 WD):
<"user agents should make it clear to the user that following the hyperlink will also cause secondary requests to be sent in the background."<
Has anyone tested the real implementations to verify that user agents clarify to the user that the link will also cause secondary requests to be sent in
the background? In my quick checks on current versions of Chrome and Safari on Mac OS clicking on links from a google.com search results page, I couldn't determine that secondary requests were being sent in the background short of opening the network inspector and observing
HTTP POST requests. I trust that we don't believe that is "clear to the user". (The spec includes an example suggesting use of a tooltip; I'm not sure
that's very clear either, but I haven't seen that in existing implementations anyway.) Do others have tests/screenshots/etc. documenting implementations
that fulfill this requirement?
Indeed, the question of implementing the clarity requirement was raised in 2007, with the suggestion that if sufficient UI wasn't being implemented within a year, then the feature should be revisited:
If there haven't been compliant implementations developed in the past 10 or 11 years, then I question whether there is sufficient implementation experience
or whether implementers believe that feasible UI is possible to meet that requirement.
I believe there are good motivations for the ping attribute feature in a way that could help user privacy. However, I think we need to be cautious about
a feature where the privacy UI hasn't been developed for this long. Indeed, this might be a step backward in transparency for end users, who in some cases
now can no longer use the status bar to observe that they're being redirected through a tracking link, and might conclude that tracking isn't happening,
that they're navigating to a site by clicking a link without any background communications. In neither browser I tested could I find a setting to disable
sending these background requests, as was proposed as an advantage of the feature.
If implementers believe that the clarity requirement is actually unnecessary and that it's still better for user privacy, that would be a separate question
to discuss. That approach might better match the reality of implementations, but I'm not sure what the privacy advantage is if users have neither awareness
nor control of background tracking requests.
The text was updated successfully, but these errors were encountered: