3 ms·
Why, again, was this needed? HTML5 is already looking like a security and management shitstorm; anything that makes it simpler is fine by me.
by jfb 16y ago
Why, again, was this needed? HTML5 is already looking like a security and management shitstorm; anything that makes it simpler is fine by me.
- Groxx 16y agoHow is a domain-locked local SQL database a security shitstorm?
- jfb 16y agoI suppose I'm just jumpy because of the lack of granularity in user control over local storage, and wary of the eptitude of the browser vendors, and in favor of fewer, smaller features. After reading the inept IndexedDB thing, however, it seems like the wrong local storage mechanism is going to get it in the neck.
- Groxx 16y agoYou've got just as much control. Grab the console and 'drop table' - all that data, gone. You can even trash all the databases in most browsers pretty simply. And restrict their size. The difference is that client-side JavaScript becomes useful with a large-ish local storage. Arguably, it's significantly safer than cookies, which are sent with every request (ie: Firesheep).
- ihsw 16y agoThe issue would largely be storing sensitive data (I presume), namely personally identifiable information. Imagine all the user data being stored in a simple and quick API that advertisers (et al) can grab at, rather than having to scrape through HTML bits on a page. Now imagine malware spreading across the internet and frictionlessly gathering this data. Although some might argue we're already there and that there's nothing stopping the deluge of user information.
- Locke1689 16y agoXSS and SOP disasters. Basically, everything that was broken about the web before, but more broken-y now. This of course applies to HTML5 local storage, too.