Feature requests

Started by Pol, April 28, 2009, 12:10:37 PM

Previous topic - Next topic

Pol

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)

Pol

#1
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

Pol

#2
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

Pol

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

greg

#4
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:

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

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

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

Doesn't it already?

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

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

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

This is coming soon. ;-)

  • Add a setting to automatically re-lock the folder when the machine goes to sleep or when the user fast-user-switch
  • Add an option to automatically relock folders after some time

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

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!).
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

Pol

#5
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

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

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.

Pol

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

greg

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

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! :-)
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

greg

#8
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.
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

greg

#9
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.
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

Pol

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

Pol

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

greg

#12
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.
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

Pol

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

greg

#14
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.
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!