No kidding. I especially liked:
>Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
and:
>Storing cookies in Web History (seriously. see FAQ)
Brilliant and EVIL. Wow.
>Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
and:
>Storing cookies in Web History (seriously. see FAQ)
Brilliant and EVIL. Wow.
That's pretty "nice". It might be possible to "improve" it by storing metadata inside the PNG, and then reading it by parsing it out of the raw data after the call to getDataURL().
I haven't tried this though, and it's possible browsers drop the metadata when they recreate the image. The spec says A future version of this specification will probably define other parameters to be passed to toDataURL() to allow authors to more carefully control compression settings, image metadata, etc.
http://www.nihilogic.dk/labs/imageinfo/ shows how to extract EXIF data from JPEG files, so using EXIF + the cache hack is possible for sure.
http://www.nihilogic.dk/labs/id3/ shows how to extract ID3 metadata from MP3s in Javascript, so you could do a similar thing like that.
Can anyone think why just using the cache hack + a JSON data file wouldn't work?
Also, it's not clear if you get access to the actual binary data from the image as it is served, or new data generated from the image as it is displayed - hence my question as to if using the metadata would work.
http://joshduck.com/blog/2010/01/29/abusing-the-cache-tracki...
Cookie stored as a simple variable in a cached JS file is IMHO better solution if you're trying to be sneaky — there's nothing unusual in variable assignment or cacheable JS file.