<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I guess we all agree. This started with me hypothesizing that the
client-side API checks had something to do with security -- an
hypothesis that is all but solid! Stefan offered another explanation
having to do with minimizing round trips by catching errors at the
client. Who knows why they did it... (does anybody know for sure why
they did this? people in the architecture working group?)<br>
<br>
But it does introduce a strong contract between the client and the
server wrt the code that is allowed to run, and such contract is a bit
puzzling at this time. In other words, I wish it had something to do
with security! :-)<br>
<br>
dr scofield wrote:
<blockquote cite="mid:48DE329B.2070803@xyzzyxyzzy.net" type="cite">
<pre wrap="">John Ward wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dr Scofield wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Diva Canto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Seriously, my group here has been experimenting with all sorts of
completely different clients to get/post all sorts of different things
from/into the world. Once the Http server was made accessible to region
modules, there's no limit to what can be done, really... But for this to
scale beyond experimentation, we need to figure out trust.
</pre>
</blockquote>
<pre wrap="">no. we need to have clear protocol specs and our grids need to be coded in such
a way that they guard themselves.
trust comes in at much higher level (for example, do i trust that grid to adhere
to the licenses i attach to my objects?). trust should never replace caution and
self-defense.
</pre>
</blockquote>
<pre wrap="">Trust is the inseparable heart of any permissions based system. One
needs ways to establish trust to set appropriate permissions at what
ever level they come up. One might have their system codified to
control all actions, but that's often not the case or necessarily the
goal. If I want someone to participate I may have to allow them
potentially negative actions to participate. Sometime you can't code
around that. Without some tools for building trust I will likely need
to caution and defend others from participation. Trust can be a more
powerful tool then caution and defense.
</pre>
</blockquote>
<pre wrap=""><!---->i'm not arguing against trust. the discussion started with the
observation that 1.21 series clients do client side vetting of scripts
--- and then we got into discussing whether an explicit trust
relationship would somehow help.
my points are:
* to build a robust internet connected system we cannot assume
benign clients (even if they present a certificate), we have to
build our servers such that they are able to defend themselves;
for example, assuming (and relying on that assumption) that the
client is only going to present vetted code to me as a server, is
very bad design
* trust relationships come in at a different level; for example, at
the permission level.
dr scofield
</pre>
</blockquote>
<br>
</body>
</html>