Labs/Ubiquity/0.2 Design: UI and Security Extensibility: Difference between revisions
(replaced "limited" w/ "restricted" to tie-in example w/ diagram) |
m (Added breadcrumb) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Back to [[Labs/Ubiquity]]. | |||
== Introduction == | == Introduction == | ||
| Line 8: | Line 10: | ||
The implementation of (1) will involve providing a well-documented API for external UIs to plug into. The implementation of (2) will involve providing a "feed plugin" mechanism through which new types of Ubiquity feeds can be created that use entirely different security models than Ubiquity's default. | The implementation of (1) will involve providing a well-documented API for external UIs to plug into. The implementation of (2) will involve providing a "feed plugin" mechanism through which new types of Ubiquity feeds can be created that use entirely different security models than Ubiquity's default. | ||
Both of these solutions invite | Both of these solutions invite anyone to create and implement new ideas to further the conversation about using the browser to connect web services together in a safe, humane way. | ||
Before reading the rest of this document, it may be helpful for readers to understand the [[Labs/Ubiquity/Ubiquity_0.1.3_Architecture|Ubiquity 0.1.3 Architecture]]. | Before reading the rest of this document, it may be helpful for readers to understand the [[Labs/Ubiquity/Ubiquity_0.1.3_Architecture|Ubiquity 0.1.3 Architecture]]. | ||
| Line 16: | Line 18: | ||
Below is the proposed architectural diagram for 0.2. Its individual parts are explained in the following sections of this document. | Below is the proposed architectural diagram for 0.2. Its individual parts are explained in the following sections of this document. | ||
[[Image:Ubiquity_0. | [[Image:Ubiquity_0.2_Architecture_Proposal_3.png]] | ||
== UI Extensibility == | == UI Extensibility == | ||
All UI components will interact with the '''UI Manager''' depicted in the proposed architectural diagram, which essentially serves as a [http://en.wikipedia.org/wiki/Facade_pattern facade] to Ubiquity's functionality. | All UI components will interact with the '''UI Manager''' depicted in the proposed architectural diagram, which essentially serves as a [http://en.wikipedia.org/wiki/Facade_pattern facade] to Ubiquity's functionality. | ||
An example third-party client of the UI Manager API would be Aza's [http://azarask.in/verbs/mouse/ Experimental Mouse-Based Ubiquity] feed. | |||
Given a selection, clients of the UI Manager should be able to: | Given a selection, clients of the UI Manager should be able to: | ||
| Line 54: | Line 58: | ||
== Security Extensibility == | == Security Extensibility == | ||
The main idea here is to decouple Ubiquity's user interface from its implementation so that it's easier to experiment with more secure implementations. | The main idea here is to decouple the security-related portion of Ubiquity's user interface and execution model from its implementation so that it's easier to experiment with more secure implementations. | ||
In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <tt><nowiki><HEAD></nowiki></tt> element of an HTML document: | In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <tt><nowiki><HEAD></nowiki></tt> element of an HTML document: | ||
| Line 70: | Line 74: | ||
Requirement (1) will provide Feed Plugins with the freedom to implement whatever security model they need, while requirements (2) and (3) will give them the ability to present that model to the end-user in an understandable way. | Requirement (1) will provide Feed Plugins with the freedom to implement whatever security model they need, while requirements (2) and (3) will give them the ability to present that model to the end-user in an understandable way. | ||
Ubiquity 0.2 will contain | Ubiquity 0.2 will contain two built-in Feed Plugins: | ||
* The '''Default Command Feed Plugin''' encapsulates Ubiquity 0.1's implementation for command feeds, which assumes that all subscribed-to command feeds are trusted and gives them full control over the end-user's system; it also warns the user when they attempt to subscribe to a feed that's served by an untrusted host or is sent over an insecure connection. | |||
* The '''Locked-Down Command Feed Plugin''' is a trivial proof-of-concept Feed Plugin that can be used to create simple commands that operate on plaintext and don't use the network, such as "uppercase". While completely secure, it's also extremely restrictive. | |||
The aim of 0.2 is to provide the infrastructure and tools for new, secure yet flexible Feed Plugins to arise that will eventually replace the default. | |||
Possibilities for Feed Plugins include: | Possibilities for Feed Plugins include: | ||
Latest revision as of 01:30, 17 February 2009
Back to Labs/Ubiquity.
Introduction
As per the first Ubiquity planning meeting, our goals for 0.2 are to:
- make Ubiquity easier for experimental new UIs to leverage, and
- make Ubiquity more secure.
The implementation of (1) will involve providing a well-documented API for external UIs to plug into. The implementation of (2) will involve providing a "feed plugin" mechanism through which new types of Ubiquity feeds can be created that use entirely different security models than Ubiquity's default.
Both of these solutions invite anyone to create and implement new ideas to further the conversation about using the browser to connect web services together in a safe, humane way.
Before reading the rest of this document, it may be helpful for readers to understand the Ubiquity 0.1.3 Architecture.
Proposed Architecture
Below is the proposed architectural diagram for 0.2. Its individual parts are explained in the following sections of this document.
UI Extensibility
All UI components will interact with the UI Manager depicted in the proposed architectural diagram, which essentially serves as a facade to Ubiquity's functionality.
An example third-party client of the UI Manager API would be Aza's Experimental Mouse-Based Ubiquity feed.
Given a selection, clients of the UI Manager should be able to:
- Determine what commands are apropos to operate on it. For instance, if I select a street address, one of the first commands that it matches should be "map".
- Implementation note: Look at the CommandManager's noun-first-suggestions code.
- Get a list of all commands that can apply to the selection.
- Implementation note: Look at CommandSource's method to get all commands.
- Sort a list of commands by criteria such as quality of text match or frequency of use, or by combinations of such criteria.
- Implementation note: Sorting is currently done entirely inside the parser, but we can pull it out and expose the scores directly so that a new plugin UI can make its own decisions about how to sort.
Given a command, clients of the UI Manager should be able to:
- Figure out what arguments(nouns) the command takes. (Including: getting the names and types of all arguments, or of all arguments that have not been satisfied already by the selection)
- Implementation note: Once we unify Verbs and Commands, this will be trivial.
- Call the command (for a given assignment of argument values).
- Implementation note: see above.
- Retrieve the html of the command's preview (for a given assignment of argument values).
- Implementation note: see above.
Given a command argument, clients of the UI Manager should be able to:
- Get default value(s) for the argument
- Implementation note: Should be able to easily get this by querying the verb for the nountype of its arguments and then querying the nountype for default value
- Given an argument and a proposed value for that argument, find out whether the argument can accept the value or not; and if it can accept the value, get a list of possible completions for the value, including relative quality rankings of those completions.
- Implementation note: see above, with the caveat that relative quality rankings of noun suggestions barely exist yet and need a bunch of work independent of the UI extensibility work.
Security Extensibility
The main idea here is to decouple the security-related portion of Ubiquity's user interface and execution model from its implementation so that it's easier to experiment with more secure implementations.
In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <HEAD> element of an HTML document:
<LINK REL="commands" HREF="my_commands.js" TYPE="application/x-javascript" />
In Ubiquity 0.2, the values of the REL and TYPE attributes will be used to locate an appropriate Feed Plugin for the feed. Much of what happens next is delegated to that plugin.
Creating a new Feed Plugin has the following requirements:
- The Feed Plugin will be responsible for actually loading the feed and providing its functionality—generally in the form of commands and pageload functions—to Ubiquity using well-defined interfaces.
- The Feed Plugin will control the user experience from the moment they click the subscribe button in the notification box to subscribe to the feed, presenting any necessary information the user may need to know before subscribing (e.g., security warnings). It will also be responsible for communicating with the Feed Manager to actually subscribe to the feed, since it's possible that the user may ultimately choose not to subscribe.
- The Feed Plugin will have optional interface elements and information it can display on Ubiquity's feed management page (currently located on about:ubiquity).
Requirement (1) will provide Feed Plugins with the freedom to implement whatever security model they need, while requirements (2) and (3) will give them the ability to present that model to the end-user in an understandable way.
Ubiquity 0.2 will contain two built-in Feed Plugins:
- The Default Command Feed Plugin encapsulates Ubiquity 0.1's implementation for command feeds, which assumes that all subscribed-to command feeds are trusted and gives them full control over the end-user's system; it also warns the user when they attempt to subscribe to a feed that's served by an untrusted host or is sent over an insecure connection.
- The Locked-Down Command Feed Plugin is a trivial proof-of-concept Feed Plugin that can be used to create simple commands that operate on plaintext and don't use the network, such as "uppercase". While completely secure, it's also extremely restrictive.
The aim of 0.2 is to provide the infrastructure and tools for new, secure yet flexible Feed Plugins to arise that will eventually replace the default.
Possibilities for Feed Plugins include:
- Plugins that execute code in a sandbox with a restricted codebase principal and mediate the exchange of data between it and the rest of Firefox to minimize the adverse effects of a malicious feed. See A Security Model for Ubiquity for more details.
- Plugins that unify Ubiquity's UI with other pre-existing forms of web extensibility, like Bookmarklets and Greasemonkey scripts.
- It should also be possible for one Feed Plugin to wrap another, creating possibilities for middleware. For instance, a social web-of-trust style model could be layered on top of an object capabilities model, thus providing multiple layers of protection for end-users.