[sldev] 3rd party viewer policy post on blogs.secondlife.com

[Jonathan Bishop]

I have just spent the last hour or two reading the blog on this topic.  The
quality of the discussion is so completely uninformed from essentially a few
people that are being allowed to monopolize the comment threads that it is
almost dysfunctional.

So I am going to comment here where at least people with some idea of what
the issues are will see it.

I see a clear benefit of having a list of SL browsers that are "recognized
by LL" to be, say, well behaved, not likely to steal the user's account
details, or intentionally corrupt their machine, or duplicate their content
and email it to the chattering masses.  But that is where it stops.

The idea that a registration system should (or even could) be devised that
forces each browser to be pre-approved before accessing SL would
e3ffectively halt OS development and defeat the a key purpose of OS'ing the
code in the first place.  Why? 

Firstly, because the development life cycle is to test the thing being
developed under real world load and conditions.  Something that can only be
done on the grid - until the server code is OS'd as well.  

Secondly, a key advantage of OS is the flux in the development and product
pool: the ability to pursue many similar paths across many teams
concurrently so that innovation occurs and gradually the better, more useful
solutions emerge.  The whole point is a lack of stability across the entire
development tree but stability within each branch and trunk.  Once
registration and authorization is mandatory the branches cease to stray from
the trunk.  

Thirdly, the cost in time and resources for LL to code verify every
candidate browser would defeat the economic benefit of LL outsourcing it in
the first place, and the diversion of resources from server enhancement, and
key feature innovation would increase the risk of a competitor duplicating
and catching up to the SL solution.  They would be better scrapping the OS
browser's all together.

Fourthly, it is too late. The key information about how everything works is
already "out of the bag", so any attempt to close it without massively
changing the server interface would be ineffective.

Fifthly, the suggestion made by some on the list that a binary hash code
could be used to verify the integrity of the browser version connecting
(a-la-unix code version verification) ignores the fact that (a) the browser
can report any number it likes to the hash request, and even if that could
be avoided, no one can stop me writing an injection dll and hooking directly
to the winproc, the ports, dynamically replacing procedure calls or wrapping
the OpenGL dll or the win32 dll, or any one of a dozen other ways I can
inject my own library into an otherwise legitimate app - that will continue
to report the hashcode correctly, once it has loaded.  Anyone who doubts me
and has a Logitech camera attached to the computer - take a look in the
windows temp folder for a dll called Lvprcinj***.dll - that is the Logitech
injection dll that ensures the camera can always function regardless of what
is running.

I think a registry is a good idea to protect non-programmers who want to
download an alternate viewer in safety.  Beyond that - for example as an
enforcement tool - it is a waste of valuable resources.  And yes, I am a
content developer who wishes copybot (et al) did not exist, but I would not
for a moment claim the world should be made "safer" by tieing the thumbs of
the browser developers.  As someone who essentially uses the LL viewer, I
have no personal position to protect with respect to the OS browsers - but I
100% support what is being done by the OS developers, and am very concerned
that the predominant tone of the comments in the blog thread is dangerously
uninformed, self interested, destructive and simply technically wrong.

Regards

Jonathan Bishop