Labs/Ubiquity/TrustNetwork: Difference between revisions
Jump to navigation
Jump to search
(New page: == Motivation == Ubiquity needs a distributed trust mechanism. Although it may be possible to depend on a central repository (or a few repositories), a distributed solution would be a be...) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
Back to [[Labs/Ubiquity]]. | |||
== Motivation == | == Motivation == | ||
| Line 23: | Line 25: | ||
** ''Trust enhanced web pages'' - a set of links on a page, enhanced with trust meta-data, including: score, weight, optional version digest, optional signature. Links can be to commands or other trust sources. | ** ''Trust enhanced web pages'' - a set of links on a page, enhanced with trust meta-data, including: score, weight, optional version digest, optional signature. Links can be to commands or other trust sources. | ||
** ''Trust search engine'' - a web app with both a UI and a set of REST actions. The "search" REST action allows search for a specific command or command revision. The result is a path, with references to third parties involved in the path. | ** ''Trust search engine'' - a web app with both a UI and a set of REST actions. The "search" REST action allows search for a specific command or command revision. The result is a path, with references to third parties involved in the path. | ||
* ''Trust score'' - a combined score for a set of paths from the trust roots to the target command | * ''Trust score'' - a combined score for a set of paths from the trust roots to the target command. | ||
Notes: | Notes: | ||
Revision as of 23:33, 4 September 2008
Back to Labs/Ubiquity.
Motivation
Ubiquity needs a distributed trust mechanism. Although it may be possible to depend on a central repository (or a few repositories), a distributed solution would be a better fit.
- a distributed system can allow new high quality developers to quickly gain trust and be more visible to the end user
- trust can be delegated, so that it is easy to delegate code reviews and scale with the large number of expected commands
- we can move past the one-size-fits-all trust mechanism - end users can set their own trusted sources and trust criteria
- a trust search engine can be created to find commands based on required trust levels and keywords
Use cases
- A naive user encounters a new command and wishes to add it to Ubiquity. The command trust metric is calculated using the default Ubiquity trust roots and criteria.
- A corporate user adds corporate internal trust sources and adjusts trust criteria to give preference to internal sources.
- A sophisticated user adds their trusted developer friends to the trust roots.
- A risk averse user adjust trust criteria so that multiple reviews of a command are required to pass the threshold.
- A user searches a trust search engine for commands.
Proposed design
- Trust user agent - in this case, the Firefox Ubiquity extension.
- Trust roots - pointers to trust sources, with score and weight on each link. A default set is distributed with Ubiquity.
- Trust sources:
- Trust enhanced web pages - a set of links on a page, enhanced with trust meta-data, including: score, weight, optional version digest, optional signature. Links can be to commands or other trust sources.
- Trust search engine - a web app with both a UI and a set of REST actions. The "search" REST action allows search for a specific command or command revision. The result is a path, with references to third parties involved in the path.
- Trust score - a combined score for a set of paths from the trust roots to the target command.
Notes:
- A breadth first search from the trust roots will be performed, with either a depth limit or a time limit
- a low score indicates that the target is known to be low quality. A low weight indicates that the target quality is less known.
- Revision 0.1 Hyper 23:29, 4 September 2008 (UTC)