It behaves the same here. The desktop is not one of the protected areas as far as I know. I remember we had a topic in the feedback board about this. It can be confusing to have something dropped there.
I don’t think its probably reasonable to generally prevent sandboxed files writing to the desktop? Too many progs would fai?. So I guess this is a help issue, if Bequick wants to do this he needs to add an additional protected folder?
I don’t think is’t probably reasonable a sandboxed program to do a thing.It’s sandboxed, right? Or it’s an illusion of sandboxing?
If I say untrusted, I mean untrusted.
IO don’t want a workaround.I want working CIS.
Maybe I’m not understanding what you are trying to accomplish. Are you saying your zip program was sandboxed, or the .zip file?
I would expect a program to run in the sandbox. Especially an action such as unzipping an archive, as that isn’t actually trying to execute anything inside the archive. What I wouldn’t expect it to do is harm my system in any lasting way. Did it do that? Perhaps then you might say CIS isn’t working…
Do you use Sandboxie? Try sandboxing your zip program and watch it unzip a file.
My program was sandboxed as UNKNOWN and was threated as UNTRUSTED.How is it possible for a program, which is sandboxed, unknown and untrusted to do it’s stuff without a problem?
I hope you understand now.It was a test and I didn’t expect jZip to work in these conditions.
OK forwarding this to format verified, on the basis that, from a users perspective, files treated as untrusted should not be able to drop files on the desktop.
The problem here is that changing this will probably require quite deep changes to CIS. (Protected files/folders to vary accoring to ‘treat file as’ setting). So I’m not sure this will change.
Happily you can adapte yourself by adding the desktop to protected files and using the | terminator. (plaese ask in help if you are not sure how). As a result some unrecognised files may not run - but you may feel this is a reasonable trade-off?