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 intended to represent the views, concerns and questions from a number of open source developers of viewers and clients that connect to the Second Life service.

There is considerable confusion in the developer community regarding what Linden meant by the recent blog posting on 3rd party viewers, and the confusion only broadened during the forum discussion on the blog entry. As developers, we take into account a broad range of important technical issues which include, but are not limited to, a focus on service protection and client management. We believe that a balance is required so that all parties may benefit. Below are some of the concerns and issues we see with what little information we have on Linden's new policy.

Viewer registry

Currently the entire concept of 3rd party viewer policy 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 SL blog and at our pre-BB meeting have highlighted many of those concerns. The possible implementations we visualize range from maintaining a simple list of "approved" viewers to allowing only "approved" viewers to connect to the grid.

Let's begin with the simple ideas and move along a continuum to the more extreme. Depending on exactly what is proposed, many in the opensource community express support for some ideas in this area. Basic questions that cover all possible implementations include:

• How would a viewer be added to or removed from 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 implementation is just a list of viewers linking each to their websites. Almost like the Third Party Viewers List that exists today.

A common concern can be expressed as: "how can I trust a 3rd party viewer with personal information such as username/password combinations?" A list of viewers could give users some confidence in the specific viewers. Conversely NOT being on the list could lead to being seen as an 'evil viewer' and this is not a good situation either.

Moving along the scale, we have things like providing some kind of cryptographic 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. The user would then know they were getting the real thing from the 3rd part developer. While the basic concept of "signing" a viewer is ok to many, if this information is on the list it opens up new questions:

• How would we update the list? (How is the list updated?)
• 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 can check if the key is, for example, the "Emerald developers" key, and not need to change the registry at all. The 3rd party developers could push out as many releases as they like, just signing with their private key. 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 simply downloads a deb from a web site or uses a 3rd party apt repository. Using an official apt repository 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?

Another extreme treatment of the viewer registry is only allowing approved viewers to connect to SL; part of the larger topic of limiting access to SL. This is related to Authentication, a topic I will discuss in another section. 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 cannot 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, a huge ecosystem of independent viewers would be adversely affected by any such extreme change to the access policy. This would be to the detriment of Linden Lab, its users, and its open developer community alike.

What will be the policy towards home brew viewers never distributed

There are many reasons for compiling a viewer and never distributing it. They include:

• Development tests
• Optimizations specific to your single architecture
• Utility bots for providing services in world
• Improving personal security by running only code which you compile yourself.

How will the policy effect these kinds of viewer/clients and their intended purposes?

Viewer Authentication and faking

Currently the viewer identifies itself to the SL service using only a channel name. LL has the ability to block a specific channel, hence crippling viewers that use that channel. In the above viewer registry discussion, one extreme was allowing only 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 actually be even 10% sure that this is true. The viewer now as mentioned [??] uses a trivial protocol to announce which it is. This is probably as good as this system will ever get.

The fundamental issues are even if an encrypted/cryptographic system is used for the viewer identification system, the keys to the crypto MUST be on the users system or else their viewer could not encrypt the message in the first place. In this case, we have an invitation to an arms race. Any hacker could simply extract the appropriate keys and use them 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 has even taken steps to build this into there operating system to protect the keys. In a program such as a Secondlife Viewer, such 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 party viewers, and those griefing will invest the effort pretending to be viewers they are not (such as the official LL viewer, or some 3rd party scapegoat viewer), or simply use approved viewers (including LL's own viewer) to carry on the griefing 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 their 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 to log every IM is, assuming that there is one. For someone to receive an encrypted IM they 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 it is a problem?

Voice is apparently not 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?

Such issues notwithstanding, SL is a worldwide service and privacy is regarded by many as an inherent right which cannot be taken away, and a matter of personal security.

Content theft

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

• The SL platform is based on a model in which assets and objects are copied to client machines by design, not by accident or exploit.
• The first copy bot existed before the viewer was open sourced, leveraging this design that is inherent to the platform.
• 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

It is important that the position of the open source community on this issue be understood and not misrepresented. We are not saying that there should be a free for all on these assets, but that they are sent to clients by design, and hence are very difficult or impossible to protect. 3rd party viewers are a very long way away from the core problem.

That said, 3rd party viewers such as Emerald have a system for protecting the clothing layers, from which LL have since adopted ideas and have developed their 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 how to do this is an exceeding difficult challenge.

There was talk of watermarking images, a possible approach but one that is neither free of problems nor hard to circumvent. Even if it worked partially, how would you administer or enforce this, or prove that you had original copyright and not get AR'd for using a free image that someone else has used first? The problems are many.

Server/Protocol security issues

As mentioned under Content theft, the worst problems have been server side/protocol issues. Many of these have been reported to Linden Lab a long time ago. Perhaps the messages simply did not reach the right developers, or they were not taken seriously. Unfortunately it has taken the development of renegade viewers for LL to take these vulnerabilities seriously and to actually start patching the server.

If anything, this teaches us that the open source method works well at finding and highlighting problems, but Lindens *really* need to listen to the issues that are reported and act on them. Blaming clients will not solve the problem.

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

As a closing comment, we would like to briefly mention the new features and stability that have been brought to SecondLife via the open source viewer development community. Without the open source effort, the viewer would not have a fraction of the fixes it has now, it would not be as stable, nor would it support Linux and probably Mac as well as it does now.

The open source developers have invented all kinds of useful features to support users with a very wide range of interests, who could not otherwise have been supported. Just looking at the comments in the blog from Emerald users clearly 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 the viewer policy becomes restrictive.

The real issue is that a small number of users, who will exploit any viewer even LL's own, combined with a history of server side faults has left the 3rd party viewers looking somewhat like a scapegoat for a problem that will NOT go away even if you removed every 3rd part viewer or restricted viewer access.

In summary, the problem has been very badly misrepresented, and this has resulted in an entirely inappropriate focus on restricting clients. This is neither sensible nor balanced, and it cannot be effective.