Cookie Size
Madness. All a cookie needs to store is be a unique identifier. Why 10Mbyte? 10 bytes is lots.
A slip-up in the implementation of HTML5 on Chrome, Opera and Internet Explorer can be exploited to fill users’ hard drives, according to a 22-year-old Web developer from Stanford. Feross Aboukhadijeh has posted a proof-of-concept of the exploit here and a demonstration page here. He explains that HTML5 is designed to allow …
The article says cookies up to 10Mbyte. Actually I don't want websites to store anything else, unless I go "File Save".
10 bytes is 80bits.
That's 1208925819614629174706176 possible visitors for each website.
What is this? HTML planning for a universe of visitors that it needs 80 Million bits of storage per visitor on your own machine?
This post has been deleted by its author
The article might say "cookie", but last time I tried writing a "cookie filler" page, the end result was that the cookie got as utterly huge as I had patience to wait for, but the web browser then failed at subsequent efforts to read any page from that site.
HTML5 local storage definitely ain't no 2kb text file.
Thereby missing the point.
HTML5 adds the concept of local storage so that more sophisitcated off-line web apps can be developed.
Writing a simple app in HTML, CSS and JavaScript is much easier and more portable than trying to do it with the more traditional technologies. What has been missing is the ability to store data.
The problem with true cookies is (a) by design, they are limited in capacity, (b) they are cumbersome in JavaScript, and (c) cookies are always sent back to the server. Off-line storage is easier to work with, and allows real data to be stored locally, perhaps permanently or perhaps you go back on-line and sync with a server.
Cookies are rightly used to store identifiers or perhaps unimportant user options. Off-line storage make the transition to creating a real web application.
"Off-line storage make the transition to creating a real web application."
Off-line storage almost makes it a local app. Cue lots of bloaty apps that rely on storing half their runtime data on your hardrive. Awesome.
Anyway i thought we were all supposed to live in clouds these days...
Already had to correct this on Slashdot. The latest stable version (released Feb 9th, and probably earlier versions too because the feature has been there for a while) of Opera is NOT affected. Why? It asks you what to do:
http://www.ledow.org.uk/Opera.jpg
Seems the same misinformation on the original site propagated through to Slashdot and The Register in spite of two independent sets of editors/journalists.
Actually, Opera IS affected. The limit should default to 5MB per orign, or set of related sites (i.e, all x.domain.com/y) However, testing with the demo page shows Opera accepting approximately 74-76MB before prompting. The prompt that comes up states that the referenced site -- not the master domain, but the subdomain was defaulted to 5MB. That should not have happend. The master domain (domain.com) should have been allocated a default of 5MB, not the subdoman (x.domain.com).
Given that, Opera should only accept 5MB from the original demo page before prompting. The fact that it accepts over 70MB indicates that Opera is NOT treating the storage request properly, and that the demo page is likely using approximately 15 subdomains or a psuedorandom subdomain selection that results in enough collisions to meet Opera's limits after approximately 75MB.
There is no rigorously specified default in the standard. The standard even admits that it's pretty much an arbitrary number to pick.
The point is that 76Mb of disk space is NOTHING nowadays and not going to fill up your hard disk (no more than just ordinary caching of web content, for example, which can default to Gigabytes of storage). It certainly won't crash your computer unless it was already going to crash anyway (76Mb of free space is just untenable on a modern system, no matter the OS - it's just not enough room to do anything, even temporary files or swap file expansion space - and you're system is going to crash).
Opera detects the situation, prevents it from getting silly, and asks the user. The fact it uses a different standard of "silly" is neither here nor there, because it's still a practical standard of "silly".
But if Opera followed the standard as written, it would stop and prompt at 5MB -- in fact the prompt that does show up indicates that this is the intent.
The break from standard that is the underlying issue is not the default amount of storage allocated, but the fact that subdomains are supposed to be treated as the same origin as all other subdomains of the same domain., and that is not done in the current stable version of Opera.
As I explained, the 76MB "limit" in this case is caused not by Opera, but by the way in which the filldisk demo script uses its subdomains. Since the number of possible subdomains for a given domain is practically infinite, a more intelligent script could use Opera to fill a drive.
More to the point, the default setting for Opera is 5MB, meaning that sites can already use 15 times the defined (in this case by the software, not the standard) limit.
While that is part of the intent of the standard, there's nothing* to stop a script from downloading data indiscriminately into the local storage, thus filling up your storage and running up a large network bill.
But there's nothing to stop the script from doing the downloading bit and just discarding the data, either. So the storage bit doesn't in itself add significantly to that risk.
*Except perhaps a proper implementation which limits a given origin (including subdomains) to a sufficiently low amount of storage, such as 5MB.
Why bother? If a botnet has your comp, why slum for a few to several Mb of localStorage that could be deleted on every exit of the browser if one has such things set up as opposed to gigs of harddrive?
It has been well known for some time that the memory limit can be expanded with a prompt, this simply gets around that. So at best a little browser patch is in order.
On the other hand as mentioned before, localStorage can be used for offline apps quite effectively. I have managed to compress a massive DB down to less than 2Mb (as a nested JavaScript array) and the accompanying JavaScript, CSS, and HTML are under 100 kb. Even with the 2.5 Mb limit, this leaves months worth of space for user data available without having to communicate with the web, and the app actually pops like Apple commercials after the edited sequences across all platforms.
Although, I will assume you are joking.
Eadon doesn't see adverts because he's using IE10 under Win8 with EasyList TPL.
(note - he probably isn't because installing a tracking protection list by clicking on a link is probably too advanced for the poor little lad. However, the 89 year old gentleman who lives over the road from me uses exactly this setup and never sees ads, except [for some reason] on Facebook which he no longer bothers with).
I appreciate you used the word "cookie" to try and give non-savvy users a clue about what's happening, but look at all the retardation you've caused in the comments. Cuhh.
This is not "cookies", in the slightest. This is "local storage", a very different thing with a very different purpose. Hence it being different. Cuhh.