Archive‎ > ‎


(see also 09-24, Friday which updates these - we should update this page to reflect that)

These are ideas about the relationships among security, UI, and API that would inform our work.

H1 - There will be no phishing - this is because once a site has been introduced, authentication to that site will be done "under the hood" in some way unphishable way TBD (e.g. a per-site password, knowledge of a secret cap, a client certificate, etc.). Note, however, that this does not defend initial introduction (the notion of "ceremony" from security protocols might be considered here - e.g. part of the "sign up for a bank account" ceremony includes introduction to the bank's website).

H2  - Applications must be componentised. If we want meaningful fine-grained access controls, we cannot have giant monolithic apps
that need access to everything. Consequences of this are manifold, but at least one slightly subtle one: components must be visible to users (or the perfect user cannot tell a componetised app from a monolithic one).

H3 - We need trusted path. For, at least, audit and revocation.

H4 - We need audit and revocation!

H5 - It is possible to build a trusted path that is an integral part of the client interface, as long as you're willing to spend some screen real-estate on this.  Such a trusted path can be the user's primary control point (they way they normally pick files, objects, etc., and in general interact with all the time).  Audit and revocation can be obvious-to-the-user, everyday features of the trusted path. The UI/UX can be pleasant an intuitive despite the integral use of a trusted path.  The problems of spoofing the trusted path, and generally confusing the user, can be addressed satisfactorily, even while supporting corner cases, such as (near) full-screen applications.

H6 - A trusted path, such as in H5, can be extended to include not just system abstractions, but application abstractions.  Hence, given a "current app instance", two trusted paths may be accessible, one to the system (and its view of the app bindings), and one to the app controller (and its view of bindings to app instances).  Such extended trusted paths have benefits to the UI/UX and to the user (pure speculation here).

H7 - It is possible to identify, enumerate, and track all *functional URLs* in a "Belay system", with URLs being the system-supported identifiers to objects and capabilities.  It is possible to do this in a way that is (a) compatible with the URLs being "just text" that can reside in any text, in any app, protocol, or data format, and (b) allows easy interoperation with non-Spindle systems, and their use of URLs, e.g., via email, or any other means of sharing text.  Doing this has great benefits (again, speculation).

Something we should decide early on: are remote capabilities just unguessable, or are they linked to a cryptographic key (I prefer the
latter, as mentioned recently)? This will lead to H5 :-)