Windows INI files and its registry have both advantages and limitations, particularly from a developer’s viewpoint. In this
DevSource article, Peter Aitken explains what they are, and explains how .NET’s isolated storage works: it provides a location on your drive that only a specific application can find and use. He explains when isolated storage is a developer’s best friend, and when you shouldn’t bother.
Exploring .NET’s Isolated Storage
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
err, is it just me or is all this a bit silly and overcomplicated? Surely OS X gets it just about right:
Application preferences go in ~/Library/Preferences/ and are all in a standard XML plist format.
If needed, an App can also use ~/Library/Application Support/
And of course these folders have an equivalent that covers the whole computer if need be:
/Library/Preferences/
/Library/Application Support/
This seems to cover everything that “Isolated Spaces” does whilst being a lot tidier. Why can’t Microsoft just go with that?
I mean, what would be incredibly cool is if I could copy my preference files from the same location on a Mac to a Windows box and have everything work since they’re in a standard format and location.
The purpose of Isolated Storage (as opposed to the Application Settings folder) is to facilitate the storage needs of applications in +Internet Zone+. That is, .NET “applets” and click-once applications run in a security sandbox (as Java applets do). They therefore cannot write to the user’s home folder. They can, however, write to isolated storage.
How quick everyone is to bash MS for allegedly over-thinking. Under-thinking and a general lack of good faith is the real problem here.
“How quick everyone is to bash MS for allegedly over-thinking. Under-thinking and a general lack of good faith is the real problem here.”
With a reason. And good faith has nothing to do with technology; that’s part of the religion.
BTW, applets proved to be a failure. Why is MS implementing applets now? Nobody has .NET installed. More people has access to Java runtime, and still there are no java applets anymore. Now everything runs flash or ajax.
Isolated storage is part of the overall code access security system. It goes beyond applets, or as Microsoft puts it:
“Today’s highly connected computer systems are frequently exposed to code originating from various, possibly unknown sources. Code can be attached to e-mail, contained in documents, or downloaded over the Internet.”
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cp…
Here is more information on .NET ClickOnce:
http://msdn.microsoft.com/netframework/windowsforms/learning/featur…
Isolated storage is part of the overall code access security system.
What that article is describing is a problem that Microsoft thinks needs solving. No remote applets or applications of any description should be storing anything on my hard drive, restricted or otherwise. We all have enough trouble right now with cookies and the information they contain, and thank goodness for alternative browsers (i.e. not IE) that let you control them more tightly. Java applets have been sandboxed fully for years without needing any access whatsoever to any kind of local storage – however temporary or isolated.
And besides, people have been using VMs and sandboxing for years to ensure that an application doesn’t get access to the filesystem or anything else remotely critical in a system, or to make sure that any settings that are saved are, at most, things like cookies. Needless to say, this wasn’t done with the disaster of Microsoft’s ActiveX in IE.
In short, there is absolutely nothing remotely useful about isolated storage. If you think about the unmitigated disaster that was ActiveX then it may provide some kind of protection on that front in Microsoft’s crazy internet world, but for everyone else there is simply nothing to see here.
“Today’s highly connected computer systems are frequently exposed to code originating from various, possibly unknown sources. Code can be attached to e-mail, contained in documents, or downloaded over the Internet.”
Wow. However, things would be a whole lot simpler if Microsoft actually heeded that advice and actually wrote better code, rather than coming up with soundbites and new things that mean very little.
Here is more information on .NET ClickOnce
Hmmmm. It may just be me, but that sounds something like Linspire’s Click-n-Run software installation service, suspiciously enough. Is it possible that Microsoft are going to create some kind of software installation repository infrastructure? *Rolls eyes*
The thing I find most interesting from reading that article is, is the scope of that isolated storage defined by the user or by the application developer? Can that isolated storage be restricted in the same way as cookies by the user? If the answer to the first question is the latter then it’s a huge security and privacy problem for the user, and if the answer to the second question is no then it’s a security and privacy problem for the user.
Isolated storage does not provide secure storage. Unmanaged code can access the files, and the administrator can open or delete the files.
Hmmmm. That’s a pretty strange idea of who is trusting who there, and is a clue to where this thing is really heading and where the power lies in it. I may want to run a spyware application that checks on what these little applications have been doing and storing, and as an administrator I may very well want to delete what this application has been doing on my machine. It’s not very reassuring.
There are also a few other holes in it from that article you can build an eight lane motorway through. Please, just don’t make me laugh.
You seem not to get it. Isolated storage is “cookies” for web applications. Web apps have 64KB of storage on your system to use.
Applets never took off for consumers, but I have few doubts that intranet and LOB applications are written in this style. That’s what ClickOnce is about too (it’s been around since .NET 1.1)… You go to an intranet site and it downloads the latest version of the software to your machine and then you use it to access your company’s HR records or other internal functionality.
I really don’t understand what you have to say about the admin being able to delete the files… of course he/she can! It’s in a hidden folder under your user profile dir.
You seem not to get it.
No, I think I do. Certainly your comment hasn’t told me anything new.
Isolated storage is “cookies” for web applications.
And?
Web apps have 64KB of storage on your system to use.
And?
…but I have few doubts that intranet and LOB applications are written in this style. That’s what ClickOnce is about too
Intranet and internal applications certainly do make use of applets, or developed applications are distributed through something like Zenworks. Isolated storage becomes pointless, because you trust the applications you distribute in your own company. The only target usage for isolated storage is for application developers distributing applets over the internet to unknown users.
I really don’t understand what you have to say about the admin being able to delete the files… of course he/she can!
That’s because you didn’t actually read what was written, or you did 😉 :
The article said this:
“Isolated storage does not provide secure storage. Unmanaged code can access the files, and the administrator can open or delete the files.”
That quite clearly tells you where this is heading and who it’s targetted at ;-).
I get it. The Microsoft and .Net fanboys are out on this one ;-).
Nobody has .NET installed
Slight modification, should be “almost everyone has .NET installed”. Also, give the rise of MONO in Gnome, we may be able to say the same under Linux some day!
“Nobody has .NET installed”
Actually 99.6% don’t have Linux installed. That qualifies as “Nobody”.
OS X is pretty scarce too.
Actually 99.6% don’t have Linux installed. That qualifies as “Nobody”.
OS X is pretty scarce too.
And who modded this up to 5? It may very well be true, but it’s got nothing to do with the article or the comment it is replying to.
Oh, and if you want to mod down read the guidelines before you do.
<blockquote>
How quick everyone is to bash MS for allegedly over-thinking. Under-thinking and a general lack of good faith is the real problem here.
</blockquote>
Well, in this case it’s true. Settings are part of the application; the current hacks–dot files, the registry, etc.–are in use mostly because of the lack of a suitable application bundling mechanism (see: windows) and to allow for per-user preferences for global applications. The latter problem is easily solved by using some sort of mechanism similar to unionfs (http://www.am-utils.org/project-unionfs.html).
The security rationale is noble, but it hardly scratches the surface of what could be done if they were to use the system outlined above. Namely, applications do not need to modify anything outside of their own directory, barring the special case of file editors/views. In a document-centric interface, documents are opened only through the file manager, so permissions can be easily determined at that time by allowing the app to read/write only the files which the user is trying to open.
Well, in this case it’s true. Settings are part of the application; the current hacks–dot files, the registry, etc.–are in use mostly because of the lack of a suitable application bundling mechanism (see: windows) and to allow for per-user preferences for global applications.
There is an suitable mechanism, the Documents and Settings hierarchy. The registry is also such a mechanism, but its primary purpose for globally registering types.
The security rationale is noble, but it hardly scratches the surface of what could be done if they were to use the system outlined above. Namely, applications do not need to modify anything outside of their own directory, barring the special case of file editors/views.
Isolated storage is used primarily for applications that have no footprint. They don’t install and they don’t run with full trust, thus they don’t have their own directory.
There is an suitable mechanism, the Documents and Settings hierarchy. The registry is also such a mechanism, but its primary purpose for globally registering types.
No. Those methods disassociate the settings (physically) from the application. I’m talking about bundling as in app-dirs.
Isolated storage is used primarily for applications that have no footprint. They don’t install and they don’t run with full trust, thus they don’t have their own directory.
I see you’ve missed my point. Application directories as I’ve outlined need no footprint either way. They don’t rely on any outside files unless the user specifically tells it to, which means you could easily save an application to a temp folder, run it, then delete it (or move it to a cache).
No. Those methods disassociate the settings (physically) from the application. I’m talking about bundling as in app-dirs.I see you’ve missed my point. Application directories as I’ve outlined need no footprint either way. They don’t rely on any outside files unless the user specifically tells it to, which means you could easily save an application to a temp folder, run it, then delete it (or move it to a cache).
You have the option of distributing applications on Windows that you can just put in the directory of your choice rather than install. In a Click-Once-like scenario however (at least the no-touch deployment scenario), the user wouldn’t participate in choosing where the application resides.
In a way (not REALLY, but in the way you are sort of applying it) it (unionfs) is like attributes in BeOS or Mac OS X but that are specific to users… so there would be the possibility of multiple attributes per application, perhaps, but only one set would be applicable per user. Interesting.
Err. I meant BFS and HFS.
OSX’s Preferences Manager (the high level api that allows apps to maintain plist prefs files) is buggy.
You wouldn’t fancy actually qualifying that comment in some way would you?
I have written many apps using the “preferences manager” – the real name is the defaults – and never had a problem. So I fail to see how it is “buggy”
a plain text file in ~/.app
Oh they like to complicate the things that are so simple.
Replying to myself. Why did I get moded down? For asserting the truth? Trolls.
Here we go again: you are not guaranteed to have permission to write to the user’s HOME directory; this is where isolated storage comes handy. Read, learn, try it and then troll.
The solution of ‘isolated spaces’ is wrong, because distributed applications do not only need hard disk space, but lots of other functionality, as well. For example, what happens if an “applet” (generic term for distributed downloadable application, not only Java) would need to execute another program?
The right solution would be to apply a kind of ring protection, like the one in Intel CPUs. Only this time rings are unlimited, and an application runs in the context of a ring: it can not touch anything of a lower ring, but it can certainly manipulate higher ring stuff.
This solution would not only allow distributed apps to use the hard disk, but it would also solve the problem of e-mail viruses (since attached programs are distributed downloadable apps as well).
For example, what happens if an “applet” (generic term for distributed downloadable application, not only Java) would need to execute another program?
They can’t unless the user runs them in a different context. Most apps that use isoated storage run with partial trust. They use isolated storage because they don’t have access to normal I/O. For that, they need more trust. Nothing is stopping you from building the app to run in a higher trust context, but you’ll have to either install the app in a context that gives it necessary trust, or (if supported in the particular partial trust context) ask the user to grant you the necessary trust. I don’t believe you can do this in the usual partial trust scenarios (browser-based or initiated execution running in the Internet zone).
If you have an app that needs wide access to resources, it really shouldn’t be an app that runs directly from the Internet, but one that is actually installed. If you’re on an Intranet, then the scenario is more workable.
The right solution would be to apply a kind of ring protection, like the one in Intel CPUs. Only this time rings are unlimited, and an application runs in the context of a ring: it can not touch anything of a lower ring, but it can certainly manipulate higher ring stuff.
This is basically what .NET’s Code Accesss Security gives you, but on a more granular level.
Edited 2006-08-15 20:55
If you have an app that needs wide access to resources, it really shouldn’t be an app that runs directly from the Internet, but one that is actually installed. If you’re on an Intranet, then the scenario is more workable.
If a ring-protection scheme was used, there would not be such restriction as ‘not running an app directly from the internet’.
If a ring-protection scheme was used, there would not be such restriction as ‘not running an app directly from the internet’.
This restriction is a default security policy. Even the ring system restricts access to higher privileged instructions. With CAS, the app could ask the user for consent in giving it access to more privileged operations, and/or the user could loosen default security settings, but many users would not make good security judgements about applications of unknown intent that they are running from possibly untrusted sources. There’s also the standard user account scenario. For some operations, the standard user wouldn’t even have the ability to give the app necessary privilege. Depending on the circumstances, the app can expand and degrade functionality based on current privilege, or it can just rufuse to run if privilege constrains functionality. It’s the application developer’s choice as to how the app behaves under those circumstances.
This restriction is a default security policy. Even the ring system restricts access to higher privileged instructions.
It’s the application developer’s choice as to how the app behaves under those circumstances.
But it is the O/S that knows what are the limits. If the O/S had a proper protection scheme like rings, then the downloaded application could access whatever its ring status allowed.