User:Robin Cornelius/ExecSummary

This is a summary based on the open source discussion at Hippotropolis on 28th Oct to discuss the upcoming Brown Bag meetings regarding 3rd party viewer policy. This is indented to represent the views, concerns and questions from a number of of source developers of viewers and clients that connect to the SecondLife service.

Viewer registry

Currently the entire concept of what is proposed by LL is very unclear and there is concern from the community that the entire concept may not work at all. Discussions on the Initial blog comments and at our pre-BB meeting have highlighted many of the concerns. The possible implementations we can visualize of this idea range from a simple list of "approved" viewers to only allowing "approved" viewers to connect to the grid.

Starting with the simple ideas and ending with the more extreme - There is some support for some ideas in this area from many in the opensource community, but this depends on exactly what is proposed. Basic questions that cover all possible implementations include:

• How would a viewer get on or off this list?
• Who is making these decisions? Linden Lab, developers, residents?
• How are "approved" viewers actually checked?
• Exactly what does Linden do with the viewer registry list?

Subject to the above questions, the most basic implementations is just a list of viewers linking to their websites. Almost like the Third Party Viewers List that exists today

One issue here is that a list could give users some confidence in the viewer as a common concern is, "how can i trust a 3rd party viewer with personal information such as username/password combinations?". But conversely NOT being on the list could be seen as being an evil viewer and this is not a good situation either.

Moving along the scale we have things like providing some kind of crypographic signature for viewer binaries (only those that are released for public download) so that the list of approved viewers also contains, for a trivial example, a MD5 sum, or even a gnupg signature, so the user would then know they were getting the real thing from the 3rd part developer, whist the basic concept of "signing" a viewer is ok to many, if this was on the list it open up new questions :-

• How would we update the list?
• Are we really going to have to jump through hoops every time we make a minor change?
• Will this affect our ability to test our code as we develop it? Will we still be able to connect to Agni to test new changes?

Things like gnupg could avoid much of this as you could check the key was for an example the "Emerald developers" key, you wound not need to change the registry at all and the 3rd party devs could push out as many releases as they liked they just sign with their private key and the viewer registry contains the public key. Debian uses this system for their official apt repositories BUT there is *no requirement* in Debian to use their official apt repository, a user could simply download a deb from a web site or use a 3rd party apt repository and this should not be a requirement here either. Who bears the responsibility if a bunch of devs are all pushing binaries with the "Emerald developers" key.

The other extreme of the viewer registry is only allowing approved viewers to connect to SL, this is related to the Authentication topic which I will discuss next. But this falls into the whole category of limiting access to SL. Limiting SL access would IMHO be a very very bad move by LL. Again the same questions of how to get approved come up, but now they have a real urgency and seriousness to them which must not be understated.

There are many many viewers out there, all kinds of service bots, text clients, clients for blind users, web clients as well as the ones produced by LL. Just trying to process this number of viewers would be difficult, and it will result in many authors just not bothering at all. There are viewers being developed for light operation without graphics for low end systems, viewers designed for the blind user. There are also viewers for systems systems as 64bit linux, *BSD etc. These mostly require custom viewers to work on the grid. Often the end user is recompiling the viewer themselves just to get in SecondLife. In some cases such as omvviewer, this was allowing a lot of 64bit linux users to connect that otherwise would not be able to, or would suffer frequent crashes due to 32/64bit mixed issues. Loosing many of these viewers would prevent significant numbers of users connecting to the SL service and also break significant in world content and systems that require bots to operate.

In summary, there would be a huge ecosystem of independent viewers adversely affected by any such extreme change to the access policy, and this would be to the huge detriment of Linden Lab, its users, and its open developer community alike.

What will be the policy towards homebrew viewers never distributed

There are many reasons for compiling a viewer and never distribution. Including :-

• Development tests
• Optimizations specific your a single architecture
• Utility bots for providing services in world

How will the policy effect these kinds of viewer/clients?

Viewer Authentication and faking

Currently the viewer only notifies the SL service what it is, via the channel it connects with. LL has the ability to block a specific channel there for crippling viewers that use that channel. In the above viewer registry discussion one extreme was only allowing authorized viewers to connect. But this also applies to creating a blacklist of bad viewers based on how they identify themselves.

Remote "untrusted" client authentication is a real world problem that no one has successfully solved. It just simply is not possible to get the viewer to say to the server I am viewer XZY and for anyone to actualy be even 10% sure that this is true. The viewer now as mentioned uses a trivial protocol to announce what it is. This is probably as good as this system will ever get.

The fundamental issues are even if an encrypted/cryptographic system was used for the viewer ident system, the keys to the crypo MUST be on the users system or else their viewer could not encrypt the message in the first place, and there for all this has done is started an arms race. Any hacker could simply extract the appropriate keys and use this to encrypt their own message and pretend they are XYZ viewer. This is not as difficult as it sounds, Microsoft's media DRM suffers from this type of attack, the DRM keys to decrypt the media are on your HardDisk if you are allowed to listen to it. So you just need to find those keys and you have unlocked the media. This is VERY common and microsoft have even taken steps to build this into there operating system to protect the keys. In a program such as a Secondlife Viewer, there is keys must be there in the code for all to extract by some means or other.

In summary here, relying on viewer authentication for either restricted access or for blacklisting viewers is doomed to failure and will result in good viewers being faked as bad and banned/blacklisted. It creates unnecessary hurdles for those creating 3rd part viewers and those greifing will invest the effort in to pretending to be viewers they are not (such as the offical LL viewer, or some 3rd party scapegoat viewer), or simply use approved viewers (including LL's own viewer) to carry on the greifing exactly as they did before.

Encrypting communications

This seems to be a particularly hot topic and one of the key concern areas for LL with regards to 3rd party viewers.

There are plenty of valid reasons for wanting private communications, one big one especially with LL's push for more businesses to come to SL to do work is that businesses do not want all there communications logged. I think if any business found out their private island meetings are recorded would be bad enough, but the fact IM's are also logged and encryption is seemingly not allowed would be the final nail in the coffin. Why would a business want to come to SL to do anything more than PR/Customer relations and advertising in this case.

We would like clarification of the ToS with regards to encryption and would like to understand exactly what the concern/requirement for LL log every IM is. For someone to receive an encrypted IM them must have first spoken to the other party and accepted the encryption key, so i find it hard to believe that just G-Team/AR reports are the reason for the concern here.

Possible reasons some us have considered include :-

• AR/G-Team issues
• A merge with the teen grid, concern over adults using encrypted chats with minors
• Anti terror type issues

Please can LL just be open and honest on what the issue with encryption is, why its a problem?

Voice is not apparently logged by IM and voice based ARs are a problem to report, but it should be noted the voice packets go over vivox's network, are they recording the voice?

Content theft

This is a very difficult problem to solve but the following points are relevant :-

• The first copy bot existed before the viewer was open source
• The worst issues have been LL server exploits, either allowing xfer hacks to produce 100% copies including original creator or to allow full perm hacks to even get to the scripts
• LL servers have managed to just loose permissions in the past
• Textures can always be ripped right out of the OpenGL (or DirectX buffer)
• Sounds and other assets also have some vulnerability, the cache is a weak spot, but is a needed thing for proper viewer operation

Now please don't get me wrong, i am not saying there is a free for all on these assets, but they are difficult to protect and that 3rd party viewers are a very long way away from the core problems.

That said, Emerald were one of the first to introduce a system for protecting the clothing layers, which LL have since adopted ideas from and have done there own version. This point should not be understated as this is a 3rd party viewer actively trying to prevent theft.

What else can 3rd party viewers do in this area? Developers of viewers expressed interest in helping protect content, but actually how to do this is an exceeding difficult challenge.

There was talk of watermarking images, a possible but again fake-able and how to you enforce this/prove this/prove you had original copyright/not get ARd for using a free image someone else already did etc.

Server/Protocol security issues

As mentioned in content theft, the worst issues have been server side/protocol issues. Many of these issues have been reported to LL a long time ago, I am not sure if the messages simply did not get to the right developers, or they were not taken seriously. But it has taken the development of renegaded viewers for LL to take these vulnerabilities seriously and to actually start patching the server.

If anything this teaches us the open source method works at finding issues but people *really* need to listen to the issues that are found and act on them

Open source contributions to the stability and features of LL viewer, new ideas and creativity with 3rd party viewers

As a closing comment section, I would like to quickly talk about the various features and stability that have been brought to SecondLife via the opensource "viewer" development community. With out the open source effort, the viewer would not have 1/2 the fixes it has now, would not be as stable, nor support Linux and probably mac as well as it does.

The OS developers have invented all kinds of useful features, just looking at the comments in the blog from emerald users shows how liked the emerald viewer is.

All these stability fixes, feature additions and the wonderful benefits of 3rd party viewers are at stake if this policy is restrictive.

The issue is a small number of users, who will exploit any viewer even LLs own combined with a history of server side issues has left the 3rd party viewers looking some what like a scapegoat for an issue that will NOT go away even if you removed every 3rd part viewer or restricted viewer access.