Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML5 localStorage allows sites to fill up users' hard disks

feross.org

Post reply on HN
Print view View original

181–190 of 191 posts

Re: HTML5 localStorage allows sites to fill up users' hard disks

#181

Post by emn13 »

pilif wrote: post #162
espadrine wrote: post #109

Earlier quoted context omitted.

> The question I'm asking myself now is how to fix this. Doesn't the website answer that? Just follow the spec! Firefox isn't vulnerable…

If you do that (like Firefox admittedly does), then my issue with subdomain users using up all local storage comes into place. It would really suck for github (for example) not to be able to use local storage in their UI because pilif.github.com used up all available storage for the whole domain.

This sounds like a mostly theoretical problem. Sure, it could be annoying, but if the quota simple is a little smarter (e.g. allowing a few filled subdomains rather than just 1, and/or always allowing the root subdomain to fill up, and/or evicting subdomains from localstorage on an LRU basis) then the chances of this happening non-maliciously are very small - and when push comes to shove, there's no guarrantee localStorage will persist anyhow, so every site needs to be robust in the face of data loss anyhow.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#182

Post by emn13 »

robryan wrote: post #146
ma2rten wrote: post #104

Earlier quoted context omitted.

You could simply fill up your subdomain's local storage and then do a javascript redirect to another subdomain.

Not if the browser only counted user navigations when deciding how space should be allocated.

It's too complicated. I don't think this is a real problem. Better to just evict a random subdomain entirely (or on an LRU scheme). After all, just like cookies, there's no guarantee the localStore will stick around, so any normal site needs to deal with this anyhow.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#183

Post by khuey »

romaniv wrote: post #165
curiousdannii wrote: post #115

The Chromium developers really dislike localStorage ( http://code.google.com/p/chromium/issues/detail?id=58985#c7 ) They'll have to fix this bug, but I won't be surprised if they try to remove localStorage entirely soon.

It sound like they hate synchronous APIs. Well, the synchronous nature of it wouldn't be a problem if: 1. JS has a language-level support for asyncrony. 2. The implementation of retrieval was performant enough or allowed for some way to control granularity of reads from the code. I really dislike that the idea that the only simple API for local storage will be gutted because of reasons quite tangential for what it do…

So synchronous APIs wouldn't be a problem if they were 1. Asynchronous or 2. Guaranteed to be really really fast? You do realize that the problem is that you can't guarantee that spinning rust will be fast, right?

Re: HTML5 localStorage allows sites to fill up users' hard disks

#184

Post by lucian1900 »

nollidge wrote: post #164
pbhjpbhj wrote: post #126

Earlier quoted context omitted.

I'd argue that a user generally has an idea that there is a persistent storage ("disk") locally held in their computer and that they have a good idea whether they want a website to use that space or not. The developer lacks the knowledge of the users requirements, that is why they can't answer the question. For "power users" the user is far better placed than the developer to answer the question about how much local…

> and that they have a good idea whether they want a website to use that space or not. "What's a website? I just double-clicked on my e-mail google and now Foxfire wants to fill up my disks. Is this going to put a virus on my Microsoft? Why don't they put it up in the clouds?"

Anyone that clueless couldn't possibly use whatever other solution to this problem.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#185

Post by shazzdeeds »

ygra wrote: post #105
rtpg wrote: post #97

Earlier quoted context omitted.

Prompt is the best solution to this. There's a prompt with flash.

Prompt is a horrible solution from a UX perspective. Essentially you're asking the user a question you, as a developer, couldn't or didn't want to answer. But the user has no idea either. Heck, she doesn't even know that there are limits in place or what DOM local storage even is.

Prompting should be a configurable setting for users aware of the restrictions. By default, I would have it evict based on timing interval for normal users, unless prompting was enabled.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#186

Post by shazzdeeds »

pbhjpbhj wrote: post #126
ygra wrote: post #105

Earlier quoted context omitted.

Prompt is a horrible solution from a UX perspective. Essentially you're asking the user a question you, as a developer, couldn't or didn't want to answer. But the user has no idea either. Heck, she doesn't even know that there are limits in place or what DOM local storage even is.

I'd argue that a user generally has an idea that there is a persistent storage ("disk") locally held in their computer and that they have a good idea whether they want a website to use that space or not. The developer lacks the knowledge of the users requirements, that is why they can't answer the question. For "power users" the user is far better placed than the developer to answer the question about how much local…

Most users would just answer yes, thinking bad things might happen if they run out of 'disk space'. So you'd still need some kind of eviction strategy for people that never said no.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#187

Post by kevingadd »

khuey wrote: post #183
romaniv wrote: post #165

Earlier quoted context omitted.

It sound like they hate synchronous APIs. Well, the synchronous nature of it wouldn't be a problem if: 1. JS has a language-level support for asyncrony. 2. The implementation of retrieval was performant enough or allowed for some way to control granularity of reads from the code. I really dislike that the idea that the only simple API for local storage will be gutted because of reasons quite tangential for what it do…

So synchronous APIs wouldn't be a problem if they were 1. Asynchronous or 2. Guaranteed to be really really fast? You do realize that the problem is that you can't guarantee that spinning rust will be fast, right?

I think he said that asynchronous APIs are a problem because they're hard to use well from JS, and that the performance of localStorage is a problem in part because the granularity of reads and writes is poorly specified.

Both of these things are true.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#188

Post by ygra »

baddox wrote: post #179
ygra wrote: post #105

Earlier quoted context omitted.

Prompt is a horrible solution from a UX perspective. Essentially you're asking the user a question you, as a developer, couldn't or didn't want to answer. But the user has no idea either. Heck, she doesn't even know that there are limits in place or what DOM local storage even is.

That's a bit like saying passwords and PINs are bad from a UX perspective. In a way, you're right, because any user flow gets simpler and smoother if you remove a password prompt, but it's pretty obvious why these things still need to exist.

Well, they get in the way of the user doing what she wants, of course. But they're a necessary evil, quite firmly entrenched by now (OpenID is subjectively worse even though it might be technically superiour) and they come expected for users these days. Just as you (usually) tell others your name when you call them on the phone, user names and passwords are kind of expected as a way of telling a web site who you are.

However, I'd say that prompts that may pop up whatever you're currently doing and ask for things most users cannot make an informed decision about. Eric Lippert once nicely summarised the problems in [1]. And while browser's confirmation dialogs are usually no longer modal, the problem persists. In the vast majority of cases the wanted result is »increase storage limits«. That this might pose a denial-of-service risk is something they are often not aware. And if you try telling them up-front they either won't read it or are needlessly scared. It's a hard problem, actually, especially given user habits concerning message boxes, confirmations and stuff.

[1]: http://www.mikepope.com/blog/AddComment.aspx?blogid=480

Re: HTML5 localStorage allows sites to fill up users' hard disks

#190

Post by pests »

natrius wrote: post #68
zanny wrote: post #65

Earlier quoted context omitted.

There really isn't an easy way to avoid this problem even if you follow the standard fixed quota per domain and subdomains don't count policy. You could just embed iframes to diskeater1.net, diskeater2, etc and fill up the disk that way. In the end, the problem is that one page can itself infer to other domain / subdomains in its document and those can execute and utilize localstorage. They have to, though, so you ca…

Prompt for origins that have never been visited directly by the user.

Isn't this how some browser recently started treating cookies? I believe so and makes sense to me as well.
Post reply on HN