Messages

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 :)

Are you sure though that there are no other sync applications that are LaunchAgents as well? If there are then making the switch might not make a difference. Either way though, this could probably be solved with the ACLs that you mentioned.

Actually, there are plenty: just browse /System/Library/LaunchAgents.

If you don't care about Tiger, then I think it should be a LaunchAgent, just because it's cleaner, and that's what background apps are supposed to be. You can also make it crash proof this way using the "KeepAlive" setting. I once had the EspionageHelper crash on me (I had sent you the crash report), so this would be a good thing.

In any case, using ACLs would be a workaround, not a real fix. It seems that the default behavior for the deamon in regards to enabled folders is to prevent any access (security systems must be safe by default), independently of whether the helper is running or not, launching too late or not.

I just noticed the EspionageHelper is a login item, not a LaunchAgent. Any reason for that? I believe login items will run after Launch Agents when login e.g. after MobileMe sync tools and whatnot.

Didn't catch your edit:

This is not a theoretical problem: I've observed this several times so far using Espionage.

Please email us with the details, I'm guessing this likely only happens at login before Espionage runs (and therefore all folders are essentially disabled), as described in my response above.

I think this is what happened: it must have been at login time. But you're right, ACLs might not be necessary since Espionage would prevent access anyway (ACLs are evaluated through the same kauth system anyway). What I don't understand is when you say "before Espionage runs": it seems your iSpy daemon is in LaunchDaemons, not LaunchAgents, which implies it runs at system startup, not when user logs in. In this case, the daemon default action, if the helper is not running yet, must be to disable access to protected folders (as if you had clicked on Cancel). This way you won't get into these situations.

Here's a concrete reason why I really think ACLs are needed on the encrypted folder: say some background app wants to access the folder, and for whatever reason you decline (i.e. press "Cancel" instead of entering the password on purpose or by mistake), or you launch app, changes you mind at password prompt (nah, I don't need this app now), and cancel: the app will end up completely confused: it will see an empty folder, and start writing into it. Boom, there's a sensitive data leak! Worse, now the app is potentially in an incoherent state.

On top of that, the next time the app runs properly (because you allowed access this time), Espionage will see an non-empty folder, move it aside (this compounds the security problem), and report a warning to the user, who then has to pay attention, and manually securely delete that extra folder.

This is not a theoretical problem: I've observed this several times so far using Espionage.

• Add an option not to display anything as the folder content when it is disabled (or a custom message) -> This is another weak point telling people there is "secret stuff" here

I'm not sure whether this is worth the developmental effort, the idea behind encryption is that you can plainly flaunt it and it doesn't matter.

It is certainly crucial when people do a rapid inspection of the hard drive contents through the Finder e.g. at customs. More information here for instance: http://www.schneier.com/essay-217.html

• If disabled, the folder should be made read-only using ACLs (deny all)

This would seem to imply that users would therefore be forced to use some new mechanism in Espionage to move or rename folders.  Not sure why this is necessary...

If you "protect" the encrypted folder with an ACL, then there's no way users or apps can modify its contents by mistake. This doesn't prevent renaming or moving the folder itself (such rights come from the _parent_ folder).

• The FAQ should contain an entry for iSpy and indicate exactly what the Kernel Extension and Daemon do

Doesn't it already?

I saw them, but I was thinking of the FAQ in the embedded help. You can't expect users to go browse your blog :)

• In the "Folder Locked" dialog, it shows the name of the app that wants to access the folder, and not its path.

There's a hidden method of getting this information: hover the mouse over the text that says "The application '__' wants access to the folder:", the full path will appear as a tooltip if it's available.

Good to know! It'd be ideal if you could simply use an NSPathControl.

• When associating an application to a locked folder, the dialog doesn't let you go inside bundles which is necessary to add helper apps typically inside other bundles

This is a standard cocoa open panel, and as such if you need to go inside app-bundles (or access other parts of the system not visible from it), use Command+Shift+G.  You can also right-click on the application bundle in the Finder, locate the helper, and drag it onto the list.

That's what I ended up doing, but it's not super-practical. There's a method on NSOpenPanel to let the user navigate into bundles.

• You should really be able to group multiple folders together: it's just annoying to enter multiple times the unlock password for apps associated with multiple folders e.g. Safari.

You don't need to enter your password multiple times if all of the folders are using the same password.  If they are then that password will be re-used to open the rest of the folders associated with that application.

I thought I observed this problem in the past, but I just tried again and wasn't able to reproduce.

Some more:

• There should be an option to do application-refcounting for folder unlocking: for instance, if I protect the Documents directory, it's not really associated to any app. However, if I open a document in it through Word, and another one with Keynote, the folder would relock only when both these apps have quit.
• Add an option to automatically relock folders after some time
• You should really be able to group multiple folders together: it's just annoying to enter multiple times the unlock password for apps associated with multiple folders e.g. Safari.

Again, Espionage is a great great app with some huge potential once a few things have been improved :)

And a couple more:

• It would be very nice and useful to have a status item in the menubar (on the right side) that currently indicates which folders are unlocked, so that you can relock them if needed.
• Add a setting to automatically re-lock the folder when the machine goes to sleep or when the user fast-user-switch

Here are a few other ones:

• In the "Folder Locked" dialog, it shows the name of the app that wants to access the folder, and not its path. It actually displays under the dialog title another line with just the app name, and there's no way to see the full path - clicking on it does nothing. You should use a standard NSPathControl widget here as the full path information can be very valuable.
• When associating an application to a locked folder, the dialog doesn't let you go inside bundles which is necessary to add helper apps typically inside other bundles

Great, great work, congratulations! :)

Some feature requests:

• Add an option not to store passwords in Keychain at all -> This is a weak point as if the Keychain is cracked, so are all your encrypted folders
• Add an option not to display anything as the folder content when it is disabled (or a custom message) -> This is another weak point telling people there is "secret stuff" here
• If disabled, the folder should be made read-only using ACLs (deny all)
• The FAQ should contain an entry for iSpy and indicate exactly what the Kernel Extension and Daemon do
• "Default Filesystem" preference should be moved to the dialog shown when created a new encrypted folder
• Notifications that require a click to dismiss should have a different look (Growl is off)