A part of the Server/Sim/Scripting User Group meeting was taken up with discussion of the viewer policy changes. It seems some of the changes have been in the works for some time. Now that they are on the verge of being implemented the Lab made the public announcement.
Viewer Identification Tags
Tankmaster Finesmith said, “So, as one of the [Firestorm] TPV devs, we’ve know for a few months now that LL has wanted to brake the viewer tags. Today [Friday] we got word that LL will be braking them next week.”
So, Jessica is right, the viewer type ID tags will be turned off next Tuesday and Wednesday. Presumably the code to do that has already made it through QA process.
Simon Linden was the meeting chairperson or facilitor and I’ll quote him several times so I think this statement is important as a framework. He said, “…I’d like to preemptively explain that I’m a coder working on the server, so I’ve mostly been out of this loop. I’m not a lawyer, from marketing or product, etc. etc.” I suppose that means we need to keep what he says in some sort of perspective.
Simon also said, “But one aspect that will hit next week is that the viewer identification tags will no longer work.”
Several respected members of the group stopped discussion on what Lab’s motives might be and made it clear what the limits of discussion appropriate to this UG were. Unfortunately everyone acknowledged there is no longer a group where such viewer discussion is appropriate. Esbee Linden once upon a time worked as the lead for Viewer Evolution. But, she has another roll in the Lab and has never held group meetings since her return to the Lab. So, that leaves the forums.
So, at some point when you rebake your avatar the viewer tag will disappear. Of course changing the avatar appearance forces a rebake. So, very quickly viewer tags will disappear.
The way the viewer tag gets from one person to another is by an information transfer of avatar information made by the servers. There is apparently some information in that package that is not used, extra texture information is some of the information. This is being cleaned up and in that group of information are the viewer tag ID’s and those are being removed.
Simon said, “The viewer tag issue has two sides — the technical one, and the TPV policy. Technically, the server will not blindly pass unknown data from one viewer to all others in the AgentAppearance message – the un-used texture entries will be cleared out. This is the vehicle that viewer ID tags were built on. Since you guys are all clever, it would take a few minutes to figure out other ways to do that. But that hits the policy issue – LL doesn’t care if anyone tells others what viewer/os/network you’re on. But it can’t be an opt-out automatic system.”
So, there is a privacy issue in the viewer tags. While there is nothing to keep one from displaying the tag in their viewer, a viewer cannot send out that ID information without the users’ permission. It seems the Lab is saying that viewer users may tell others their viewer type, operating system, and other information, but, they must deliberately tell others that information. The viewer cannot automatically do it for them.
But, it is unclear whether the Lab would find changing the viewers to require user action to send that information would be acceptable or not. What is obvious and understood is that the Lab’s servers will NOT be transmitting that data in the AgentAppearance message. So, some other form of viewer to viewer communication would be needed and that is unlikely. While some type of chat communication like /125728 viewer=Firestorm is possible, it would be far less efficient.
My Special Viewer – Shared Experience
One of the attendees Flip Idlemind asked, “My personal viewer had features that other viewers don’t? Depending on how broadly you define “shared experience”, am I now in violation?” This is a key point I and others seem to have taken too broadly. As Innula pointed out in a comment in the previous article, someone would have to be setting beside her to share her experience of Second Life. The answer to Flip’s question is: not likely. Simon made no response. So, there is some ambiguity, but the idea is much narrower than several of us have taken it to be.
The shared experience idea means you can’t change what others see. Torley could have Torley colors, but he can’t force Torley colors on anyone else.
An example of changing the shared experience comes from the past, Emerald Viewer’s new attachment points. Using those ‘extra’ attachment points only worked for those with the Emerald viewer. Everyone else saw things attached in odd places or floating out to the sides of the avatar. It broke the shared experience.
Simon commented on the Emerald example saying, “That policy change is really designed to try and prevent that from happening again.”
Tankmaster Finesmith explained a bit farther, “Basically on any major feature that affects the way you use Second Life, Linden Lab wants the devs to work with them to get the feature ironed out so that server side support and whatnot can be properly set up and then all viewers can use it.”
Simon Linden explained it this way, “Let’s pick an example – let’s say you figured out a way to do 3D display in SL, but when you use it, everyone else sees garbage. That would be a violation. If you figured out how to do it without changing the world for everyone else, that’s great.”
RLV
The question of whether this affects RLV (Restrained Life/Love Viewer). Simon’s answer was, “There are no issues with RLV.”
User Interfaces
User interfaces do not change the ‘shared experience.’ So, the policy changes to not affect Third Party Viewers (TPV) user interfaces.
Unintended Consequences
One now has to wonder how the viewer ID system will work. Viewer ID information is sent to the servers. We know it is not going to be retransmitted. Some of the information is available through LSL (Linden Scripting Language), scripts. Some of that ‘scripted’ information transfer is changing too.
We know getting online status via scripts is going to change. All those online status indicators for shop owners and customer service people are likely going to have to be redone to some extent eventually. Whether they will be possible is questionable. We’ll know more later. Some think an object owned by the person will still be able to show their online status. But, an object I own cannot run a script to show your online status.
I think the viewer ID thing will affect various games within Second Life. It may be possible to program a HUD to get viewer ID. I’ll own the object. So, a HUD I wear can get my viewer type and send that information somewhere. But, unless I wear the HUD or some scripted object there will no way for anything outside of my viewer to collect that information other than the Linden Lab servers and they will not be relaying that information.
WindLight
There are some changes coming for WindLight and how it is implemented. The rumor is that Oz Linden will be discussing what the viewer needs from the server to provide parcel level WindLight settings.
Simon commented, “I haven’t looked specifically at parcel WindLight settings, but it’s probably one of those features that needs minor changes all over, and thus turns into a pain. Viewer UI, messaging, server code and back-end database.” That suggests it will likely be some time before we see this change reach the main grid.
This is a feature that is currently implemented in Firestorm. That viewer handles it by storing information in the Parcel Description. A better way to handle the data storage is needed.
As it is now, it presents a conflict with the new policy changes. The WindLight change only happens in viewers that have the feature. So, in that respect it does not change the shared experience of anyone using the Second Life Viewer. However, Firestorm saves the WindLight settings in the Parcel Description. That changes the shared experience of anyone reading the description.
That doesn’t really matter to the Lab. If they chose to be hardnosed about it, the feature would have to go. They are helping to find a better way. I doubt we will see the Lab force the removal of the feature.
Summary
In an initial take the policy changes seem aimed at Third Party Viewer developers. In many ways they are. But, the purpose is to stop many of the privacy violations we see with the anti-copybot technology that is used by many.
False positives have apparently been a growing problem from this type of software. I guess many of you remember the Red Zone scandal and Emerald-Onyx scandal. (search on either here for more info). It affects the shared experience in ways that are upsetting and frustrating to new and long time Second Life users.
Also, griefer stalking has been an ongoing problem. I see a few ‘what-do-I-do’ posts each month in the Answers Forum. People are literally forced out of an avatar and into an alt in an attempt to get away. Some of the anti-copybot software has allowed the tracking of alts. Presumably this will help reduce those problems.
The policy changes are not as bad as I first thought. My first take left me wondering what’s left for a TPV Dev to do? They will affect how viewers are developed for Second Life. But, it is not the end of TPV’s.
What concerns me the most about this policy is that it stifles the only user driven innovation in SL.
Think about avatar physics; as originally implemented that would violate this policy, but in the end it was so wildly popular that LL implemented it properly. LL has always liked the “innovations” they come up with and pretty much ignored resident input. The jira is full of feature requests that are ignored, the best of them rise to “maybe someday” status.
You make a good point. But, remember. Management at the Lab has changed. It is hard, if not impossible, to say what would have happened if Avatar Physics had not been added by Emerald. Some believe the feature would have been added sooner, later, or not at all. Some believe Emerald made it sooner. Some have doubts. Whichever camp one falls into, it is belief not knowledge. People argue passionately for their beliefs. So… we have wars based on religion with nothing but beliefs for a basis.