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
