W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

Re: Extending Trust...

From: Mary Ellen Zurko <zurko@osf.org>
Date: Tue, 27 Jun 95 13:42:38 EDT
Message-Id: <9506271742.AA06723@link.osf.org>
To: sroussey@balboa.eng.uci.edu (Steven T. Roussey) (Steven T. Roussey)
Cc: www-talk@www10.w3.org, www-security@ns2.rutgers.edu (WWW security dist list), zurko@osf.org (Me)
Trust is usually associated with security; you might be
more/different/better/weirder feedback from www-security, so I've
replied there too.

In thinking about trust, I've found it useful to break the concept
down into two components; amount of trust, and trust for
what. Following your example, I would expect SuperWorriedParents to be
much better vetters of toy ads than software integrity. While it's
fairly easy to think of a variety of algorithms that might do
something useful with "amount of trust", figuring out the types of
"for what" is harder. You might start by answering "What will this be
used for?".

Also, it's often useful to explicitly separate the producer and
recommender functions. Some trustworthy recommenders don't produce
trustworthy product (critics), and some excellent producers don't
produce trustworthy recommendations. 

Finally, you really don't want trust chains to go on forever. In real
life, I really don't maintain high trust after 3 or 4 hops, unless I
have multiple corroborations (or until I have direct experience with
the farther off nodes).
	Mez

> 
> I have a request for comments about how best to extend a viewer's trust in
> me to other people. I feel this may become necessary do to undesired
> content and to possible unsafe code (programs or scripts to be executed on
> the client side).
> 
> I can imagine a scenario where the browser only allows limited access to
> documents or gives warnings about documents based on a chain of trust.
> Options would include access control, trust chain warnings, or no warning
> (current state of affairs).
> 
> For example, a browser could be configured to only allow access to a
> personal list of bookmarks digitally signed by the user.
> 
> Another layer of protection would be to have the server of a URL provide
> digital signatures from other agents, or query another agent as to whether
> it trusts the URL itself or the server in question. If the signatures
> extend trust to the URL then you can view it (or at least be warned
> otherwise). Other servers (or specific URL links) may be signed my the
> previous server and so a list of signatures could validate the URL. For
> example, a banner on the bottom of the screen may say "This 'PowerRangers'
> URL trusted by Edutainment Co. which is trusted by SuperWorriedParents
> which is trusted my you".
> 
> The above extension of trust does not have to apply to total access
> control. It could be applied selectively (e.g., to client side execution of
> shell scripts).
> 
> 
> Issues:
> How to design signature authorities that approve of sites based on some
> criteria.
> 
> How to digitally sign a URL.
> 
> Other?
> 
> 
> -steve-
> 
> Background:
> http://www.eng.uci.edu/~sroussey/NetVision/editorials/risk_reward_trust.html
> 
> PS  If this is not the right forum for this type of discussion, please
> point me in the right direction.
> 
> 
>                                         ---------------------------------------
>                                         |          Steven T. Roussey          |
>                                         |     mailto:sroussey@eng.uci.edu     |
>                                         |  http://www.eng.uci.edu/~sroussey/  |
>                                         ---------------------------------------
> 
> 
> 
Received on Tuesday, 27 June 1995 13:43:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT