Tao Effect Forums

Espionage => Espionage 2 => Topic started by: Pol on April 28, 2009, 12:10:37 PM

Title: Feature requests
Post by: Pol on April 28, 2009, 12:10:37 PM
Great, great work, congratulations! :)

Some feature requests:
Title: Re: Feature requests
Post by: Pol on April 28, 2009, 03:19:29 PM
Here are a few other ones:

Title: Re: Feature requests
Post by: Pol on April 28, 2009, 05:20:21 PM
And a couple more:
Title: Re: Feature requests
Post by: Pol on April 29, 2009, 07:47:04 AM
Some more:

Again, Espionage is a great great app with some huge potential once a few things have been improved :)
Title: Re: Feature requests
Post by: greg on April 29, 2009, 05:42:05 PM
Thanks Pol, lots of great stuff there, many of your items are already on our TODO list (which currently has at least 81 items on it).  In due time we plan on getting through all of them.

To address some of the requests you brought up:


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.


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...


Doesn't it (http://www.taoeffect.com/espionage/support) already? (http://www.taoeffect.com/blog/2008/10/what-is-this-ispy-anyway/)


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.


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.


This is coming soon. ;-)


An auto-lock is planned for a future update, however, in most circumstances when we get this request, users don't realize that it's not necessary because they already have the tools to protect their folder.  Simply by enabling the checkbox in the Security System Preferences to "Require password to wake this computer from sleep or screen saver" is sufficient for protecting your encrypted folders. With that enabled your folders are protected, even if your computer is stolen while it's asleep.

Regarding the fast-user switch, it's not necessary to auto-lock the folder because their contents cannot be accessed by any user account, other than the one that owns the folder. To deliberately enable other users access to folders, we've implemented a "Public mountpoint" option which is turned off by default.


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.

Thanks again for your feature requests! Rest assured we will be knocking most of these out, but please be patient with us, we've got other projects in the pipeline as well (exciting stuff!).
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 11:30:22 AM
Quote from: "greg"
  • 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 (http://www.schneier.com/essay-217.html)

Quote from: "greg"
  • 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).

Quote from: "greg"
  • The FAQ should contain an entry for iSpy and indicate exactly what the Kernel Extension and Daemon do
Doesn't it (http://www.taoeffect.com/espionage/support) already? (http://www.taoeffect.com/blog/2008/10/what-is-this-ispy-anyway/)

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

Quote from: "greg"
  • 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.

Quote from: "greg"
  • 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.

Quote from: "greg"
  • 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.
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 11:42:22 AM
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.
Title: Re: Feature requests
Post by: greg on May 01, 2009, 11:54:41 AM
Quote from: "Pol"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 (http://www.schneier.com/essay-217.html)

That is a valid point, I've added this feature to our TODO list.

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

Well, it's on our Support page FAQ as well... but sure, there's no issue with adding this.

Quote from: "Pol"Good to know! It'd be ideal if you could simply use an NSPathControl.

We'll consider it, but right now there's not much of a demand for this feature, and I'm concerned about it cluttering that dialog unnecessarily, especially since we already provide a method of retrieving this info in the rare instance you need it.

Quote from: "Pol"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.

Thanks! Didn't know that! :-)
Title: Re: Feature requests
Post by: greg on May 01, 2009, 11:57:11 AM
Quote from: "Pol"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.

Actually, this will not happen because Espionage already acts as an ACL for the folder in this situation.  When you press cancel the app is denied the ability to access or manipulate that folder in any way (for a certain period of time).

This could be an issue if the folder is disabled and you run the app though, so in that specific case this may be a good thing to do. I've added it to our TODO list.
Title: Re: Feature requests
Post by: greg on May 01, 2009, 11:59:15 AM
Didn't catch your edit:

Quote from: "Pol"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.
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 12:06:33 PM
Quote from: "greg"Didn't catch your edit:

Quote from: "Pol"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.
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 12:08:20 PM
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.
Title: Re: Feature requests
Post by: greg on May 01, 2009, 12:17:58 PM
Quote from: "Pol"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.

Yes, actually this is a relic from a time when we were trying to support Tiger which doesn't support LaunchAgents (there turned out to be too many issues with Tiger to support it), and it is the helper that is responsible for denying the access.  Since it's been working fairly well we haven't made the switch, though the issue that you bring up may be a good reason to consider it; I've added to the TODO list.

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.
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 12:25:16 PM
Quote from: "greg"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.
Title: Re: Feature requests
Post by: greg on May 01, 2009, 12:35:20 PM
Quote from: "Pol"
Quote from: "greg"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.

That's a very good point, so we'll definitely look into this in the future, but for now it's not a super-pressing issue, and there are other higher-priority items on our list.  Thank you though for all of your feedback!

Quote from: "Pol"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 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 (http://www.taoeffect.com/blog/2009/04/taking-inqueries-for-ispy/).
Title: Re: Feature requests
Post by: Pol on May 01, 2009, 01:04:57 PM
Quote from: "greg"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 (http://www.taoeffect.com/blog/2009/04/taking-inqueries-for-ispy/).

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 :)
Title: Re: Feature requests
Post by: greg on May 01, 2009, 01:12:11 PM
Quote from: "Pol"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).