[whatwg] Better model for avoiding history spam from pushState?

[Maciej Stachowiak]

On Nov 21, 2005, at 4:13 PM, L. David Baron wrote:

> In http://lists.w3.org/Archives/Public/public-webapi/2005Nov/0017 , I
> wrote a comment on a WHATWG spec,
> http://whatwg.org/specs/web-apps/current-work/#scs-session , which I
> quote here:
>
>> On Monday 2005-11-21 07:44 -0800, Kenny wrote:
> [...]
>>> My big concern with both document.save and pushState is security.  
>>> The
>>> pushState method has a recommendation for security, "It is suggested
>>> that to avoid letting a page "hijack" the history navigation
>>> facilities of a UA by abusing pushState(), the UA provide the user
>>> with a way to jump back to the previous page (rather than just going
>>> back to the previous state).", but if this is not implemented,
>>> malicious developers could take control of the users navigation.
>>
>> I think a better solution than extra user interface is a solution  
>> like
>> what popup blocking uses:  pushState (like window.open these days)
>> should only be allowed while handling a user event like a click or a
>> keypress that expresses the user's choice to navigate to a different
>> state (like navigating to a different page).

Increasingly, some aggresive sites are defeating the event-driven- 
only popup blocking by modifying ever single link in the page to do a  
window.open in an onclick handler. This leads me to conclude that any  
new feature where you would want to restrict it to user events only  
may be too dangerous to have at all.

Regards,
Maciej