Freigeben über

Castle and HomeGroup: A study in the evolution of user needs

  • Artikel

Several years ago, at the beginning of the “Longhorn” project (which eventually became Windows Vista), I worked on a project that was attempting to solve the problem of how to make file sharing in small networks (particularly at home) both simple and secure – something that, frankly, Windows has been working for a long time.

I worked with a small team of architects from across Windows to develop a technical concept that was eventually codenamed Castle†. Castle eventually became a fairly major project in Longhorn. Details of this project have trickled over the years, but since it never shipped in any usable form, it’s not widely known or understood, though some have tried to figure it out.

The Castle idea

Castle was based on the idea of creating a small network (typically in a home environment) with a shared concept of user accounts. In typical home networks, the main gating factor in a simple, secure sharing model is that the PCs each have their own idea of the users – a user on one PC doesn’t even “exist” on the other PCs. Earlier versions of Windows have approached this by having a password-based sharing model (the user create a password, and tells it to other people who want to get stuff from their PC), or having a completely open sharing model (put something in a particular folder, and anyone on your local network can get to it).

With Castle, the user accounts were shared with all PCs, with changes made to the user account information on one PC replicated to the other PCs automatically. A user on one PC could share pictures with the other members, and, using standard permissions model, make decisions about who could see what. Any single user could also log on on any of the other PCs using their own account (with replicated settings, of course). The advantage of this model from a technical perspective was that it would take advantage of all of the security and file sharing features that users in a corporate domain have used for years.

The interesting* thing about Castle, however, was that it was built around a model of home networks that assumed that, for the most part, home PCs were shared by users in the home. At the time (early 2002), home networks were uncommon, but were growing in usage, but typically, they were an extension of the home PC – two or three PCs shared by the users of the home, occasionally with one or more them primarily used by one person.

On HomeGroup

Contrast the model of Castle with this description of observations from the HomeGroup post on the Engineering 7 blog:

A majority of the computers in our panel only had one primary user. While we all know that laptop sales have overtaken desktop sales in the last couple of years, this data tells us that people are buying PCs more for specific people rather than for a shared location [emphasis mine].

HomeGroup is solving the same things that Castle was trying to solve – simple and secure sharing of documents, media and devices. But, this simple shift in the dynamics of home networks from shared PCs to single-owner PCs suggests a change in the solution. Instead of attempting to create a shared concept of user accounts, HomeGroup assumes a network of “equals and peers”, and uses the concept of a single shared password (a well-chosen analogy in the E7 blog compares this to the concept of the front-door key in a home) to build a trust relationship between the home PCs on top of which the media sharing, libraries and search features are layered.

Evolution of ideas

Some have postulated that HomeGroup is basically dusting off and shipping Castle. I’m not part of the team building HomeGroup (nor was I part of the Castle team at the end – I had switched focus to Wireless and Bluetooth projects and handed off the project to another team), but the Castle project ultimately died as a victim of the Longhorn reset in 2004 – at its height, it had grown to be a joint project of at least four different Windows teams. Like HomeGroup and its integration with Win7 technologies, Castle had pieces that depended on WinFS and other Longhorn technologies that never shipped in any form. It’s highly unlikely, given the different fundamental directions of Castle and HomeGroup, that they share any code.

In a world of single-owner PCs, Castle would, frankly have been overkill. If Castle had existed, the current HomeGroup concept could have been built on the base framework, but instead, like much of Windows 7, HomeGroup is a simpler, easier-to-use solution to the same fundamental problem Castle was trying to solve. HomeGroup was most likely built from scratch and integrated with other Windows 7 concepts and technologies (NLA, Libraries, Media Player sharing).

What the Castle and HomeGroup projects ultimately did share was the desire to make home sharing simple and secure‡ that Windows teams have been trying to solve for years. I don’t have enough PCs with Win7 at home yet to fully try out the HomeGroup feature, but from everything I’ve seen, the team seems to have delivered a simple and effective solution to the problem we set out to solve over six years ago.

Windows 7 seems to be, yet again, living up to the promise of Windows Vista.

/fin..

† On naming:  One early set of notes I still have that was written by one of the technical architects, Richard Ward (currently a Microsoft Distinguished Engineer in the Windows Core Architecture group), used the term “Minidomain.” I toyed with the codename “dominion” -- a play on “mini domain” – but it didn’t really catch on. The idea for the final codename originated with Andrew Sinclair, the GPM of my team at the time (currently General Manager of Hosted Exchange) and one of the inventors of the Castle concept, who opined, in his typically British way, during brainstorming, “A man’s home is his castle.”

I wrote most of the early scenario documents related to the project (used to flesh out and sell the concept), which made it easy for me to be the one to choose the codename. I latched onto the word “castle” from Andrew’s quip, which worked since it had the same medieval echoes of its technological ancestor, the Windows Server domain (a domain is a Windows enterprise concept of centrally administrated network systems). It was also a perfect analogy for what we were trying to build – a wall of protection around a set of PCs.

As a side note, we did spend quite a bit of time brainstorming with marketing about a branded name to use in the product. I had a moment of panic when, in one of these meetings, the marketing team got quite excited when I jokingly tossed out the name “workgroup .net” – the term “.net” was making the rounds in the company as the popular term to add to things, and Castle was, as HomeGroup is, an evolution of the long-existing idea of a workgroup. I think we can all breathe a sigh of relief that the “.net” fad has run its course.

* There were plenty of interesting things about Castle, for what it’s worth. Castle was, as was typical of Longhorn-era projects, quite ambitious. In my first scenario documents that I used to popularize the idea around the company, I had designs not only for simple and secure file sharing (the primary goal), but also for ways to potentially revolutionize concepts like application installs (install an app on one PC, and, via the secure mechanisms we were developing, we could replicate the application and its settings to the same user account on all of the PCs in the home, making it easy, as a user to move from one PC to another – obviously this would have required changes to the way apps were licensed, but we had a number of ideas for how to, for example, allow a user to use the app on only one PC at a time). I talked with the Windows Update team about using the Castle framework to distribute patches within the home after one system downloads them (patch distribution has be done via a secure distribution because systems basically install them automatically, so if someone can insert bad code that would be a bad thing). I also spent some time with the media player DRM team on techniques to automatically license downloaded music to all PCs in the home. We didn’t really plan to ship all of this in Longhorn, but we wanted to to lay a foundation for building features and applications in future versions of Windows that could rely on a secure, trusted home network.

‡Simple and secure – I harp on this phrase, because it’s relatively straightforward to make home sharing simple, and other products have made strides in that direction. It’s also easy to make home sharing secure – just lock everything down :). It’s a real challenge to bridge both concepts.

Comments