Of course, it will be vulnerable to key loggers and programs that read the decrypted data from RAM, but I don't think its possible to protect against these.
Unless the content you want to protect is highly valuable, I'd say you're probably right to dismiss these. Reading the decrypted data from RAM would be non-trivial and probably suggests a targeted attack if it is after your application's RAM specifically.
Isolated Storage appears to be a .net abstraction on top of Windows rather than an extension to the Windows API itself. This MSDN article reveals that the locations are, essentially, just the usual Application Data paths. The impact of the user, domain and assembly flags is summarised in this article.
I'm not a .net developer per se, so I decided the best way to test what happened would be to use the demo from codeproject, have a look at the directories and watch it with procmon.
So, first up, what sort of security attributes does
It doesn't, in conlusion, appear to have any specific access rights beyond what a usual user might expect to use.
Indeed, as you see above, I can waltz on in. Finally, having a go with procmon:
You might need to zoom that one, but as an interpretation, that's just a standard set of Windows API calls and a bit of locking access to the file. Because it might be of interest, what I was looking for was a call to
SetNamedSecurityInfo() which shows up as
In short, I think IsolatedStorage is Isolated as a .net abstraction, but .net runs currently on top of Win32, from which it provides no defence I could think of. So, it's as secure as writing files to My Documents or any other App Settings location you care to pick from the perspective of a Win32 App. Which is exactly what Ross has said - no defence from unmanaged code. I just like pictures.