401217 - Issues with support for "ping" attribute

Status: RESOLVED DUPLICATE of bug 951104

(Core :: General, 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: 

I believe the "ping" attribute on <a> (see http://developer.mozilla.org/en/docs/HTML:Element:a) breaks RFC2616 compliance, in that it silently performs an unsafe method invocation (POST method). See RFC2616, Section 9.1.1).

Please consider:

- turning this off by default, or
- minimally turn if off by default for ping URIs on a different server.

Also I'd recommend to use a method != POST, such as GET or HEAD (and yes, these can be made uncached with the proper request headers).


Reproducible: Always

Comment 1

[Mardeg]

I think the pref should instead of being true or false, be an integer:
0 = off
1 = on for everything
2 = on for https:// SSL connections only
3 = on for originating site only
(any higher value) = on for https:// SSL connections for originating site only

Proposed default value: 2

Comment 2

[Julian Reschke]

Further comment: 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."

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

Comment 3

[Hixie (not reading bugmail)]

Turning the feature off would be a net loss for users, since it'll just mean authors continue using the tricks they use now,  with the associated problems they have (which ping solves).

Limiting it to same-domain would block a large number of use cases which again would just mean those authors continue using the tricks they use now,  with the associated problems they have (which ping solves).

Making it GET would violate HTTP since the whole point is to make this have a side-effect.

Regarding comment 1 and comment 2, please file separate bug reports for each request.

Comment 4

[Julian Reschke]

> Turning the feature off would be a net loss for users, since it'll just mean
> authors continue using the tricks they use now,  with the associated problems
> they have (which ping solves).

Ping may solve problems, but it introduces new ones. In this case, I think it's preferable to stick with the old ones for now.

> Limiting it to same-domain would block a large number of use cases which again
> would just mean those authors continue using the tricks they use now,  with the
> associated problems they have (which ping solves).

It would be nice to see a coherent document discussing these use cases.

> Making it GET would violate HTTP since the whole point is to make this have a
> side-effect.

Sorry, but that's a total misunderstanding about what RFC2616 says about safe vs unsafe. (related discussion in http://lists.w3.org/Archives/Public/public-html/2007Oct/0347.html).

Comment 5

[Hixie (not reading bugmail)]

(In reply to comment #4)
> > Turning the feature off would be a net loss for users, since it'll just mean
> > authors continue using the tricks they use now,  with the associated problems
> > they have (which ping solves).
> 
> Ping may solve problems, but it introduces new ones. In this case, I think it's
> preferable to stick with the old ones for now.

The old problems are bad transparency of user tracking, obfuscation of link targets, and significant performance degradation. The new problems appear to be limited to theoretical spec purity.

With all due respect, the new problems seem a better choice.


> > Limiting it to same-domain would block a large number of use cases which again
> > would just mean those authors continue using the tricks they use now,  with the
> > associated problems they have (which ping solves).
> 
> It would be nice to see a coherent document discussing these use cases.

I agree. If you would like to help write such a document I would be happy to discuss it with you, e.g. on IRC. I'm Hixie on Freenode (e.g. in #whatwg).


> > Making it GET would violate HTTP since the whole point is to make this have a
> > side-effect.
> 
> Sorry, but that's a total misunderstanding about what RFC2616 says about safe
> vs unsafe. (related discussion in
> http://lists.w3.org/Archives/Public/public-html/2007Oct/0347.html).

I understand that we disagree on what the spec says here.

Comment 6

[Julian Reschke]

>> Sorry, but that's a total misunderstanding about what RFC2616 says about safe
>> vs unsafe. (related discussion in
>> http://lists.w3.org/Archives/Public/public-html/2007Oct/0347.html).
> 
> I understand that we disagree on what the spec says here.

So please follow up on the HTML WG, in particular to what other's said: <http://lists.w3.org/Archives/Public/public-html/2007Oct/0360.html> (Roy Fielding), <http://lists.w3.org/Archives/Public/public-html/2007Oct/0356.html> (Charles McCathieNevile).

Comment 7

[Hixie (not reading bugmail)]

It's on my pile of feedback to reply to:
   http://www.whatwg.org/issues/#semantics-links

(Feel free to vote for those e-mails if you want them dealt with sooner rather than later.)

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hixie suggests two possible APIs:

1. A checkbox

  [X] Help sites by sending usage data when following links

Unchecking disables PINGs but keeps everything else the same

2. Two radio buttons:

   (o) Balance protecting my privacy with functionality.

   ( ) Protect my privacy over all else.

       Disables receiving cookies from and sending cookies to sites
       other than the ones you are visiting. Disables sending of usage 
       data to sites that request it.

       This option may cause compatibility problems with sites.

The second option disableds PINGs and third party cookies. Might want to disable cross-site referer there as well (and make cross-site Origin: headers have the value 'null', once we have Origin headers)

Comment 9

[Julian Reschke]

Some observations:

- specified almost 5 years ago
- single implementation (Chrome)
- removed from W3C HTML spec
- does not seem to be used in practice

Maybe it's time to remove the code, or at least to disable it (because what's implemented doesn't match the WHATWG spec anyway)?

Comment 10

[Simon Pieters [:zcorpan]]

ping seems to be supported in Safari and Edge as well now. They pass the hyperlink auditing tests in http://w3c-test.org/html/infrastructure/urls/resolving-urls/query-encoding/navigation.sub.html

Comment 11

[Anne (:annevk)]

OP should and will be considered as part of shipping this feature, but that is not this bug.