Re: ping attribute (was Re: Request Privacy review of HTML5.3)

On Mon, May 28, 2018 at 11:21 PM Nick Doty <npdoty@ischool.berkeley.edu>
wrote:

> On May 28, 2018, at 9:15 AM, Jochen Eisinger <eisinger@google.com> wrote:
>
> On Fri, May 25, 2018 at 12:27 AM Nick Doty <npdoty@ischool.berkeley.edu>
> wrote:
>
>> ---
>>
>> Via https://github.com/w3c/html/issues/369 it looks like the ping
>> attribute has re-appeared.
>>
>> 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?
>>
>
> What's the reason for requiring this, while just installing an click
> handler on the link and sending an XHR and navigating on completion of the
> XHR wouldn't notify the user?
>
>
> I think the ping attribute is of interest because it doesn't incur the
> performance delay involved in delaying navigation until an XHR is completed
> (or, as might be a more common practice, redirecting through a server that
> logs the navigation click).
>
> The suggestion (I believe Hixie is the original author of the text) was
> that the attribute would be an opportunity to provide a privacy advantage
> over those click-handler/redirection alternatives. It's true that
> background XHR requests can and do track user activity without transparency
> or control, the question was whether we could improve on that situation.
>
> There are similar questions around Beacon, which also sends analytics data
> in the background, and is implemented to prevent the performance delay
> involved in unload handlers that block until a request is completed. I
> think UAs have not implemented UI in those cases to provide transparency
> either.
> https://w3c.github.io/beacon/#privacy-and-security
>

I mean, improving the transparency of what's going on is a noble goal,
however, I don't think ping or beacon were introduced with that goal in
mind, but to reduce the negative performance impact of common analytics
frameworks.

I'm also wondering whether creating transparency around those pings is all
that valuable compared to creating transparency for other things on the
such as third-party tracking?


>
> 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:
>> https://lists.w3.org/Archives/Public/public-html/2007Nov/0055.html
>>
>> 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.
>>
>
>