Issues with support for "ping" attribute

NEW
Unassigned

Status

()

11 years ago
7 months ago

People

(Reporter: julian.reschke, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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

11 years ago
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

(Reporter)

Comment 2

11 years ago
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.
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.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
(Reporter)

Comment 4

11 years ago
> 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).
(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.
(Reporter)

Comment 6

11 years ago
>> 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).
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.)
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)
(Reporter)

Comment 9

7 years ago
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)?
OS: Windows XP → All
Hardware: x86 → All
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Blocks: 786347
No longer blocks: 951104

Comment 10

7 months ago
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
You need to log in before you can comment on or make changes to this bug.