media1mogul
I put these notes together over the past week or so and I want to post them here in case they help someone else.  I make no claims that this is the only or the best way to handle this, but it works for me.  

The environment:
() Windows 7 X64

The problem:
() I travel with my PC. It is possible that the PC may be stolen or forgotten on a plane, etc. If this occurs I do not want the privacy of company or personal data to be compromised.

The Solution:
() I use Symantec Encryption Desktop. I create PGP disks that can then be mounted as sub-directories or as virtual hard drives.  I mostly mount them as subdirectories.  (I choose not to use full disk encryption based on early negative experiences with it.)

The problem for theBrain
() The brain is stored in an encrypted directory.
() The brain uses the Windows indexing service as it's search service.  If the indexing service database is not encrypted, you've got data leakage.

The solution:
I chose to move the windows index to a RAM drive. I chose to recreate the RAM drive and the index at each boot of my PC.

What follows may be somewhat specific to my environment.  There were some behaviors that I encountered with respect to the indexing service that might not be encountered on someone else's machine.

This requires your user has admin rights on the machine.


Preparation:
() Create the RAM disk that will hold the index and mount it.  Mine is mounted to
C:\Users\XXXX\Documents\ENCRYPTED\indexed. It is setup to mount on startup.
- Ignore that the word encrypted is in the path. It was an arbitrary choice by me.
- A RAM disk will be mounted at the directory "indexed", not a PGP drive. 

() in Explorer, create a new library. I called it "notebooks". Add to that library the mounted encrypted director where your brain data lives. Mine is:
C:\Users\XXXX\Documents\ENCRYPTED\my_documents\Notebooks
-This was one of the first places I hit a quirk.  Windows indexer won't normally index directories that are mounted as subdirectories. 
-The cleanest workaround I saw on the web was this one; add a library, then add the mounted directory to the library.

() Bring up windows "indexing options" and click modify and select the "Notebooks" library as an indexed location.

() Bring up windows "indexing options" and under advanced,  set the "New location after the service is restarted" to
C:\Users\XXXX\Documents\ENCRYPTED\indexed
- I hit another potential quirk here though I haven't fully explored it.
- I believe I saw behavior (and saw it mentioned in a forum) that for some reason that if windows restarts the indexing service and the new directory is not empty, it will revert to the default index database location.  I'm not 100% sure I saw this behavior or not, but by that point I was going down the road of a RAM drive so I didn't care to spend more time on it.


This is where the really quirky behavior began on my machine with respect to the indexing service. 

First , to summarize where we are now:
() The RAM drive is created and mounted.
() The new library that points to the root of the brain location is created.
() That new library is added to the indexing service.
() The index has been pointed to the new RAM drive location.

The next thing that has to be done is to make sure that things start up in the following order:
() Machine boots.
() the brain directories are mounted.
() the RAMdrive is mounted.
() The indexing service is started.

What I found was that even if I disabled the indexing service something re-enabled and started it very soon after windows started, and the index would drop back to the default location.

Here is the startup sequence to avoid this.
================
Mount the PGP encrypted subdirectories - This is an interactive process via a GUI
-----------------------------

================
Mount the RAM drive where the indexes will be created.
-----------------------------
REM Create the RAM disk
imdisk -a -s 1G -p "/fs:ntfs /q /y"

REM Mount it to the index location I selected.

C:\bin\util\small\junc C:\Users\XXXX\Documents\ENCRYPTED\indexed \Device\ImDisk0\

================
Start the indexing service.
-----------------------------
REM Set the service to run as the special localsystem user. It won't run correctly otherwise.

sc config WSEARCH obj= .\LocalSystem
sc config WSEARCH start= auto

REM 
Start the service
sc start "WSearch"

REM Once the service is started, disable it, and make sure it stays disabled for the next reboot.
REM Here .\XXXX is the name of a local account on the machine that has user privileges.
timeout /t 10
sc config WSEARCH start= disabled
sc config WSEARCH obj= .\XXXX


So what happened?

At this point, the service is started but is also disabled.  When the system is next rebooted it will be "magically" changed to "auto" from disabled, but since the user is not .\LocalSystem the service will not be able to start until the commands above execute ad admin priviledge.

I found that whatever process is starting the service is able to re-enable it, and then start it, but it is not smart enough to change the user.

That's it.
It's been working pretty good for me so far.
One caveat is that I do not have an enormous brain as of yet.

References:

Mike
Memory on Paper
Quote
mcaton
Mike,

Thank you for the detailed search testing in your environment.  I'll be sure to share this thread with the development team for further review.

Thanks,
Matt
Quote

Newsletter Signup  Newsletter        Visit TheBrain Blog   Blog       Follow us on Twitter   Twitter       Like Us on Facebook   Facebook         Watch Us on Youtube  YouTube       

TheBrain Mind Map & Mindmapping Software     Download TheBrain Mind Mapping Software