I want to save a filesystem entry from chrome.fileSystem.chooseEntry to chrome.local.storage, as suggested here: unlimited file storage in chrome app.
Is this safe? Could another unwanted user/app look at chromes localstorage and change the value of the entry key I set in my app? Or is chrome.local.storage sandboxed just like app filesystem?
localStorage is protected from access by javascript in pages in other domains, similar to the way that cookies are protected. So, javascript access is only allowed from pages within the same domain.
Neither has robust security measures from being accessed outside the browser by external applications.
Whether that is safe enough or not is not something we could say as you haven't fully described the security needs of this particular element of your application. You would have to judge what is safe enough.
I wouldn't store my banking passwords in localStorage. But, I'm fine with storing application preferences there. The wide gamut between those two options depends entirely on the specifics of the situation.
Related
Making localStorage and/or IndexedDB data offline permanent?
Is it possible to make localStorage and/or IndexedDB offline data permanent?
I am planning to make a completely offline HTML5 app and want the data to never get deleted, unless and otherwise the user knowingly does so.
I do not want the data to be deleted even after the app is closed, system is shutdown.
...want the data to never get deleted, unless and otherwise the user
knowingly does so.
The Storage API allow requesting a "persistent" permission for your origin. If granted, the semantics are that the data stored in certain APIs (local storage, Indexed DB, Cache, etc) is preserved until an explicit user action (like clearing storage), which appears to match your needs.
Documentation:
https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
Note that this is a new web platform API. It was recently added to Firefox (57) and Chrome (55), but is not present in Edge or Safari. Also note that Chrome does not currently show prompts for this permission request; it uses heuristics about the web app to determine if the request should be granted or not rather than asking the user to make the decision.
The specification is at: https://storage.spec.whatwg.org
The spec gives a background on how storage could work in browsers, i.e. by default an origin's data is "best effort", meaning preserved until the browser needs to clear it (due to space constraints, etc). The actual behavior of browsers varies significantly.
I need an offline caching system where my app can store about 0.5 MB of data. It is preferred that there is no interaction required by the user, but small amount of user interaction might be acceptable
Currently, Microsoft's Silverlight is being used to store data offline. It is a large download for the plugin, and not installed as standard on most machines.
I have been considering cookies - but they are far too volatile. I can imagine numerous reasons someone might clear their browser cache and lose all their data.
I am not sure about HTML 5 storage, and how volatile it is in practice.
I have been looking into flash, which is installed on over 97% of windows computers. It seems I can load data from a user selected file, and save data to a user selected file.
My questions...
How big is the microsoft silverlight plugin download (in MB) for windows? (I think about 8mb, but did not get clear answer from the internet)
How can users accidentally (or deliberately without realizing the consequence) clear their HTML 5 storage on common browsers?
Is there a way to get flash to store or load data from local files without user interaction?
Is there another alternative I have not considered?
Well you could use Flash shared Object storage, which will allow between 0 and unlimited space. Check this settings panel for details of your own settings to get a better idea of what I mean.
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
Of course this does mean that the user will have to allow third party flash content to be stored locally, which is the default. Also the default storage space is 100KB, with the user being prompted to allow for a larger amount unless they have previously increased the default themselves. So that's a small draw back, but still workable.
I am not sure how you would access the shared object from within a silverlight app, as I have only used it via a Flash swf. I will do some digging around using javascript and get back to you on that.
Also there is another post that may help you:
Javascript bridge to Flash to store SO "cookies" within flash
It sounds like what you need is isolated storage.
I use it with all my silverlight apps and it couldn't be easier to use. With only a few calls you can store and retrieve data programatically.
Edit: I was thinking that your app is already programmed in Silverlight. What is your app programmed in? Is it simply HTML/CSS at the moment?
I have an extension where users maintain a list of links. It would be nice to have this data synchronized between computers (at work and at home). What are the possible solutions?
Chrome has extension synchronization option but I am not sure if it synchronizes data or not (I would be surprised if yes). Even if it does, not everyone would want all their other extensions be synced.
I can store my links in a special bookmark folder and use built-in bookmark synchronization, but in this case all bookmarks would be synchronized too (not all users would want that either I think).
Any external sites I can use? Something easy to use and linked to a google account?
(I don't want to build my own site for this)
Edit: As of Chrome 20 and above you can use chrome.storage module to save to the cloud.
chrome.experimental.storage.sync.set({'settingAlwaysOn': true}, function() {
console.log('Saved option in the cloud');
});
Before Chrome 20
You're right, the Chrome Sync for extensions options (in settings) does not synchronize extension data. The only way to synchronize those data is through a third party.
Since you ruled out the usage of Bookmarks, which makes sense if users don't want bookmarks to be synchronized.
Everytime you persist data through storage (Web SQL Storage, localStorage, IndexDB), you grab that object, and serialize it into JSON (via JSON.stringify), and you send it to some online service such as Google Docs.
That would be quite tricky for Web SQL Storage and IndexDB, you would have to do your own importer and exporter. For localStorage it is pretty simple, since its a key/value pair.
It requires some work to link it to a Google Account (such as Docs) you would have to use OAuth and do the plumbing to connect your extension to the service. Once your connected, it is not that difficult to maintain the state.
Good luck :)
Chrome 20 supports chrome.storage.sync API. It seems to fit your requirements perfectly.
For storing data offline WebApp can use:
session storage, "advanced version of cookies"
key/value based Web Storage (AKA local/global/offline/DOM storage)
sql-based Web SQL Database (deprecated) and Indexed Database API
FileReader and FileWriter API (requires user to select files each time the application loads)
But apparently there is no File Storage. Of course, there is a manifest-based caching, but it's just a cache and is not supposed to be used as a user data storage.
Does it mean that the user of WebApp is forced to use some sort of a cloud file storage?
Is there any way to save large files on user's local machine? Or maybe some way to select a local folder web application can use to store user data?
Edit. Security. HTML5 already has the ability to write big portions of data to user's local machine. I don't see any security issues if a browser will provide another, file-based abstraction to store data. It can be some virtual machine, virtual filesystem, whatever.
Hm, I think, it is possible to write JS filesystem and store it as a blob in SQL...
Similar questions.
Update:
Hm... recently I've found this and this. Maybe it is what I'm looking for... Yes, it is! See the answer below.
At last, I've found it! Here's the answer:
I’ll have the DOMFileSystem with a side of read/write access please wrote:
Eric Uhrhane of Google has been
working on the working draft of the
File API: Directories and System specification which defines a set of
APIs to create a sandboxed filesystem
where a web app can read and write
data to.
Wow! I'm so excited!
Why not use localStorage while the user is editing a document and the FileWriter API when they want to save it to disk? Most people are used to seeing a save dialog pop up when saving a document.
The only scenario I can think of that warrants userless access to the FileWriter API is an autosave feature, but autosaving to localStorage can be just as good.
There is a way to save relatively large files to a users hard drive if you are willing to use Flash. Look into Downloadify:
http://www.bitrepository.com/downloadify-client-side-file-generation.html
Downloadify allows you to send data to a SWF and have that SWF create a file on the users machine. My recommendation would be to store the data via one of the methods you listed, Webstorage, sqlite database, etc. Put all your assets, including the SWF in the manifest file so everything is cached locally to the browser. You can then pull information from your db or webstorage and use the SWF to create the files you need.
I'm not sure if you will be able to read these files back into your web application.
Another option to save data is by using link tags with the data URI scheme. However, I'm not sure if it is supported in all the major browsers at the moment.
For security reasons you can't write files to a user's local filesystem in case it gets used for nefarious purposes by evil people.
That's not likely to change, and that's a good thing.
The HTML5 FileSystem API started landing in Chrome 8 and is fairly complete as of now (Chrome 11).
There's a nice tutorial on it here: http://www.html5rocks.com/tutorials/file/filesystem/
http://fsojs.com wraps the FileSystem API effectively, if you want an easy solution
As mentioned by others here, the FileWriter and FileSystem APIs can be used to store files on a client's machine from the context of a browser tab/window.
However, there are several things pertaining to these APIs which you should be aware of:
Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs
IsolatedStorage, which hasn't been mentioned as of yet, also allows for file i/o from a tab/window context, but it is made available through solely through Silverlight and requires the use of managed code to access. It, like FileSystem, also exists in a sandbox and makes use of a virtual file system.
Given the high market penetration of both Chromium-based browsers and Silverlight (support for which, interestingly enough has been dropped by such browsers), you may find a solution which uses the first of the above approaches available on a client machine satisfactory.
BakedGoods, a Javascript library that establishes a uniform interface that can be used to conduct common storage operations in all native (including FileSystem), and some non-native (including IsolatedStorage) storage facilities, is an example of such a solution:
//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
storageTypes: ["fileSystem", "silverlight"],
options: {fileSystem:{storageType: Window.PERSISTENT}},
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
Just for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
I've started looking into HTML web database storage for some Chrome extension I'm working on, and it made me wonder - Who should be cleaning abandoned web databases? As opposed to desktop apps, there's no uninstaller for a web site. And as opposed to regular cookies, web databases can be much larger than just 4KB.
I can imagine some browsers or addons might give advanced users a way to clean up locally stored data, but I can't imagine my parents doing that. What will prevent web sites from clogging their hard drive once this feature is commonly used? Is there any way honest and responsible web sites can have their local data removed once they are not used anymore?
On the two websites and 4 apps I use html5 local storage in, I offer an option somewhere (off the About page, or in account settings, or a link at the bottom of the page) which gives you the ability to remove the local database and key-value pairs, as well as the option to opt-out of the site using it.
It'll be persistent, just like cookies. The difference with cookies is that you can store much more data and no expire date can be given.
Firefox has an option to clean those information automatically (Offline storage)