Privacy concern with ping attribute

[LJWatson]

Originally filed by email from Nick Doty, in response to a wide review request to the Privacy IG.

it looks like the ping attribute has re-appeared (from #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.

[chaals]

Waiting on @cynthia, but I will also explicitly request feedback from TAG on this issue.

[chaals]

ping attributes are at least simple to inspect. If a user wants to rely on an extension, it is far easier to make one based on that than alternative methods, so it seems better than not having it. However I think we should add text explaining this, and how users can actually make this work while noting that currently browser implementations don't do it.

[npdoty]

I couldn't totally parse the TAG minutes, though I see this was briefly discussed. Did they have specific input? Are they planning to discuss it again at an upcoming meeting?

It might be easier for an extension developer if the ping attribute is used, although it might be that extensions that want to provide this kind of functionality are already trying to detect link redirection. But that a requirement could potentially be implemented is different from having been implemented (or having been implemented interoperably in two independent implementations). Are browsers or prominent extension developers planning to implement transparency for the ping attribute?

For the typical end user, I think it's currently easier to inspect a URL (lots of browser UIs provide this) and see that it isn't going to the final destination than it is to view source and review other attributes on the anchor tag.

[torgo]

Discussed on f2f July 24 -will post a summary.

[chaals]

Thanks for the pointer.

A few thoughts:

As @plinss noted, sites do the tracking that this enables, so the attribute changes nothing in that regard. If the attribute were mostly reliable, site would be likely to live with it - if it mostly led to people disabling it, then it won't get used.

Many browsers have apparently decided not to help users do anything at all, although it seems trivial to write an extension that removes the attribute. The question is whether there is any data about whether sites pick that behaviur up and try to work around it, or accept it as part of offering users privacy and hoping that most of them don't take it...

On balance, I don't see an architectural problem, and much to like architecturally, about a solution that makes the tracking explicit and theoretically easy to opt out of, although like DNT if many users do then we can expect content producers to start designing around it if they want to stick with the "fre because you're the product" model so prevalent on the web.

So my current thinking is that we should have text clarifying this in the spec, but keep the attribute, which in any case is reasonably widely implemented.

[npdoty]

I'm unclear on how this merged pull request resolves the raised issue. Adding a recommendation that authors use the ping attribute doesn't seem to address the situation of the unimplemented (since 2007) requirement on user agents. Was that the conclusion from the TAG f2f discussion?

[chaals]

@npdoty the conclusion as I read it is that we are better off with people using ping than using random JS or HTTP redirecters.

However, we won't see much of that benefit unless there are tools that enable users to realise it. Whether browsers natively support privacy or not (and it seems they are not that interested), there are other mechanisms users have available (admittedly at higher cost).

I think the issue becomes one of privacy advocates being clearer in communicating the risks and publicising tools that are actually helpful.

[npdoty]

@chaals hmm, that is not the conclusion I see from reading over the TAG f2f notes. It sounds like there was interest there in more strongly noting the privacy issues, and potentially in making some recommendations for how browsers can reflect that, but I don't see a suggestion that the spec should be changed to more strongly recommend use of the ping attribute. It looks like there was an action item on Hadley to write something up; perhaps we could keep this issue open to track that until we hear back?

The just merged text doesn't read very consistently to me. It tells authors they should use the ping attribute to better support user privacy, and then immediately notes that in actual implementations there appears to be no benefit to user privacy.

I'm not clear on why the issue is one for educational activities by privacy advocates, but in any case the HTML spec doesn't seem to be the place to record that.

[npdoty]

@chaals @hadleybeeman I noted in July that I didn't think this issue was resolved, but I'm not sure if maybe it's being tracked elsewhere with the TAG action on writing something up. Can someone update me on the current status?

(I'm reminded of this with recent news that some UAs have removed the existing settings that were possible to disable ping actions, making them further afield from the spec and the alleged privacy benefits.)

[cynthia]

Re: TAG, I think we never followed up on doing a write-up of this after the F2F.

The one part I do remember is that while the privacy concerns are valid - this attribute doesn’t enable anything new, and does have the benefit of reducing compute overhead compared to doing this over JS.

There is a population which will be affected by this - people with scripting disabled. For the general case I recall the conclusion that putting this behind a permission or making it a opt-in would not be particularly effective, as it would simply make the offenders resort to scripting or redirect intercepts instead.

I don’t quite remember if we had spec text level feedback, will have to look at the minutes and get back to y’all on this.

[npdoty]

@cynthia

The one part I do remember is that while the privacy concerns are valid - this attribute doesn’t enable anything new, and does have the benefit of reducing compute overhead compared to doing this over JS.

For what it's worth, I think it does enable multiple new things: ping attributes can include multiple URLs which can all be contacted in parallel, in the background, without any indication in the URL bar (through redirects) or status bar (for example, hovering over a link when using a desktop browser) as well as providing performance benefits for sites that adopt it. Also, the stated requirements would be new in terms of providing user transparency and control, if they were implemented, which they have not been thus far.

Also, I don't think 'maybe not actually much worse for privacy than the current situation for most users' is consistent with recommending use of a feature as a benefit for user privacy.

I don’t quite remember if we had spec text level feedback, will have to look at the minutes and get back to y’all on this.

That would be great, thanks!