[Opensim-users] Banning "bad" viewers was Re: Can this be done?

[John Ward]

Anders Arnholm wrote:
>> Ignoring the name calling....
> 
> The name calling was for someone that thinks that can secure a server by
> blocking any kind of client. The server have to be secured on the server
> side. It can never ever trust anything from the client.

A screed is a screed is a screed.  I don't see the value in your name calling.

You say a server can never trust anything from a client.  Then by reasoning a 
sever can only have untrusted conversations with clients.  Trusted connections 
can be established with proper techniques even if say they can never be trusted.

>> When one designs the server side of a system and finds a security flaw in
>> the client software that they did not write, then by your logic the 
>> server has responsibility to block the client or shut down the service. 
>> That agrees with blocking you so vehemently reject.
> 
> If the client have a security problem, the client should be fixed. if it's
> your own client you can use messaged to ask users to update, maybe even
> deny them access untill they done so. If a bug in the cleint make

One might use a client ID string check to facilitate that.

> the server unsecure, then the server is unsecure and should be fixed. The
> server can't be resposible for client security, the client can fix server
> security. Whats happends on the other side of the internet your side can't
> take resposibilty for.

Which doesn't address the service operators responsibility or potential
liability to the user with the bad client or their use of any unqualified clients.

>> Exactly the point.  I use the word obscure the same way you do when you 
>> said "By makeing the knowledge some kind of long obsure string I made up 
>> my self. It's much harder for someone else to figure this out and the 
>> trust is me is me gets better"

> This is not the security by obsurity thou.

If one picks a guessable password they very much are relying on "security 
through obscurity".  It's like leaving your spare house key under the door mat.

>> Correct.  However some systems mix them.  The idea being that if access 
>> is the only permission available then authorization and authentication 
>> become a one to one correspondence.  I generally argue against this
>> mixing.
>> 
> 
> You can't mix them, you maybe can do at the same time and you can have bad
> schemsed for it. But as it totally differ functions and theoretical 
> functions you can't mix them really.

What is the difference between "mixing" and "doing them at the same time"?  In 
the context I presented they seem to mean the same thing as best I can tell. 
When you tell me I'm wrong I wish you would take a different position.

>>> Both models have there vaildity the problem with the layer idea is when
>>> it applied to stuff that easy can be added into a tool.
>> Checking a string is on easy end of the scale.

> The flaw, the big flaw in this model is that you asks the bad guys to 
> identify thems selfs. It's a bout as efficiant as a sign "Bad guy's, don't
> log in please."

You faulted layering security because tools have to be easy to add.  I pointed
out that checking a string is pretty easy.  Now you say the flaw is elsewhere.

And you are wrong about the big flaw, the big flaw is that filtering by ID
string annoys your legitimate users as much or more then the users you want to
keep out.