Re: CHANGE PROPOSAL: Remove ping and hyperlink auditing (ISSUE-1 and ISSUE-2)

Kornel Lesinski wrote:
> ...
> It was thoroughly discussed, had experimental implementation and has 
> been redesigned in response to feedback. That's about the same as most 
> HTML 5 features.
> ...

Firefox 3.0 almost shipped with an experimental implementation that did 
the protocol part, but ignored the UI requirement (which used to be 
stronger than in the current spec).

So yes, there was an experimental implementation, but it failed to 
follow normative requirements in the spec.

> ...
>> Also, as described in ISSUE-1, ping's use of POST causes an
>> unsafe method to be used in response to a safe activation request,
>> in violation of the method constraints that have been part of
>> Web architecture since 1992.
> 
> Is current widespread practice of using GET specifically for triggering 
> side-effects better? If so, then ping can be made to use that too.

That proposal has been made many times, and has been rejected by the editor.

> ...
>> In short, if the UI is being presented as a normal link, then the
>> HTTP methods resulting from the user's selection must all be safe
>> (GET/HEAD/OPTIONS/etc.).  While some user agents may already fail
>> to protect the user in that regard, that is not an excuse to add
>> another broken feature to the standard.
> 
> I think it is. There's no point worrying about weak link in a chain that 
> is already broken in few places (form.submit() or submit button with 
> CSS/type=image are far more dangerous). Today servers/applications 
> without CSRF protection cannot be considered safe.
> 
> Switching to "safe" method may make very little difference in practice. 
> Web applications that don't need body of POST at all are very likely to 
> be exploitable via GET requests as well (e.g. PHP using register_globals 
> misfeature).
> ...

If it does make little difference in practice, why not do the switch 
then? At least the new feature wouldn't abuse HTTP the way it does now.

> ...
> There are already nastier tracking methods in widespread use that lack 
> UI. To compete with them ping probably even _shouldn't_ have UI. Anyway, 
> it gives browsers full control and tracking URLs, so browsers have a lot 
> of freedom with UI implementation, if any is ever needed.

Currently the spec 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 URLs."

So far I haven't seen an implementation of that. It appears you say this 
requirement isn't needed, in which case you probably should open a bug 
requesting to remove that part.

Best regards, Julian

Received on Tuesday, 8 December 2009 10:14:59 UTC