Comments on: qUIpt: caching JS in window.name

By: x00mario

x00mario — Mon, 07 Jul 2008 12:48:03 +0000

Just a sidenote: I just opened a Google Group for qUIpt rekated discussions:

https://groups.google.com/group/quipt

By: x00mario

x00mario — Mon, 07 Jul 2008 08:28:56 +0000

@Jordan: Yep – but if you allow the user to post HTML with dangerous attributes – which target definitely is – you mostly also have an XSS or a first step in this direction.

@stevesnz: It depends – if you have the possibility to compress and concat all your JS files during deploy you can and should use it. But not any site does it and this approach tries to give an overall solution to reduce the traffic sent from the server to the client.

Please keep in mind that the project is very young and there is of course a lot to optimize.

By: stevesnz

stevesnz — Mon, 07 Jul 2008 05:02:18 +0000

and if you’re using it to store multiple javascript files, then you better off just copy and pasting the all the files into a single .js file so that there’s only 1 http request.

that will stay cached for multi visists, window.name stuff won’t so will actually offer even worse performance

By: stevesnz

stevesnz — Mon, 07 Jul 2008 04:59:24 +0000

Just seems pointless, fiddly, and probably insecure. If it’s a really js complex app then just do the entire thing in ajax so you never leave the page

If you want persistent data store for a standard app, then store it server side via sessions.

By: Mikael Bergkvist

Mikael Bergkvist — Sat, 05 Jul 2008 16:41:33 +0000

What is it supposed to do? I get nuthin? I’ve tried it in Firefox 3, IE7, and Safari.

By: Nosredna

Nosredna — Sat, 05 Jul 2008 16:15:15 +0000

Is this really persistent? It goes away upon browser close, right? So it’s only good for replacing session cookies, right?

By: Jordan

Jordan — Sat, 05 Jul 2008 15:59:24 +0000

The HTML in my last post was not escaped. Here it is again: [a href="." target="alert('evil');"]Click Here[/a]

By: Jordan

Jordan — Sat, 05 Jul 2008 15:57:42 +0000

What if your site allows user input via HTML (like forums) and you fail to filter out the "target" attribute on links. Then someone could craft a malicious URL that modifies the window name and your website might run it. e.g., [a href="." target="alert('evil');"]Click Here[/a]

By: V1

V1 — Sat, 05 Jul 2008 11:47:28 +0000

U can just add a some sort of identifyer infront of the code that u will store in window.name.. If it doesn’t match the identifyer in your normal code, just fetch the regular data en clear the window.name..

Just taking a simple window.location as identifyer would probly be enough.. and lets face it… what would the chance that someone would inject evil code in a window.name and the person with infected window.name would actually visit your site…. So a simple identify string would be enough..

And if u secure information in window.name your just an moroon.

By: Urielka

Urielka — Sat, 05 Jul 2008 08:58:21 +0000

you can md5 the window.name with the md5 of your js file to prevent hackers from inserting code in window.name

By: uize

uize — Sat, 05 Jul 2008 07:34:38 +0000

*Really* clever, and *really* scary. Persistent data storage, persistent JS storage. And, basically circumventing the size limitations imposed on cookies. Seems more compelling for persistent state than JS module caching.

I’m inclined to agree that it’s good to rely on the caching controls of the browser for external JS modules, although one of my pet gripes about browsers is the lack of a formal packaging protocol – for *anything* external. Is there nothing in HTTP that speaks to batching of requests? I’m sure I’m not alone in finding that there are cases where one bundles many JS files into a single file in order to improve page performance by reducing HTTP requests. We also do this with CSS sprites. So, clearly the HTTP protocol – in its current form – is failing critical use cases and critical request patterns. There’s a need that the spec is not adequately addressing.

So, one of the gripes about creating JS bundles for some pages is that on other pages when one wants to load in only a few of the modules that were already part of a bundle used on some other page, those modules are not already cached from the browser’s perspective. In an ideal world, an enhanced HTTP would just take care of this automatically, based upon negotiation between the client and the server, so that the sweet spot of separate requests vs batched/bundle requests would just be tuned over time by the server’s record of performance and how separate vs bundled would improve performance.

HTTP and networking is already a sophisticated world of complex algorithms of mathematics. It doesn’t seem unreasonable to push HTTP further in the direction of negotiating the pattern of requests to achieve optimal results, without forcing application designers to have to build access assumptions into their application design.

By: rindu

rindu — Sat, 05 Jul 2008 04:59:35 +0000

I have try on FireFox 3. This is good. But … When I type new url on address bar. The Firefox take all my CPU around 30 sec and then display the warning to continue or terminate the running script.
Hmm … this not good for my client and need more improvisation to to handle it. But thank you and good work.

By: Nosredna

Nosredna — Fri, 04 Jul 2008 21:17:11 +0000

So it’s gone when you close the browser, right? Anything else that kills it?

By: x00mario

x00mario — Fri, 04 Jul 2008 19:27:30 +0000

@V1: browser caching relies on several factors that can’t completely be controlled by site owners – headers, client settings, SSL, strict provider etc. I made several performance tests – IE7 runs slower as soon as you start putting more than 2MB into window.name. FF3 runs pretty stable even with +200MB.

By: V1

V1 — Fri, 04 Jul 2008 19:05:49 +0000

Did u test storing large data in window.name in IE.. performance based.
Also did u test.. window.name performance when the memory is running full?

As these a some big issues that i found out when using the window.name for storage, even for small javascript of a size around 150k (normal extended library size)

Also, i don’t really see the point of “caching” javascript in window.name as the browser already caches it itself.

By: Nosredna

Nosredna — Fri, 04 Jul 2008 16:53:18 +0000

Clever.

Can I use window.name as a persistent store for other things?

By: x00mario

x00mario — Fri, 04 Jul 2008 15:33:20 +0000

Not all browsers support the CacheControl headers for SSL connections yet – and it may take more or less long while until the majority will do. So as a site owner you can remove one blackbox (you never really know how your users configures the caching and why and when resources are loaded again) and traffic generator.

By: ironfroggy

ironfroggy — Fri, 04 Jul 2008 15:19:44 +0000

This should not be needed if you provide proper caching headers.

By: x00mario

x00mario — Fri, 04 Jul 2008 14:57:05 +0000

Yup – I am not yet sure if the script is “un-hackable” in all major browsers – especially IE6 – but my tests showed good results. During this month we will start a live test on a high traffic site – I will post the results to the project page as soon as completed.

By: SimonWillison

SimonWillison — Fri, 04 Jul 2008 14:40:25 +0000

On second look, he’s guarding against that attack by checking document.referrer before eval()ing the JavaScript in window.name. Smart workaround.