Re: SSH revised

[Bas Wijnen]

On Tue, Mar 28, 2006 at 10:41:02AM +0200, Marcus Brinkmann wrote:
> > Companies in particular aren't very fast in adopting new methods, though,
> > and they'll want to have the administrator do these things.  If the user
> > doesn't agree, she can easily work around this if she does have access to
> > the network.  But I think that trying to tell this to the manager is
> > something that takes years (and if we take that effort anyway, we could
> > better tell about something important, like software patents ;-) ).
> 
> Company policies are not necessarily a good guidance for (our) system
> design.

True.  But in case of something trivial like this, which doesn't harm our
design at all, I think practical matters which may influence adoption of the
system in a positive way are valid for deciding to allow things.  In case
these things would conflict with our design goals, it's clear that the design
goals are to be followed.

> > But as I said, it's easy to disable this.  Depending on how the service is
> > implemented, the host ssh server can filter the password file before
> > checking if a user is in it, or the administrator can fail to give a
> > capability for the network port that should run the server.
> 
> What password file? :)

You know, the one that maps strings to user accounts.  Like /etc/passwd on
unix systems (which doesn't actually hold passwords either ;-) ).

> You are right of course, that the feature can be added.  However, I am
> really interested in exploring the user freedom principle here.

User freedom is important, and we should make it possible as much as we can.
But forcing user freedom on people isn't going to work.  If we try that, then
the administrators will simply choose a different OS, and that doesn't help
the user either.

So in my opinion we should allow as much user freedom as we can, but in most
cases the administrator should be able to limit it.  Note that this is only
about limiting freedom of users by the owner of the computer.  Limiting
freedom by anyone else (through DRM) is unacceptable, and we shouldn't try to
provide means for it.  On the other hand, I don't think it's worth crippling
the system to make it impossible, but if we can make it possible to support
DRM without gaining anything else, I think we should not do it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature