[whatwg] several messages about pushState() and related ideas

[Ian Hickson]

On Fri, 22 Apr 2005, Brad Neuberg wrote:
> 
> Whenever I implement a DHTML (Ajax?) type app that needs to talk to the 
> server without refreshing the client, such as through a hidden iframe or 
> an XmlHttpRequest object, I always wish that I could update the window 
> location bar to show a bookmarkable and copyable URL, but update it in 
> such a way that it _doesn't_ refresh the browser or change it's location 
> (window.location.href changes the location).

I've now added URI and title parameters to pushState(), so we basically 
now have that.


> In fact, we should do a security, phishing, and annoyance scan (blink 
> tag anyone?) over the WHAT-WG draft itself sometime, forming a threat 
> model before so we know what potential attackers would actually be 
> trying to do.  When we take this into account we should remember that 
> sometimes email programs embed the browser into themselves, so that WHAT 
> standards could be embedded into email messages, leading to various 
> kinds of attacks and general wierdness.

I encourage you to do this. The more people we have looking at this with 
an eye towards how it can be abused, the better.


On Mon, 18 Jul 2005, Sjoerd Visscher wrote:
> 
> Now, what I'd really like to see a solution to the "bookmarking 
> problem". Well, it's really not a bookmarking problem, because you can 
> simply do
> 
>   location = "#...some representation of the state of the page..."
> 
> And you can bookmark that. The bigger problem is Google. Google afaik 
> completely ignores fragment identifiers. So if f.e. the bookmark 
> location was "http://www.example.com/#salesdep", and everybody is 
> linking to that location, there are 2 problems with Google:
> 
> 1. Google doesn't support javascript. But it is impossible for the 
> server to send a static page of the sales department, because fragment 
> identifiers are not sent to the server with http requests.
>
> 2. Because of the links, Google will add the page to its database, but 
> it will remove the fragment identifier. So even clients with javascript 
> support will see the homepage instead of the sales department page, when 
> they found the page through Google.
> 
> So what we need is a way to change the path or the query part of the 
> location, without getting a page reload. I think it works best (security 
> etc) to just allow to change the query part. It would probably make the 
> most sense to make this the second argument to pushState.
> 
> In our example we could do
> 
>   history.pushState(data, "salesdep")
> 
> and get http://www.example.com/?salesdep in the address bar.
> 
> When Google, or any other non-AJAX client, follows that URL you can let 
> the server generate a static sales department page. AJAX clients get the 
> basic site framework, and the client will read the query string and go 
> to the sales department part.

You can now basically do what you request.


On Fri, 25 Nov 2005, ROBO Design wrote:
> 
> True. This is why I propose that pushState() to allow an URL as an 
> argument, so it can behave in the same way as save() was suggested 
> previously, but with a twist: some strict rules to as which URLs the 
> author can use in the argument. Not a big twist, but it's something.
> 
> For example, the author of http://www.example.com/test.htm should not be 
> allowed to insert in history a page from another TLD, domain or even 
> subdomain.
> 
> Now a malicious web developer can still do bad things, like: flood the 
> history. Yet, AFAIK, flooding/borking/braking the back button can be 
> done with pushState() as currently defined, so not a big difference (or 
> is it?). This is a problem similar to the alert() flood.
> 
> Yet, the problem can be solved in the following way by UAs: block (or 
> ask the user for confirmation) after a number of X pushed URLs in 
> history by a page. This is something that can be applied to alert(s) 
> too, yet in that case showing a checkbox can also be used (like in the 
> good old Opera 6).

This is now possible too.


On Fri, 9 Dec 2005, Maciej Stachowiak wrote:
>
> On Nov 21, 2005, at 4:13 PM, L. David Baron wrote:
> > > 
> > > 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.

I agree, and I think that the abuse limitations on pushState() would have 
to be rate-limited or capped at a certain number, not based on how the 
method was invoked.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'