In recent versions of Safari (I am on 5.1 now), local storage can be cleared with Safari » Reset Safari » Remove all website data. Or by using Safari » Preferences » tabsheet Privacy » Cookies and other website data » Remove All Website Data. And even by using Remove All when viewing the details on that very same Privacy tabsheet. The Security tabsheet no longer shows any button to view the databases.
Some more details, also for older versions:
On my Mac, I found the folder ~/Library/Safari/LocalStorage
, which has a file for each site that uses local storage†, with its creation date set to my very first visit to each site. On Windows, this might be in a folder like %APPDATA%\Apple\Safari
or %APPDATA%\Apple Computer\Safari
.
Deleting all those files, and restarting Safari, obviously cleared the data for StackAuth too.
However, logging in to a random Stack Exchange site gets me the StackAuth data again, and a file in the above folder, without ever being prompted to allow that (my Safari preferences show "Database storage: none allowed before asking"), and without the domain being shown in the "Show databases" list. This also happens in private browsing modes.
This seems to be caused by the difference between HTML5 Web Databases, and HTML5 Web Storage (the latter including local storage). Chrome shows both for Twitter:
Apparently Safari only warns for databases, not for local storage? Maybe blocking local storage is going to be as hard as stopping Adobe Flash from leaving its privacy trail. The specifications state:
User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.
Let's hope someone knows of an easier way, or that we get some more control in future releases. (I filed a feature request at Apple for that.)
† In my case, I found as many as 5,904 items dating back to March 2009. And even my own domains, for which I'm sure no local storage is used, were listed with 8kb files each. Investigation shows that Alexey Ruzanov's FlashBlock user script uses local storage too, and hence causes a file for each site one visits, regardless whether it uses local storage, and regardless whether it uses Flash.
Firefox's relationship between cookies and localstorage (from https://bugzilla.mozilla.org/show_bug.cgi?id=341524):
- disabling cookies disables storage, unless the site is on the whitelist.
- enabling all cookies enables storage, except if the site is on the blocked list.
- if a site is set to session only in the block list, only session storage may be used. Global storages are treated like session storages.
- similarly, if the cookie preferences are set to session only, all storage usage is session only
- if the cookie preferences are set to prompt, this is treated the same as reject cookies. Not sure whether we want prompting to occur here. Do cookies prompt every time a cookie is set, or just once per session?
- the hidden preference dom.storage.disabled can be used to disable DOM storage.
Thus, you should be able to use cookie managers such as Cookie Monster to control localstorage.
To view/delete persistent localstorage in Firefox, you can use Foundstone HTML5 Local Storage Explorer or NoTrace. Other related Firefox extensions are listed here.
From How to clear and disable DOM Storage in Firefox, IE and Chrome:
Clear DOM Storage in Firefox:
Select “Tools” -> “Clear Recent History”, open “Details”, check “Cookies” and select “Everything” as time range.
ATTENTION: No other time range will clear the DOM Storage.
[...]
Disable DOM Storage in Firefox:
Type “about:config” in your address bar and hit enter to view your internal browser settings. Scroll down to "dom.storage.enabled", right click on it and hit "Toggle" to disable the DOM Storage.
From Bypassing the intent of blocking "third-party" cookies:
In concept, HTML5 Local Storage is very similar to cookies. On a per-origin basis, there is a set of disk-persisted name / value pairs.
With a simple test, it's easy to show that the HTML5 Local Storage feature is not affected by the third-party cookie setting.
Mozilla knows about this issue: Bug 536509 - localStorage does not obey "third-party cookies" pref. Fortunately, if you untick Firefox checkbox "Accept cookies from sites," then localstorage is enabled only on domains that are allowed in Firefox's cookie Exceptions list. Since JavaScript is needed to set localstorage, JavaScript blocking extensions like NoScript can also mitigate this issue.
Localstorage test sites:
Firefox issue: Bug 748620 - When cookie expiration is set to ask every time, localStorage throws a security exception.
All of the information in this answer was adapted from DOM storage: browser data storage that can bypass the intent of blocking third-party cookies, a thread that I started.
Best Answer
Chrome provides the ability to block HTML5 LocalStorage as part of its cookie-blocking functionality. Since both technologies ultimately allow websites to store and retrieve data on end-user devices it makes sense to manage them in the same way.
Just click the Menu icon and choose Options (or Preferences on UNIX-like platforms), click Show advanced settings..., select Content Settings, and choose the Block any sites from setting data option:
While you're there, you can select Manage Exceptions to whitelist certain sites, or All Cookies and Site Data to manage or delete existing data.
Now when you visit a site, a small icon will appear indicating cookies or LocalStorage has been blocked:
If you click on that, choose Show cookies and other site data, and select the Blocked tab, you can see what data the site tried to save and whitelist sites on a temporary or permanent basis.
The Chrome authors are not big fans of fiddly knobs, so they're unlikely to add ones to disable individual storage methods. On the flip side, you can be reasonably sure any future storage methods will be blocked by the same mechanism without hunting for more checkboxes.