FYI: Documentation of specific folders removed from Default Green List in change set 1909

Jun 7, 2007 at 3:11 AM
The checkin notes for Change Set 1909 in the Source Code indicate the following:

"fix for 8447 - Some folders on Default Green List can not be encrypted because System attribute is set. Removed folders from Default Green List."

However, the specific folders eliminated have never been documented. I have diff'd the source code to determine which folders were eliminated, so that organizations wishing to encrypt these folders know which ones were intended:
  • Environment.GetFolderPath(Environment.SpecialFolder.Cookies) aka %userprofile%\Cookies\
  • IE6's WinInet UserData aka %userprofile%\UserData\
  • IE6's Outlook Express Address Book aka %userprofile%\Local Settings\Application Data\Microsoft\Address Book\
  • IE7's WinInet UserData aka %userprofile%\Application Data\Microsoft\Internet Explorer\UserData
  • IE7's Outlook Express Address Book aka %userprofile%\Contacts

Strangely, the EFS Assistant originally was coded to remove the System attribute from the Cookies and UserData folders - so there shouldn't have been any trouble trying to encrypt these folders once the System attribute was removed. Huh?
Jun 10, 2007 at 6:02 PM
A decision was made that, for safety's sake, we would not scan into folders with the system bit set. Therefore, because the system bit was set above the folders in question, they would never be scanned, and therefore need not be on the green list. Because of this, we removed them from the default green list so users would not get the impression they were being encrypted.

This is documented in Chapter 2 of the EFS Administrator's Guide.
Jun 10, 2007 at 11:49 PM
However, there are a couple of folders from which the tool removes the system bit, then scans into those folders and generally encrypts them. These folders are altered by the RemoveSystemAttributes() method:
  • IE7 Feeds cache
  • IE Temporary Internet Files cache

It's great that these were left in the tool. Was there any particular reason that these were left in - were they deemed "safer" than the other folders (Cookies, UserData) that were removed from the RemoveSystemAttributes() method?
Jun 11, 2007 at 8:57 PM
These folders were left in because they existed outside the %userprofile%. This folder was marked with the system bit, and we felt uncomfortable about resetting the system bit on this folder.

We would have liked to encrypt more folders (as in the original design), but we felt that better safe than sorry was a good rule of thumb. If an organization wants more folders encrypted, the tool can easily be modified.