Future research topics

From Erights

• Develop a translator from E to some formalism that's good for reasoning about authority, such as SCOLL or perhaps an appropriate process algebra. This would have obvious connections to language design and translation, as well as some mathematical / formal analysis leanings. One might even be able to consider this in the context of proof carrying code -- E modules carrying proofs about their security properties would be an interesting thing indeed.

• Investigate the connection between E and the work on using type systems to enforce capability security ala "lightweight static capabilities".

• Take up the CapDesk mantle and build a robust POLA desktop on top of E, using available tools such as Plash or other permission-limiting application environments in order to allow the integration of legacy applications. This would likely also include looking at how existing application launching and packaging frameworks can be leveraged (such as the XML .desktop files used by GNOME for example)

• Complete the E-Native work, which would result in an E runtime environment that isn't layered on top of another runtime environment (e.g., JR, Lisp, Squeak). Unique Research Contributions:
  • Develop a VM (OCVM?) that embodies object capability semantics
  • Implement the OCVM in a verifiable language (e.g., BitC)
  • Develop the Kernel-E AST to OCVM compiler
  • Develop a (verifiable?) native implementation of CapTP (although the current implementation of CapTP in Java will probably be replaced soon with one written in E)

• Re-implement COUGAAR [1] in E to show how object-capability security and promises can be used to simplify and secure distributed, concurrent agent planning systems. Unique Research Contributions:
  • Intrinsically secure distributed agent system
  • Early (first?) large-scale E (object capability) application
  • Worked example of applying object capability patterns to the design of a large distributed system

• EBASS (E-Based Application Server System). Develop an E application server framework (like J2EE or the CORBA Component Model) that provides an infrastructure for deploying general-purpose E services, while orthogonally managing and enforcing organization security policies using object capability patterns. Unique Research Contributions:
  • Intrinsically secure application server system
  • Early (first?) large-scale E (object capability) application
  • Worked example of applying object capability patterns to the design of a large distributed system

• Invent a way to securely re-use native code libraries in E applications or perhaps Emily. Details can be found in [2], [3], [4] and [5].

• Implement a version of Second Life that works in a more distributed manner. Instead of relying on just centralized servers, spread the processing and storage of objects to all the end-user machines instead.

• Implement a content management system - like ZOPE - in E. This would be especially true if E moves to using Tyler Close's HTTPSY protocol beneath CapTP, since it would then be directly usable by standard web browsers.

• Expanding CapDesk to become a generalized secure rich client platform (CapClient?) would be a tremendous development. Combined with EBASS, we would then have the ability to create end-to-end secure applications.

• Auditing [6]. Note that the E-on-CL auditing system is quite different from the one documented here, with interesting advantages and disadvantages. The current E-on-Java is slowly working towards yet another take on an auditing architecture, but it's much less far along. Joe-E special cases some built-in auditors, but we've talked about generalizing it to an openly extensible static auditing framework. During the Waterken security review, we found that around 25% of the classes in the Waterken system were Powerless. In other words, they had passed the Joe-E static checker assuring that they were authority-free. As a result, we were able to ignore these regarding many security-relevant questions during the review. This demonstrates that the auditing idea has a lot of value.

• Safe Serialization Under Mutual Suspicion [7]. The issues involved in serializing a graph of mutually suspicious objects is otherwise unexplored. At these pages, I think we raise more questions than we answer. The need for a good serialization framework meeting these goals seems to come up over and over again in different contexts. The notion (due to Jonathan Rees) of serialization as un-evaluations seems like a very rich starting point. In a recent conversation with Alan Karp and Marc Stiegler, we arrived at a new perspective on un-evaluation. At one simple extreme, we have the literal realism of orthogonal persistence, where objects simply get to keep whatever rights they acquired. We assume that a held permission can only be acquired "legitimately", so the holding of a permission is an adequate demonstration of a the right to continue holding that permission. At a hypothetical simple opposite extreme approximated by SPKI, the entire delegation chain by which a permission was actually acquired is recorded, and is presented afresh each time the permission is exercised, effectively as a chain of title (sharings, not transfers), enabling a fresh check each time that the permission was acquired legitimately. When these two give extremes always give the same answer, the difference is uninteresting. However, if the "rules" change, the first "historyless" system can only grandfather-in all permissions acquired so far by the old rules. OTOH, the SPKI-like system can determine whether to accept as legitimate, under the new rules, the means by which the permissions were acquired under the old. (Note: in general, and especially in the human world, I generally prefer historyless rights systems over retro-active re-evaluations. But both have a place.) Un-evaluation is a complex expressive mid-point between these two. In order for the object to retain its rights across a serialization boundary, i.e., to reconstitute an object like itself with permissions like those it currently holds, it must be able to construct from its current state a rationalization (the uncall), i.e., a simplified story about how it could have gotten these permissions. In the world in which this expression is evaluated, it may or may not succeed at re-obtaining permissions like those it held.

• Decision Alignment (see [8]).

• Solve upgrade and legacy compatibility issues (see [9]).

• Continue the work of Alfred Spiessens on formal systems for reasoning about authority propagation and practical tools using them. This work would continue his thesis work: [10].

• Alfred Spiessens' point 2 on page 282 of his thesis.

• Investigate possible enhancement to set of E asynchronous control flow operators Proposed Asynchronous Control Flow Operators

• Does EQ add to the expressiveness of an object-capability system.

• Actually building Capability-based_Active_Invocation_Certificates and evaluating it compared to SPKI, Macaroons, and CapTP. Adapting CapCert to Ethereum-like blockchain scenarios, where many of the entities (e.g. Ethereum contracts) cannot keep secrets -- not even their own private signing key.