401352 - Missing UI distinction for a/@ping attribute usage

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Julian Reschke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: 

The current editor's draft of HTML5 states:

"When the ping  attribute is present, user agents should clearly indicate to
the user that following the hyperlink will also cause secondary requests to be
sent in the background, possibly including listing the actual target URIs."
-- http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.299&content-type=text/html;%20charset=iso-8859-1#hyperlink0

This doesn't seem to be the case in FF3, thus I'd propose to disable ping handling by default.


FF isn't doing this -- why? Please consider disabling "ping" until it does.

Reproducible: Always

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I suspect this will be WONTFIX, and that we'll leave this problem to be solved by add-ons. But it might be worth exploring some alternative options.

Comment 2

[Clement Cherlin]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #1)
> I suspect this will be WONTFIX, and that we'll leave this problem to be
> solved by add-ons. But it might be worth exploring some alternative options.

As per the Mozilla Nonprivacy Policy, web "features" that provide functionality to data miners but not to users are core, on by default, and have no visible preference. Notifying users of these privacy holes, and giving users the option to disable them is left "to be solved by add-ons".

Comment 3

[Nick Doty]

The HTML specs suggest adding the URLs that will be pinged to the tooltip or status bar for browsers modes that have those UIs. That would roughly match the (poor, but present) UI that accompanies the case where URLs are sent through a top-level navigation redirect. Since the ping URL is probably not relevant to the user (they explicitly aren't navigating to the ping, just notifying the domain owner), I think one could instead experiment with an icon or an icon+hostname.

Some UI affordances only exist on some devices, and it would make sense to use what affordances are present on desktop even when an exact equivalent can't be implemented in some other situations. Tap and hold UI exists in mobile Firefox -- including the full destination URL (which on google.com actually includes google.com/url?sa=&url=https:example.com/actual/destination/url) and some contextual commands like copying either the URL or the text, and that UI could also note that background link tracking will occur by tapping on the link.

(I noted similar suggestions in the Chromium bug.)

Leaving this to add-ons while simultaneously making this feature on by default would mean that Firefox users would have less visibility into this kind of tracking than they have today, where at least click tracking done through redirects can be observed through hovering over a URL or noticing navigations in the address bar.

Comment 4

[Simon Pieters [:zcorpan] (OOO until Aug 4)]

I think we should close this as WONTFIX. See arguments in https://github.com/whatwg/html/issues/11309