Once again, allow me to apologize for so doggedly disturbing everyone's day with discussions of cooperation with limited trust. However, David Reed's correct observation that "XXXXXX" leaves me terribly aware that, in the absence of a little more shared perspective on security requirements, the upcoming presentation by Mark Miller and myself will take place in a vacuum where the quality of our suggestions cannot be assessed. Anyone who wants to escape from this thread, let me know, and I will construct a new mailing list that excludes you. Below is a draft list of security requirements that seem reasonable to me for Croquet. This is not a proper requirements document. It drills down into architecture from time to time, where the requirements make certain architectural choices likely. It also wanders into philosophies of security. The goal is not a pure requirements document. Rather, the goal is to establish some basis of mutual understanding, or perhaps to establish the areas of clear disageement. Some of requirements are also "anti-security" requirements. I.e., these are requirements imposed by Croquet usability goals (and other goals). The anti-security requirements allow us, I believe, to quickly reject many traditional security mechanisms. Security Requirements Suggestions -- Security needs to be largely invisible. The Diablo trading system, referred to earlier points the way (as do a couple of the demos we will present). Humanity has had to tolerate obtuse in-your-face security far too long already. -- Passwords should be excoriated. This is a straightforward derivative requirement of invisible security. Human beings have terrible trouble with passwords. The usability goals of Croquet would seem to demand their elimination. The security toolset should make it easier to implement password-free security, than to implement passwords. -- An architectural choice that is hard to avoid, given these requirements, is to eschew ID authentication-based security in favor of authorization-based security. Ask not, "who are you?" Ask rather, "Are you allowed?" This is comparable to transitioning from using a driver's license to using a car key. Imagine a world in which the car demands your driver's license to match the car's certificate of title, and you have a world sadly similar to the one we have today on our computers. Fortunately, in the physical world cars do not care who you are, they only care that you have the authorization. A poignant demonstration of the risks of ID-based security can be found today by entering any airport. My own sense is that individuals often seem to prefer authorization based security. Centralized organizations often seem to prefer ID-based security. Which brings us to the next point: -- Centralized management systems are unacceptable. Croquet should not depend on Verisign certificates. There should not be a (shudder) Croquet Central Certificate Authority. -- A related point is, there should be no global namespaces. The current dispute over ownership of the ".iq" domain space should be enough said. Croquet should strongly minimize its dependence on the DNS global namespace system, though this is so ubiquitous, it may not be possible or desireable to escape from it entirely. You can read about an alternative, Pet Names, at http://www.erights.org/elib/capability/pnml.html for a simple, general-purpose approach to naming. We will demo such pet names at the meeting. I have now implemented pet name systems with diverse technologies, even ACLs, so I do not believe it is prejudicial to suggest this as a good idea no matter what other security technologies Croquet elects for deployment. -- Security must impose minimal overhead on performance, above and beyond the performance penalty for choosing an object-oriented language with such practical features as garbage collection. (implementation note: since the performance penalty for OO has already been accepted by the Croquet team, you're already almost there. The main additional thing that needs to be done is to avoid screwing up the security inherent in object-oriented systems. One needs to eschew non-OO touches like global variables and ambient authorities. Ambient authorities may seem convenient...until you have to deal with either security or reliability, both of which are placed at risk). -- The security toolkit should be well integrated with the gui toolkit: the gui toolkit should encourage good security implementation, and the security toolkit should encourage good user interface implementation. As a part of this, the gui toolkit should easily enable securing the widgets. So, for example, conveying authority to edit a single window pane should not by default be a conveyance of the authority to edit the entire window frame, much less the entire display screen and the file system. This is a simple application of the Principle of Least Authority (POLA). This may seem a trivial detail to present as an example, but it has interesting implications. This little bit of "polarization" is central to enabling the construction of objects that have all the power and utility of ActiveX controls without the egregious security side effects so common in Internet Explorer. Let us go in the other direction, making the security tools support user interface. We have a growing body of strong demonstrations for a key architectural concept for usable security: combine the authority to operate on an object with the designation of that object. This philosophy is demonstrated quite nicely by the Diablo escrow agent (and our CapDesk demo). Consequently, a good candidate feature of the security system is that it bundle authority with designation, since having this principle directly embedded in the security system aids the gui writer to easily create user interfaces wherein the security disappears from view. -- Do not prohibit what you cannot prevent. This is not exactly a requirement. Rather, this a heuristic I would propose for the Croquet team. We have found it to be a useful tool for thought. Attempts to prohibit what you cannot prevent often leave the user confused about his real risks when making trust decisions. We often find it clarifying to take this to the extreme, to "embrace what you cannot prevent". This extreme form ensures that the true risks are exposed while enabling any positive functionality that prohibition might constrain. An amusing example of this principle is the periodic re-emergence of the concept "security by obfuscation": make it so hard to understand the code that no one can figure out how to crack it. Open source is a good example of embracing what you cannot prevent: if your system gets popular enough, someone will reverse engineer it anyway, you might as well give the good guys an equal opportunity to crack it as the bad guys. -- Croquet should embrace delegation. Traditional security thinking often attacks delegation as an easy target for prohibition. However, people have been doing delegation for millennia. You can't prevent it, it is crucial to our normal interactions, and we are actually quite good at it (though both news media and famous literature focus on situations where people make catastrophic delegation decisions -- it makes a better story). Sit back, relax, and enjoy the ride. (note: pure simple delegation is not always appropriate in a corporate setting. However, in communities of individuals like Croquet, I do not see a reason for complicating this perspective). -- Croquet should support, easily and naturally, "polarized chain delegation". One of the reasons people sometimes fear delegation is that, on computers, delegation too often means conveying whopping big authories (like giving someone your password). To be effective, it must be easy for each successive act of delegation to also be a further act of authority minimization. So Alice gives Bob a panel of her window, Bob gives Carol a subpanel of his panel, and Carol gives Ted just the authority to attach an observer to one widget in her subpanel. -- Defense in depth rather than perimeter security. I like to refer to traditional "perimeter security" with the rather more pejorative term (which I also think is more correct) "eggshell security": stick a tiny pinhole in the shell and you can suck out the entire yolk. "Defense in depth" is of course a "motherhood and apple pie" concept. The heart of the issue is making it natural and easy. We have found that, using the right security paradigm, defense in depth is often an emergent property of clean OO design. In this way, the security can, at many times and in many places, disappear into the background not only for the end user but also for the programmer. This seems an attractive approach. Well, too much said. What objections have I stimulated? --marcs