[sldev] alternative os support?

Joshua Bell josh at secondlife.com
Tue Jan 23 15:14:33 PST 2007


One current use of this handshake is to be able to say "there is a newer 
viewer version available for your platform" - either required or optional.

* Optional usually indicates that bug fixes are available
* Required usually indicates:
** a protocol change
** a client-side exploit was discovered/patched
** a bug in the viewer is causing content loss or DoSing the grid

Obviously, viewers can lie, in which case:

* They won't be told of optional updates - well duh, it's not an 
official build anyway
* They would be using an incompatible protocol - and stop working in 
short order
* They would be vulnerable to a client-side exploit - so update to the 
latest code
* They would continue to DoS the grid - but a malicious viewer can do 
this anyway

As the Second Life ecosystem evolves I presume that some day the 
viewer/server protocol will be open and stable enough that most of these 
issues go away and that this sort of handshake is informational only. 
And then some day this will hopefully be like the web, where the thought 
of a web site telling you to upgrade your browser is anathema.  However 
we're not there now, all but a small fraction of residents get their 
viewers from a single source, and the protocol does change on a frequent 
basis. So this handshake still makes sense.

We'll hardly ever do server-side differentiation based on viewer 
platform. We have done this a few times recently when there was a 
Mac-only fix - no point in forcing the Windows users to update. 
(Following this thread, you'll see that we are currently unable to do 
that distinction for Windows vs. Linux users - sorry!) Generally, the 
optional/required versions advance in lockstep.

...

So yes, we wouldn't add "bsd" to the list of valid clients, and should 
instead evolve this handshake to accommodate viewers build by other 
parties. Off the top of my head for short-term approaches would be to 
add Linux (which for the foreseeable future will be the UN*Xy platform 
targeted by Linden builds) and perhaps add an "other" token of some 
variety that can be used to tell users who have built their own viewers 
that the protocol has changed.

Opinions? What makes sense? What information should be provided in this 
handshake such that a sufficient warning can be shown? (And consider the 
scenario that you've built the viewer yourself vs. the future scenario 
of having downloaded the viewer from a third party provider.)

Mathew Frank wrote:
> Joshua,
> as long as this is being visited, the following thoughts occur:
>
>    1. blocking access based on reported name of client is like
>       blocking based  on reported name of web browser - ie useless in
>       blocking access to somebody not using your official client.   It
>       only leads to a misreporting of the client type - for example
>       libsecondlife says it is windows when it is not.
>    2. I see that you put this in so as to have an easy answer to
>       potential problems.
>
> Accordingly don't just add "bsd" to a list of valid clients.  Replace 
> the "denied access" system with a simple warning.
>



More information about the SLDev mailing list