[Auth]SEE daemon

[Norbert Bollow]

David,
  since there is a high level of renewed interest in moving the
SEE daemon forward, could you please post an introduction from
your perspective into this package... what has been implemented
already and what are the next steps?

BTW I'm including (below) a key message from our discussion of SEE
with Richard, which I believe has never been posted publicly so far.

Greetings, Norbert.

--snip------------------------------------------------------------
Date: Wed, 17 Oct 2001 11:51:00 +0200
Message-Id: <address@hidden>
From: Norbert Bollow <address@hidden>
Prefer-Language: de, en, fr
To: address@hidden
CC: address@hidden, address@hidden, address@hidden
In-reply-to: <address@hidden> (message from
        Richard Stallman on Tue, 16 Oct 2001 18:43:15 -0600 (MDT))
Subject: Re: A statement on portability in DotGNU
References: <address@hidden> <address@hidden 
>     > Let us be specific.  The only part of DotGNU that really must have a
>     > Windows counterpart is DotGNU SEE.
>
> Does having a "Windows counterpart" for DotGNU SEE mean making DotGNU
> SEE run on Windows (as well as on GNU and other systems)?  Or is it
> something different from that?
 
The easiest way to get what what we need will indeed be to
implement dotgnu-see in a reasonably portable way, so that we
won't need too much help from Windows programmers to make it
work well on Windows.  But it'll still not be trivial, because
it needs to be "end user friendly".
 
There are three important areas to consider here:
 
a)  In order for the "virtual identities" system to be useful
    for website owners, the client-side parts of it must work
    with the vast majority of desktop computers.  The current
    plans of the various project proposals for the "virtual
    identities" system all rely on executing code on the client
    computer.  This must happen either in the browser (which is
    unreliable and a bad long-term strategy as long as Microsoft
    has a lot of influence on what capabilities the browser
    provides, or doesn't provide) or in DotGNU SEE, our "Secure
    Execution Environment").  Execution of code in DotGNU SEE
    will either be directly as a plugin (for programs that are
    distributed with DotGNU, and which have been compiled to
    native code with gcc), or via a Java bytecode or IL JITer
    which in turn is a SEE plugin.
 
b)  There will also various kinds of webservices that will rely
    on being able to execute code on the cient side.  Again,
    this code would be executed in the "DotGNU Secure Execution
    Environmant".  So DotGNU will not be useful for providing
    this type of webservices unless DotGNU SEE is made available
    for all widespread desktop systems.
 
c)  As we're moving into the area of webservices, it is very
    important to keep in mind that the end users should have the
    freedom to keep all data on their own computers.  This
    fundamental freedom is very strongly attacked by Microsoft's
    .NET, and I believe that it is very important that we very
    clearly address this issue.  Microsoft is building a
    web-services infrastructure that they control, and they will
    allow some programs to be run *only* on machines operated by
    Microsoft and Microsoft's "partners".  This means that the
    customer is forced to transfer to those computers the data
    that those programs will process.  I believe that this
    violates a very fundamental, privacy-related freedom.  It
    will also lead to many customers not even having a copy of
    all their business-critical data, which results in a very
    strong case of vendor lock-in.  There can be no doubt that
    what Microsoft is doing here is outright evil.  How will
    businesses be able to switch to Free Software if Microsoft
    is in control of their business-critical data?
 
    In contrast, DotGNU is designed to prevent this kind of
    vendor lock-in, by making sure that all the code which
    powers a webservice can also be executed locally, on the end
    user's computer, in the "DotGNU Secure Execution Environmant".
    This gives the users of the webservice the essential freedom
    of keeping their data on their own computer.
 
    The programs which implement webservices under DotGNU will
    all be available as Java bytecode or IL on the server side.
    Whenever a client is properly authenticated so that it has
    the right to cause the execution of the program on the
    server, the client can also cause the transfer of the
    program (as Java bytecode or IL) to the client-side "DotGNU
    Secure Execution Environment".
 
    I feel that it is very important that we can say that DotGNU
    protects the freedom of to keep your data on your own
    computer.  It's a sad situation that currently many people
    are not granted the freedom to do their work with a Free
    operating system.  We can criticise their employers for
    that, but at the same time we must admit the reality of this
    situation, and avoid a situation where a widespread adoption
    of DotGNU-based webservices might lead to these people
    losing the freedom to keep the data (which is essential for
    their work) on computers that are under their control.
 
To summarize, those parts of DotGNU which are of interest only
for _providers_of_webservices_ only need to work on GNU systems.
For example, a program for balancing the load between multiple
webservice servers, or the C# compiler, such programs only need
to work on GNU systems.  We don't need to worry about porting
them elsewhere.
 
DotGNU SEE on the other hand needs to be available on the vast
majority of desktop systems, in order for DotGNU-based
webservices to be useful and ethical.

Greetings, Norbert.

-- 
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month  http://cisto.com