Messages

Hi leland,

The trial has no limitations to it, so this should not be happening.  However, which version of Espionage are you using? If you're not using 2.0.7, try updating to that and see if that fixes your problem ("Check for Updates..." in the Espionage menu).  If you still run into problems, please give us a detailed explanations of what you are trying to do (step by step), the more you tell us, the better we can help.

No, the folder is automatically locked if you log off, throw the computer in the pool, pull the plug, restart, etc. ;-)

Folders also cannot be accessed from another user account through Fast User Switching, even while your account is also logged in.

Checking the box to enable the sleep/screensaver password in the Security System Preferences is highly recommended, as this will protect your folder even if your laptop is stolen while it's "unlocked".

The reason is because what it means for an Espionage'd folder to be unlocked is simply that a virtual entity called a mounted volume exists at a specific location in /Volumes/EspionageMounts (see Espionage's built-in help documentation for more info).  This entity doesn't actually exist on your hard drive, it is a location through which data is encrypted and decrypted on-the-fly, and once you log off, or the computer is shut down, it disappears immediately.

Hi Jake, sorry to hear of the unusual trouble, are you running the latest version of Espionage?

Also, is the folder that you've encrypted in the side-bar? (i.e. alongside the other folders in the sidebar like Documents, Movies, Music, etc.)

One thing that you may one to try is to add Preview to the blacklist, you can do this directly from the password prompt itself (just click the little blue button in the lower left of the password prompt).

No problem, but if you want the script to run every 10 minutes then I would make sure that it checks to see if Mail is running before attempting to ask it for anything, otherwise you'll get the password prompt.

Also, if you *really* don't care about someone getting access to your email and only want to prevent say, a sister from seeing what's in there, then you can set Espionage to not use any encryption for Mail's folder, in which case you won't need to setup application associations for it.  The application associations are a method of allowing Espionage to delay the launch of an application while it decrypts (mounts) the application's data.

If you'd like your contacts to sync then you should definitely sync it after the folder has been unlocked.  One way of ensuring this is to use the "autounlock at login" option (and if you use the login keychain, then you won't be promoted to enter the master password when you login to autounlock folders).

Hi Ted, there are plenty of resources and information available both on Espionage's website and within Espionage itself.

First I recommend watching the the intro video on Espionage's homepage, and after that indeed Espionage does have a manual so I recommend reading that. You can access it either by clicking on one of the many context-sensitive help buttons in the application (like the one in the main window next to the "Discard Changes" button), or you can bring up it up by choosing "Espionage Help" from the Help menu in Espionage.

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

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!

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.

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.

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.

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.

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.

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.

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.

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

[not]

Hi Steven,

The only problem here is if Mail's folder is locked.  If the folder is unlocked, then whether Mail is running or not does not matter (if the "tell application id "com.apple.mail"" launches mail if it's not already running).

To get this to work first make sure that the script is saved as an "Application Bundle":



Then add it to Mail's application associations, and uncheck "Lock on Quit":



Make sure that it's not run upon login by any means.  If you need it to run at login, then set the "Launch at Login" option for the association in Espionage.

This means that if the script is launched and Mail isn't running, you'll be prompted to enter the password for Mail's folder, Espionage will unlock the folder, and only after the folder is unlocked will it actually allow the script to be run.

Note: I haven't tested your script to check to see if it will launch the Mail app automatically, if it doesn't do this then you'll need to write some code to first launch Mail, wait until it fully launches, and then tell it to do stuff.

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

No problem! :-)