WinFS Mailbox II


Hi Everyone! Before I disappear for the holidays, I thought I’d dig through our inbox, the blog, and newsgroup, and answer a few more questions.


Q: Chris asks, “While it’s good to have a common silo that all apps can easily use, it’s seems a bit risky. Wouldn’t some rogue app/spyware have an easier time getting to financial Quicken/Money data?
A: Even though all your data is in a single silo, all the data isn’t equally accessible. WinFS provides two data protection mechanisms. First, there is share-level security that controls access to your WinFS share. Second, there is item level security that supports NT compatible security descriptors. In order to access an item, the caller must be provisioned at the both share and the item. To manage this, WinFS will provide a rich API for security administration. Also in Vista there is the concept of “integrity level” for an application (Mandatory Integrity Control). Data can be configured to prevent lower integrity apps from accessing it. Simon (our security PM) will post more detailed description about this soon. 


It’s important to note that an application shouldn’t be using file format complexity as a primary security measure. For important information like bank account and credit card numbers, you could continue to store them in an encrypted and password-protected file. But, there’s no reason that this file couldn’t live in WinFS.


Applications may have some data they definitely want to lock away. WinFS, however, gives the application developer the opportunity to share the data he chooses to share. Today there is a good amount of information in a money file and not all of it necessarily needs to be private. For example, Money could have “payees” (i.e. someone you get a check from or write a check to) represented as WinFS contacts.


Q: Retla1 asks, “What’s the best way to get some data into WinFS?
A: This is a great question. After all, once you install WinFS, there isn’t that much to look at except an empty relational filesystem. 🙂 Thankfully, there are number of good ways to get data into your store. The first set of ways is to copy it in. Open up our awesome WinFS Shell Namespace Extension (in the Windows Explorer, click through My Computer->WinFS Stores->DefaultStore). Now just drag and drop some files in.


Or, if you prefer, use copy or xcopy. Our Win32 support is robust, so please try it out (note the Win32 path is a UNC path: “\\<machinename>\defaultstore\foo.doc”). You can also redirect your “My Documents” folder to your WinFS store. This would move that data into WinFS. Any application that respects Shell APIs will work fine. (If it doesn’t work, let us know.)


If you prefer, you can sync data into your store. Beta 1 came with some sample sync adapters. Open up StoreSpy (one of our unsupported tools) and import some stuff from Outlook. If you install WinFS on two computers, be sure to use Rave to share that data. 


Q: Lars asks, “Does WinFS look inside files (word, excel, pdf, etc.) like desktop search engines do?
A: Yes. When a file is stored in WinFS, its metadata will be extracted by type specific property handlers. Part of our Beta 2 work is to integrate this with the Windows Desktop Search handlers. The end result is that a Windows Desktop Search query will return WinFS and non-WinFS files. 


Q: Qearsa asked, “What about all the Shell improvements in Vista? How does WinFS fit into that?
A: Vista provides a rich user experience using indexing technology. By integrating into that technology and providing a Shell Namespace Extension, WinFS will provide this same experience to users. This means your Vista searches will have results from many stores including WinFS, NTFS and Outlook. In addition, WinFS will provide the opportunity for the new and compelling user experiences we discussed in earlier posts.  


Q: A few people asked, “Will Beta 1 run on 2003 or x64?
A: Nope, we’re not planning to re-release the Beta 1 to support any other platform. We’re currently evaluating what platforms our Beta 2 will support.


Q: A few people also asked, “Are there any new features in the Beta 1 refresh?
A: The re-release has the same functionality of the original, but runs on the RTM version of the .NET Framework 2.0.


Q: Timbu asks, “Desktop search applications already aggregate my data from different apps (like Outlook and Sharelook). Isn’t this ‘Unify’?
A: Desktop Search represents the first step in a truly unified store. While you can use desktop search to see different types of data from different silos in a result view, the data itself still resides in separate silos. This means it is hard to operate across all that data. For example, I can search for all my files that have “Shell Namespace Extension” and get a huge list of emails, docs, and other files. At this point, there are some operational limitations. For example, I can’t copy all that data and put it in a single folder or USB drive, burn it to CD, or even share it out. Desktop search is a great end user application, but it’s not a platform. WinFS is a platform with great programmer access through managed APIs targeting the unified and extensible data types.


One last question, but I need the answer from you: “What should I write about next?” I’ll like to start getting into more details and away from the high level stuff. 🙂 Please post some comments with suggestions and ideas.


Happy Holidays!


Author: Vijay Bangaru

Comments (10)

  1. Lynn says:

    Will server-based WinFS shares support synchronization similar to DFS?

    Is there any on going work with the IIS 7/asp.net team to provide solutions in that space?

    When will Beta 2 be released? 🙂 (Sorry, had to ask.)

  2. The Groker says:

    What will be the relationship between WinFS and WSS (Windows SharePoint Services) going forward?

  3. Myxiplx (mail me on hotmail.com) says:

    I think Chris raises a good point with that first question and I think it’s a shame that the recommended approach for secure data is to not store it in WinFS..

    I’d love to see WinFS expanded in the future to allow secure storage for applications that require it (and yes, I am aware that I’m asking for a new feature for a product that hasn’t even been released yet..)

    Now, I’m not a WinFS developer so I’ve really no idea if this is feasible, but I would have thought that it would be possible for the WinFS security model to be expanded, allowing permissions to be set per application as well as per user. All you need then is for applications and data files to be digitally signed and data could easily be secured. That would make the advantages of WinFS available to many more applications, and personally I would trust that security far more than any 3rd party encryption.

    An added bonus would be that this security would apply to more than just the data. The application files themselves could be protected in the same way. You’ve got guaranteed data and program integrity; nothing that hasn’t been properly signed can modify the program or it’s data, not even a virus.

  4. Johan S says:

    If I install WinFS is my whole filesystem going to be WinFS "enable" entirely of just a certain folder? Is the goal to have the entire filesystem WinFS (that is, everything from Windows System files to application program files to be in WinFS)?

  5. mabster says:

    I have a question about portability of WinFS data.

    If I open an application like Word, and type up a document, I can save that document onto a USB key, take it home and keep working on it.

    How does this scenario play out in WinFS? Can I have WinFS stores on removable storage devices?

    I ask because I have a hobby project which works as a file-based application. It can File|Open and File|Save its data as single files, which users often carry from PC to PC. If I were to port this app to WinFS, how would a user pick up his data from one machine and take it to another (assuming they’re not connected – I’ve read about Rave etc)?

    Cheers,
    Matt

  6. Lyle Kopnicky says:

    Where can I get more details about the security model of WinFS?  Does it follow the route of the capability security model, or is it based totally on ACLs?

    If it is based on ACLs, then any software that executes with my privileges can do anything to any item I have permission to access.  Not good.  This is what allows viruses to propagate, spyware to operate, etc.

    If it is based on capabilities, this gives more fine-grained control, so that a program can only have the permissions I give it.

  7. Dave Bacher says:

    It would be nice to see security two steps beyond the current NT permission level on NTFS.

    Step 1:  Application Group

    It is likely that Money and Quicken are both using proprietary file formats for their data.  It is likely that an end user doesn’t care about this.  With WinFS, Money and Quicken could easily create a table that the other program could easily read.

    The issue is you don’t want some spyware program that isn’t a member of the application group to access these tables.  It would be relatively simple to provide a group (or groups) for applications, exactly how NT/XP handles groups of users now, and to restrict access to tables, rows or columns based on that group.

    Similarly, you could forbid "Internet Applications" from accessing "Financial Data" group files, in the process blocking any vulnerability in the web browser, e-mail, etc. from exposing the data from these files.

    Step 2: Individual Application

    Continuing, an individual application should be able to write data, and tag that data as only being available to it, or to selected other applications.

    Both of these would work exactly as the user group security features do – you would assign a SID to the Application Group or Application, thus allowing it to participate (with no changes) in operating system DACL-based security.  

    This would help a lot in preventing attacks, especially when combined with other factors.

    Note that the recommended approach (encrypting data) only works in the presence of an external factor such as a smart card.  Even a password based approach is insufficient to adequately protect data from attackers.

    The reason I am suggesting this change is that the only thing that is going to kill spyware is to start making it harder to install in the first place.  

    Consider an trojan attempting to e-mail your contact list.  If the trojan is running in the "unassigned applications" application group, it can’t get to your contact book, then it is contained and cannot spread.

    I would love to see CoCreateObject(Ex) check a DACL also, and to have it follow these same rules in order to cut it off from the world.

  8. CodeTyro says:

    I’d like you to write about the transitioning (promotion/demotion – is that the terminology) of alternate data streams in NTFS, to Items; and about the Item extensions.

    I guess I’m seeing these as an evolution of metadata in pre-WinFS file system storage and maintenance (everything up to Windows 2003 Server and Windows XP SP2), to whatever OS’s we will have in 2007 onwards that will run with a superimposed WinFS layer.

    As a part of readiness, what I would like to see is how to build an iFilter to search for text within an ADS (a named one, presumably).

    Ian Thomas (gxdata@iinet.net.au)