[sldev] 3rd party viewer policy - Viewer Reg doesn't defeat the purpose of OS'ing.

Science Fiction Computer - SCi-Fi PC partners at scifipc.com
Tue Oct 20 19:28:20 PDT 2009


Respectfully, Jonathan

DMC ;)

-----Original Message-----
From: sldev-bounces at lists.secondlife.com
[mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Science Fiction
Computer - SCi-Fi PC
Sent: Wednesday, October 21, 2009 12:26 PM
To: 'Jonathan Bishop'; 'Second Life Developer Mailing List'
Subject: Re: [sldev] 3rd party viewer policy - Viewer Reg doesn't defeat the
purpose of OS'ing.

RE: Jonathan Bishop
SUBJ: Viewer Reg doesn't defeat the purpose of OS'ing.

A LL a registration system does not defeat the purpose of open sourcing at
all, as viewer code released to date under GPL is still free in future to be
applied in connection with on other grids for the experimentation or
development of new features and functionality. 

The simple fact remains that LL server side code remains proprietary and LL
reserves the right to determine who connects to the SL Grid in the interests
of all users and the greater functioning economy. 

There are positive benefits that may come from this process if the
registration system results in an official and improved dialogue channel
available between Third Party Developers and Linden Lab. 

DMC Zsigmond



-----Original Message-----
From: sldev-bounces at lists.secondlife.com
[mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Jonathan Bishop
Sent: Wednesday, October 21, 2009 11:48 AM
To: 'Second Life Developer Mailing List'
Subject: Re: [sldev] 3rd party viewer policy post on blogs.secondlife.com

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 



_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting
privileges
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.423 / Virus Database: 270.14.24/2449 - Release Date: 10/20/09
18:42:00

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting
privileges
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.423 / Virus Database: 270.14.24/2449 - Release Date: 10/20/09
18:42:00



More information about the SLDev mailing list