I would like to read the browser's "localstorage" when the browser is off using the OS !

I want to save client data in localstorage and then switch off the browser and the internet and then let an OS program (a windows exe) access and analyse that data and then write new data into that localstorage area so that when the browser restars the new data is in localstorage.

This should be possible because my OS (i.e. windows) can read can delete cookies from the browser "files" ... so presumably once i know the format of the localstorage "file" then the OS is boss of all of its files and so it should be able to alter them !

So: how do i read and write to JavaScript/HTML5/DOM "localstorage" using "client side .exe programs" ?

FAILING THAT: is there any other way that the OS can pass simple data into (and out of) the browser ?

Obviously all of this has both huge potential POWER and huge potential DANGER !

The browser can only bee the "virtual OS of the future" if the real OS can interact safely with it !!

Thank You.

I would like to read the browser's "localstorage" when the browser is off using the OS !

I want to save client data in localstorage and then switch off the browser and the internet and then let an OS program (a windows exe) access and analyse that data and then write new data into that localstorage area so that when the browser restars the new data is in localstorage.

This should be possible because my OS (i.e. windows) can read can delete cookies from the browser "files" ... so presumably once i know the format of the localstorage "file" then the OS is boss of all of its files and so it should be able to alter them !

So: how do i read and write to JavaScript/HTML5/DOM "localstorage" using "client side .exe programs" ?

FAILING THAT: is there any other way that the OS can pass simple data into (and out of) the browser ?

Obviously all of this has both huge potential POWER and huge potential DANGER !

The browser can only bee the "virtual OS of the future" if the real OS can interact safely with it !!

Thank You.

• javascript
• windows
• html
• dom
• local-storage

• "Obviously all of this has both huge potential POWER and huge potential DANGER !" - it does? – Mark Amery Commented Feb 3, 2013 at 21:59
• This depends 100% on the browser. Different browsers will implement local storage differently. – Lightness Races in Orbit Commented Feb 3, 2013 at 22:02
• 1 thanks for ents - really i am hoping JavaScript and the HTML-DOM will bee the defacto "program running platform" of the future - but javascript need considerable beefing up to get there - i hoped localstorage could lead to a "safe-secure-wide-fast" pile between he browser (on any OS) and the OS files and indeed "real memory". – Clive Williams Commented Feb 4, 2013 at 12:19
• the obvious danger is the the misuse of that "pipe" to attack the OS - however as control of a "sandboxed file and real memory area" could be set by the OS writers and the Javascript-DOM specifiers - all could be well !!? (that's the hope anyway - obviously Javascript might then bee partly pilable for speed in number-crunching from the browser side - so we could in effect throw away all the old OS's (Windows, Ix's GUI's DOS etc) - so the browser would be the ONLY and single used "puter human interface" of the future ! ..... so obviously we are not there yet - but we can do it !!! – Clive Williams Commented Feb 4, 2013 at 12:26

2 Answers 2

Of course an app running locally with the appropriate permissions can access any file on disk. However, the real question is what to do with that file once it's open?

Consider the following:

• Each browser (Chrome, Firefox, IE, Opera) is likely to store localstorage data in its own proprietary format. You'd have to reverse engineer those formats.
• Since those formats are an implementation detail (not a documented API), they are liable to change. This will break your app and/or corrupt user data.
• What happens if you modify those data files while the browser is open (even if the page in question isn't open)? The browsers don't expect their data files to change out from underneath them, so it's likely you'd see strange behavior.

All of this is to say that this is a very bad idea. You're messing with the internals of someone else's application; that's a big no-no.

Have you considered an alternative approach? When I was faced with a similar problem, I simply implemented a very simple HTTP server in my app that was bound to a specific port on 127.0.0.1.

With XHR and the appropriate CORS headers, your browser-based application can municate with your desktop app in a safe manner.

Here are some other ways:

• Embed a web browser control in your application. The web browser control can readily peek into the page, and the page can readily peek into the local storage. The web browser control refers chiefly to Internet Explorer.
• You can pass parameters from the web page into an initiated executable (even a batch file) by manipulating the name of the executable. (Use application/bat as Content-Type to invite the OS to run your program when the user downloads it.)
• A ClickOnce program initiated from the browser can readily receive data from the webpage.
• You can use automation in your program (AutoIt, AutoHotKey) to copy/paste to an from a field on your web page. You can find the window by title as you control the title on the web page side. You can even automate opening a browser, navigating it to a page that dumps the local storage into a text field, and focuses the field.
• ActiveX controls (good luck)

I can't speak for similar tricks for OS X or Linux.