Feature requests

[Pol]

I mentioned this above, but I guess I wasn't very clear, the helper is responsible for allowing or denying access to the folders, not the daemon, so if the helper isn't running then all of the folders are effectively disabled.  This is not a security risk for encrypted folders (unencrypted folders are inherently insecure, and we provide many warnings and explanations about how and why you'd want to use those), nor do we consider it a defect in the design of iSpy. We're aware BTW that we don't provide much information about iSpy, this is for various reasons, including "trade secrets", but a bit more info is available here.

Ah OK, I was indeed suspecting the helper was in charge of this, thanks for confirming. I'm not concerned about the data being accessed: like you said it's encrypted. I'm concerned about data leakage or application instability as the app can write to the protected folder in some circumstances (as mentioned in the above non-theoretical example).

The current design of "if the helper isn't running then all of the folders are effectively disabled" seems a real weak point. You'll never be able to guarantee that your helper can run before any other process that can potentially write in the protected folders. And the helper can crash and not be relaunched too. There might also be race conditions as well.

If you can't move this logic from the helper to the daemon, then it seems putting an ACL on the protected and enabled folders is the minimum thing to do. It's just a few lines of code and might be good enough for now :)

[greg]

If you can't move this logic from the helper to the daemon, then it seems putting an ACL on the protected and enabled folders is the minimum thing to do. It's just a few lines of code and might be good enough for now :)

Indeed, ACLs are the path we'll take for this, as moving those sorts of decisions into the daemon is a huge no-no (for which there are many reasons).