Viewer 2.0 goes “live”

Tom (Hale) Linden bullishly pushes through Viewer 2.0 as the new default Viewer for Second Life today. In a post about an improved New User Experience, Hale lets slip that Viewer 2.0 is now released, stating that the new  viewer is now a part of the default download for new users when they create a new account. Viewer 2 is now out of beta and joins Viewer 1.23 and other approved third-party viewers as an option for all Residents.

While this move isn’t entirely unexpected – the Lab did state back when the released of Viewer 2.0 into open Beta was being announced that they planned to make it “official” “by the end of Q1” (which is today), the “announcement” that this is now the case is nevertheless liable to cause much outrage and upset – especially for those heavily engaged in new user orientation and who a) have been given next to no time in which to re-generate their notecards and other information to reflect the new Viewer and b) haven’t even been given the luxury of a formal open announcement that Viewer 2.0 is now “out of Beta”.

One might also point out that those still attempting to Beta Viewer 2.0 have probably been taken by surprise by this announcement.

So… here it is – and note that official support for Viewer 1.22 now ends, and support for Viewer 1.23 will terminate at the end of June 2010.

TPV: First casualty

imprudenceImprudence issued a statement earlier this week that they are withdrawing from Second Life as a result of the Third Party Viewer (TPV) Policy. In the statement, they set out their reasons as to why they are withdrawing, pointing to clauses 2b, 4a(i), 4b(iii), 7a and 7d, and 8c and 8d as being “unreasonable”.

Having gone over the TPV a number of times, I have to say I find Imprudence’s position for the most part hard to understand, as their interpretation of four of the clauses then mention seems to be wilfully subjective and misleading; while their reaction to two more of the clauses seems to lack any professional clarity of thought.

Imprudence state that (4a)i, (4b)iii, 8(c ) and 8(d) require us to promise to obey Linden Lab’s every future whim and that as such, the Imprudence team are unwilling to make such broad promises, not knowing what they may request.

This is a very sweeping statement, with Imprudence further claiming that 8(c) requires that they agree to stop using or distributing the viewer at Linden Lab’s request and that 8(d) requires that they agree to add, modify, or remove parts of the viewer at Linden Lab’s request, within a time frame dictated by Linden Lab.

However, these claims can best be described as over-exaggerated. Here is what clause 8c actually states:

If a Third-Party Viewer or your use or distribution of it violates this Policy or any Linden Lab policy, your permission to access Second Life using the Third-Party Viewer shall terminate automatically. You acknowledge and agree that we may require you to stop using or distributing a Third-Party Viewer for accessing Second Life if we determine that there is a violation.

Note my emphasis: the qualifier is clear. If a third-party Viewer breaks the TPV Policy, the Linden Lab require it no longer access Second Life. This is far short of Imprudence’s blanket assertion that Linden Lab require they “agree to stop using or distributing the Viewer” – a denial of access to Second Life clearly does not prevent them from continuing to distribute their Viewer for use on OS Grids, etc.

Similarly, clause 8(d) states:

If you are a Third-Party Viewer Developer, you agree to provide any content, data, executables, or for Third-Party Viewers based on our viewers, any source code that we may request to verify compliance with our policies, licenses, the GPL, or the law. If we believe that your Third-Party Viewer is not in compliance, we may request that you add, modify, or remove features, functionality, code or content, and you agree to comply with the request within a reasonable timeframe specified by Linden Lab.

Again, note the qualifiers I’ve emphasised. There is really nothing unreasonable here – if you wish to play in Linden Lab’s sandbox – which, by connecting to their servers and services a Developer is in fact doing – then sorry, Linden Lab have the right to ensure, so far as is possible (or, as I’ve stated elsewhere, give the perception they are ensuring) that your code does not constitute a threat to their services in and of itself  (excluding, obviously, mods any user introduces – which the Developer should again be able to prove relatively easily via the provisioning of their own source code).

Similarly, it is hard to see why Imprudence should be so upset of clauses 4a(i) and 4b(iii). Clause 4a(i) refers  to data received from Linden Lab’s servers – data for which Linden Lab has certain legal responsibilities (likely to be both State and Federal in nature (such as data privacy laws). As such, their various policies, terms of service, etc., must reflect such requirements  – and by extension, they need to ensure (or again, give the perception) that they are doing all they can to ensure that this data is protected when used by the software connecting to their servers.

Similarly, clause 4b(iii) relates to the protection of user data and makes a perfectly reasonable request that third-party developers take steps to ensure such data is kept secure when passing through their systems (and remember, if you use their Viewer, your login information, etc., goes through their servers). As such, it is in Imprudence’s best interests to ensure such data is protected at least to the same degree as on the Linden Lab servers. It is hard to see Linden Lab being so stupid as to issue requests for user data protection that exceed their own, and frankly – one would hope that Imprudence already have the necessary safeguards in place to ensure the data is as secure as possible.

Given that both these clauses relate to potentially sensitive data, I find it hard to accept that Imprudence, as responsible code developers would find a request to take reasonable steps to protect such data objectionable.

Indeed, in this, I find Imprudence’s own assertion that If and when Linden Lab makes any request of us, we will use our own judgement to decide how best to handle that particular request to be at least as presumptive and arrogant as anything in the TPV – even to the point of suggesting that if they see little need to protect user data, then that is their call, and nothing to do with either Linden Lab or the users of the Imprudence viewer.

Frankly, when all four of these clauses are viewed in their proper context, it is very hard to see how any professional software developer would find them in and of themselves reasons to reject the TPV Policy. That the Imprudence team opt to refer to the clauses somewhat out of context and apply highly subjective interpretations to them suggests that it is the thinking at Imprudence that is at fault, not the thinking behind the policy itself.

Clauses 7a and (d) have been the source of much wailing and gnashing of teeth across the Viewer development community, but again – as I’ve previously said – it is hard to understand why. While 7(a) is indeed poorly worded, and unnecessarily mixes Viewer use with Viewer development – there is absolutely no reason why the entirety of Section 7 of the TPV cannot be handled by a Viewer developer issuing their own EULA as a part of the distribution / installation package. A responsibly written EULA would clearly protect the developer for undue liability, and wouldn’t be in violation of GPL.

Certainly, it is what Kirstenlee Cinquetti has already done with her Viewer – and I’m pleased to see at least one voice of reason on the Imprudence website has raised the same point.

Which brings us finally to clause 2b. And here Imprudence have a point. As stated, the TPV Policy effectively restricts the export of content from SL to the creator. Period. If the user’s name is not on every prim, every animation, pose, script, contained in a linkset or whatever – then it isn’t going to be exportable.

This does – to be fair – read as overly restrictive. As if one is to remain fair, the clause seems to be less related to preventing content theft as it is about preventing “valuable” content being removed from Second Life per se – which LL have always looked less-than-favourably upon. Frankly, it is hard to fully justify LL’s stance on limiting content export so tightly: this automatically disallows the export of Group-created content for the purposes of back-up, and also disallows the export of content created by one person but sold under a license agreement to another. As such, I can see Imprudence’s concerns – just as I can see the issue LL face in trying to invoke the perception of protecting people’s creations when given the crudeness of the ownership / permissions system.

I doubt Imprudence will be the last of third-party developers to walk away from the Second Life sandbox. Each one that does will be a loss to the community to some degree, to be sure. How many do so on the basis of rational thinking as opposed to acting in a fit of pique, however, remains to be seen; and I have to say that having gone through the stated reasoning behind Imprudence’s move, I do feel it is a case of pique getting the better of them.

Server 1.38 rolls outs

Following the recent announcement on the subject, sever release 1.38 has started arriving, and with it the first steps in script management, together with other goodies.

Some 20% of the grid will be used as a pilot environment during the roll-out, with the rest of the grid receiving the update (assuming the pilot goes well) by the 6th April.

For scripters / builders, there are a series of new LSL commands than mean that (a) a lot of us are going to be busy for a while and (b) overall script counts / memory loading for certain functions should be reduced as the new functions are adopted. Initially, the ability to incorporate the new functions (for those that use them) will be limited to those working on 1.38 server sims (obviously) – so many of us are going to have to wait until after the roll-out has been completed before we start determining what needs to be changed.

As far as the script management tools are concerned, these are only available for those using Viewer 2.0; the functionality is not being back-ported to Viewer 1.2x (unless third-party developers opt to do so).

Ciaran Laval currently gives an overview of the new About Land script information tabs, and if it is not old hat by the time my home sim receives 1.38, I’ll likely have a few words on the information displays as well – unless, of course, Linden Lab keep to Jack’s stated promise and provide the necessary Information themselves. In this regard, and even allowing for the current roll-out being a pilot, I was somewhat surprised that nothing on the situation was posted in the LL blog (although a brief note did eventually appear in the Grid Status links).

Reaction to the new server code has so far been good –  those in the pilot are reporting good stability and overall improvements in sim performances. Doubtless, part of the latter is down to 1.38 fixing the Mono rezzing / start-up bug that would cause massive lag spikes.

Providing LL communicate the new script management tools and their limitations clearly, and estate owners can communicate matters to their tenants as well, 1.38 will hopefully be a boon to SL overall.

The future of Second Life?

At times it is easy to forget that, warts-and-all, Second Life is potentially the prototype environment of future systems that might aid us in so many ways.

The following is a video produced by Bruce Branit that appears to have been wonderfully inspired by Second Life and is both moving and points to a possible future use of immersive technologies that doubtless strikes a cord with any of us who can still glimpse the wonder that lies beyond the computer screen each time we go in-world.

My thanks to SuzanneC Baskerville for bringing this video to my attention.

A brief history of content-ripping

This “little” post has come about as the result of a suggestion from regular reader, Peter Stindberg, which followed the concerns I raised about the “Bye Bye Copybot” prim being circulated by members of the Emerald team, and lauded by  some content creators and others, despite its potential as a ToS violator.

Before I get to the nitty-gritty, I will point out that while what follows is a genuine attempt to timeline events and interrelations of events as accurately as possible, the degree of paranoia and misinformation surrounding content ripping means that a) there is a possibility I may fail to mention some events ; b) some may view things differently (and may themselves not necessarily be correct); c) I’ve confused issues (although I’ve verified as much as I remember over the years with various sources elsewhere) – in which case polite corrections welcomed!


Up until 2006, Second Life had largely been a closed universe: the code for both the server and client-side software was developed purely by Linden Lab. There had been issues around copying content – tools like GL Intercept, which enabled the likes of avatars to be copied, and basic tools and scripts that enabled textures to be pulled from the local cache. However, these tended to be somewhat obscure as far as the populace of SL at large were concerned, which somewhat mitigated their impact (but didn’t excuse their use).

Then something happened: libesecondlife was created.

libsecondlife commenced, with Linden Lab’s blessing, as group of Second Life residents attempting to back-engineer an open-source version of the Viewer (client-side software).  Today, to avoid copyright issues in relation to the Second Life name the group is now called


As a part of this work, an automated tool was developed – CopyBot that could be used to replicate avatars – bots, and be used as a debugging tool. The original CopyBot required that that target user actively give permission to be copied, and issued a disclaimer (in the form of a drop-down) prior to the copying taking place, specifying the fact that ownership / permissions pertaining to anything worn by the avatar would be lost in the copying process.

The software itself (written in C#) worked by intercepting the communications between the Viewer and server and replicating the information relating to objects (prims, textures). In doing so, and due the the way in which Viewer / server communications had been coded by LL, the copy process would lose the metadata relating to the original creator of the object and all permissions set against it – there was simply no way of including this information in the raw copy process as written in C#.

The original version of CopyBot was published as a part of the libsecondlife library of tools, where it became relatively easy for someone to remove the code asking for the target’s permission to be copied and the disclaimer drop-down, and thus use the code to copy virtually anything in Second Life – with the exception of scripts, gestures and animation (although later iterations of CopyBot could apparently grab animations and gestures from avatars) – completely surreptitiously, giving birth to CopyBot as we know it today.

What made CopyBot different to earlier attempts to rip content was its relative ease-of-use, it’s availability and – inevitably – the notoriety it quickly gained as a result of being made “public”.

From the start, the libsecondlife group were fairly unconcerned by the risk CopyBot presented to content creators, demonstrating a “so what?” attitude, supported and repeated by other techies posing as “journalists” as the news broke. Indeed, in one such interview, libsecondlife’s Admin, Babba Yamamoto intimated the issue of metadata loss could have been overcome if the CopyBot code had been re-written in XML (this is in fact how tools such as Second Inventory and Viewers such as Meerkat and Emerald “legally” export content)  – but no-one saw the point in doing so, since the “flaw” that lost the metadata lay with the way LL had originally coded Viewer / server communications, so those in the libsecondlife group felt justified in deflecting anger directed at them by pointing the finger at LL.

libsecondlife did eventually pull the CopyBot branch from their open source library as the wave of outrage reached the level of a tsunami – but again (and to mix metaphors) their action was that of not only shutting the stable door after the horse had bolted – but having ensured the horse had an open-ended ticket to any destination of its own choosing as it left the stable.

Protests and Response

The “revised” CopyBot code quickly started showing up as being for sale both in-world and on SL Exchange and immediately generated uproar as a result. Protests were held, the forums were flooded and people were angry: stores were closed; sims locked down, and calls were made to boycott Second Life.

While the libsecondlife group’s reaction remained pretty much, “so what?”, Linden Lab’s initial response to the protests could best be described as lukewarm, with Robin Linden repeating the assertion that content copying is “not necessarily” theft – a meme initially rolled out by Cory Linden – himself an active supporter of libsecondlife. While the meme is technically true (it should be pointed out that Second Inventory, for example, effectively uses CopyBot-style coding with ownership and permission checking in place, to export objects from Second Life, for example), it was also was somewhat disingenuous to raise it in the context of content ripping.

Many were angered by this reaction from Linden Lab, which gave rise to a further round of protests. Some of these made headline news in the likes of Business Week and – prompting Linden Lab to take something of a more affirmative stance, revising their policy to make it clear the use of CopyBot and similar tools would not be tolerated. While the move was in some ways welcomed, it was also felt that it was the risk of poor publicity, rather than a desire to help reduce the risk of Copybotting that prompted LL into “action”.

Nor was the revised policy that successful. By referring to the use of such tools as CopyBot, the policy implied that the sale of such tools in-world was still OK – and so people kept right on selling it at up to L$1500 a pop, quite prepared to face the wrath of residents while the Lab again kept quietly to the sidelines.

At the same time as calls for tougher action against CopyBot and it users continued, so to did the counter-argument “that nothing can be done” to stop the matter (an argument still heard today) gained strength among techies. People pointed to the code behind web pages being viewable and therefore copyable; people pointed to the existence of tools such as GLIntercept that could copy avatars, people raised the issue of ripping MP3s over the Internet as reasons why CopyBot was not only “inevitable”, but should be more-or-less accepted.

While such statements are broadly true, they in no way justify the theft of Second Life content – or any theft for that matter. Rather, they deflect discussion from the core issue that Second Life is promoted as a platform of commerce, and as such those encouraged to take up business opportunities on the platform should be offered a degree of protection that appeared to be somewhat lacking on LL’s part.

Promises and Tools

Another reason people perceived Linden Lab as having little concern over the matter was the time taken to develop practical tools that could help in the identification of potentially ripped goods. Conversations around such tools commenced in November 2006, with Robin Linden’s above-mentioned post. However, it was not until April 2008 that the first really useful tool –  the Object Inspector – finally made its debut;  18 months after the initial furore.

Now, there could be perfectly legitimate reasons as to why such a tool took so long to develop and deploy. However, during the 18 months it was in development, Linden Lab was largely silent on the matter of content ripping, giving rise to the perception that they “weren’t interested” in dealing with the issue. Right or wrong, this perception was further reinforced by the fact it was not until August 2009 – nigh on three years after the original protests – that the Lab saw fit to outline updates to their IP Complaints Process, as outlined in their Content Management Roadmap. Even then, insult appeared to be added to injury in that elements of the Roadmap appeared less concerned with the worries of current residents as they did in providing the perception of content protection for “upcoming” users of the Second Life Enterprise product.

In the meantime, CopyBot development continued among known hacker groups – such as the Patriotic Nigaras – who worked to make the tool more “user-friendly” and added further capabilities to it. While the sale of the tool was banned from both in-world and on the likes SL Exchange / XStreetSL, CopyBot does continue to be available through various torrent sites – although I understand (but have absolutely no proof) that many of the advertised CopyBot downloads are, in an ironic twist, themselves riddled with viruses / Trojans.

Viewer Threats

Throughout 2007 and 2008, CopyBot remained an issue. Exactly how widespread its use was was difficult to assess: paranoia meant that many reports of copying came via “friends of friends of friends” rather than first-hand exposure, and the storm was further whipped up by merchants selling “anti-Copybot protection” tools that were little more than scripted placebos. While such tools did little or nothing to stop Copybotting, their widespread proliferation  in stores across the grid reinforced the perception that Copybotting was epedemic in proportions.

Then the landscape started to change. In 2007, the first fully-functional third-party Viewers began to appear. Over a period of several months, a crop of Viewers showed up that offered people a genuine alternative to the “official” Viewer, which was regarded as poorly-written and crash-prone. What was more, these Viewers not only offered improved stability, they also tended to offer features that users has been requesting from Linden Lab without any success. As the popularity of these Viewers increased, so did the likelihood that the Viewer code would be maliciously hacked.

This likelihood became a reality in 2009, when the first of the “CopyBot Viewers” appeared in-world. This did raise content theft to a new level: now it was possible for anyone to grab content (with the exception of scripts) simply by using a modified Viewer – no other tools or add-ins required.

As with CopyBot itself, Linden Lab were initially slow to respond, despite the renewed outcry the appearance of these “hacked” Viewers caused. It was not until February 2010 that their Third Party Viewer (TPV) Policy first appeared.


In mid-2009 the matter almost took another very nasty turn when Jim Himoff of Rezzable suggested an in-house tool created by his company would be made available to the open source community. This tool was Builderbot. Based on the CopyBot code, Builderbot enabled entire sims to be “backed up”: land, buildings, content, textures – all in a single pass.

Like CopyBot, Builderbot was initially developed with a genuine function in mind: Rezzable had invested heavily in Second Life in terms of sim development and commissioning custom builds they have not only paid for, but have purchased the rights to as well. When they opted to make a move from Second Life to their own OS Grid, they obviously wanted to take their investment with them: hence Builderbot.

However, Himoff’s announcement of issuing Builderbot to the open source community as an unrestrained tool was alarming, and his very public claims that it presented “nothing new” as it was based on “CopyBot” and the “CopyBot was already out there” was an utterly disingenuous excuse. Given the history of CopyBot, any release of an unrestrained version of Builderbot would have been worse than mischief making – it would have been as malicious as pulling the pin of a hand grenade and tossing it into a crowded room.

Fortunately, such was the outcry over the announcement that Rezzable quickly backpedalled away from their stated intent (assuming said intent wasn’t a stunt aimed at raising Rezzable’s visibility and that of their new OS Grid offering), opting instead to develop a version of Builderbot that would include ownership and permissions protection. So far as I’m aware, no version of Builderbot has to date been released.

The Present

Most recently, Linden Lab again caused some consternation with the release of Viewer 2.0 – which had the invaluable Object Inspector completely removed. Why this was done is anyone’s guess, but it lead to some consternation on the part of residents using it – so much so that a JIRA was raised and LL reintroduced it with the first Viewer 2.0 update –  although one has to ask why it was removed in the first place.

We’re still awaiting further updates around the Content Management Roadmap – again nothing has been heard of on this subject since the August 2009 blog post, giving the (potentially wrong) impression that it has fallen of LL’s radar in the rush to get Viewer 2.0 and all things “Enterprise”-related out the door.

Currently, the subject of content ripping remains contentious. Not because it isn’t happening – it is – witness the recent XSL sale of ripped dances and Ishy Wingtips’ highly-literate and thought-provoking flog posting on the subject as it affects the Teen Grid –  but rather because the accepted perception is that copy ripping has reached pandemic levels in Second Life. This perception has resulted in a lot of misinformation to enter circulation – some of it through simple misunderstandings, some of it to deliberately derail attempts to halt the further spread of the problem.

The waters have also been muddied by the subject of “copybotting” being used to promote other agendas. Towards the end of 2009, for example, a number of high-profile content creators used the subject of copybotting to float the idea that only a selected “elite” (my term) of content creators should be allowed to operate in Second Life. Among other things, they suggested the criteria by which such creators should be selected should be related to in-world turnover – an idea that found its way into the Content Management Roadmap thus: We are starting the process of planning a content seller program, and we would like your input on possible program criteria. At a minimum, participation in the program will require that the selling Resident…..3. meet a minimum threshold for content transactions.

Quite how limiting the number of content creators to a “selected few” would stop content ripping (given their own content would clearly become the target) has never been fully explained – but the fact that their views, issued under the guise of concern about content ripping, found their way into the draft CM Roadmap is disturbing.

Beyond this, and in part due to the apparent lack of concern from Linden Lab on the matter, in-world tools to “combat” Copybotting have appeared over the years. How effective any one of these tools is, I cannot honestly say. Some appear utterly useless and smack of cynical attempts to cash-in on people’s fears. More recent tools have appeared that seem to offer a degree of protection against the use of “hacked” Viewers, but even these are subject to considerable controversy, inasmuch as a) they have been developed by former content rippers (allowing their potential effectiveness to be undermined using the question of trust), and b) the creators have been so secretive around the tools, entire rumour mills have been created around them- and not always positively.

And so we come bang up-to-date with things, and the post that initiated Peter’s suggestion that I try to summarise (!) things relating to Copybot, etc.

I think I’ve covered all the bases and key events. If I’ve missed anything significant, I apologise, and will attempt to correct any omissions / inaccuracies that are pointed out to me.

Further information on CopyBot and the furore around content ripping can be read at:

Note: Revised Mar 26, 2010 01:45 BST to better reflect the situation prior to the advent of CopyBot. With thanks to Tateru Nino for both prodding me in the right direction and for giving further information.

The road to hell…..?

I use the Emerald Viewer. Over the years I’ve used a wide range of Viewers to experience Second Life, from the official Viewer through Snowglobe to Meerkat, Imprudence, Cool Viewer for Windows, KristenLee’s Viewer  – and even Viewer 2.0 and the Snowglobe iteration of Viewer 2.0.

But it is with Emerald I’ve found my “home”; of all the Viewers, this is the most stable for my PC configuration and provides the fastest fps rate of any (although KristenLee’s Viewer isn’t that far behind. Truth be told, if KLee’s Viewer incorporated RLV functionality, I’d swap over in a heartbeat, as her rendering pipe just blows everything else to pieces on a good graphics card).

It is true that Emerald has features that could be a nuisance if incorrectly used: the ability to locate anyone on a sim and Tp right into their face is one. I’m also aware of the claims of data scraping and the like surrounding Emerald and the claims relating to it ignoring permissions (generally made by those who have not sought to actually use the Emerald export tool). But the fact is, Emerald includes much that has been lacking in the official Viewer for general users, builders and estate managers – and these make it a winner.

As such, I applaud the efforts of the Emerald Dev team in building and maintaining a versatile Viewer.

However, even good intentions can go a step too far. Today, members of the Emerald Viewer group received a Notice and attachment I’d venture to suggest is questionable.  The attachment came in the form of a wearable prim. The Text of the Notice accompanying it reads thus:

This neat little prim has certain magical properties about it that causes viewers that do not respect permissions to crash when selecting it.

We turned it into a sort of “copybot shield” you can wear.
Fractured thought you guys should have these, they won’t hurt any viewer that respects permissions.
Come by Emerald Point to see us if you liked it.

So in essence, it is a prim that can be worn and which contains a script that identifies malicious Viewers and crashes them.

Now *IF* this prim is for real (there are no visible scripts, so exactly how it detects / communicates with “illegal” Viewers is beyond my ken), then on the surface it would appear to be a neat trick in deterring copybotters. However, *IF* it is for real, the tool raises concerns on a number of fronts.

  • At the very least, it would appear to violate the Terms of Service, to whit, Section 4.1, which includes the statement: In addition to abiding at all times by the Community Standards, you  agree that you shall not: (v) take any actions or upload, post, e-mail or otherwise  transmit Content that contains any viruses, Trojan horses, worms,  spyware, time bombs, cancelbots or other computer programming routines  that are intended to damage, detrimentally interfere with,  surreptitiously intercept or expropriate any system, data or personal  information. Given this prim has the ability to crash suspect Viewers, it could be argued that it is a form of Trojan horse  / time bomb intended to detrimentally interfere with other systems
  • While copybotting is a major concern, and it could be argued that Linden Lab should be doing more to control / eliminate the worse cases, this same argument does not entitle users and /or content creators to undertake what amounts to be vigilantism in lieu of firmer action on the part of Linden Lab (and I say this as a creator of content myself). Two wrongs simply do not make a right
  • There is already a degree of controversy surrounding the Gemini CDS system marketed by members of the Emerald team – not in terms of whether or not it hack people’s computers (it doesn’t) – but rather in the number of “false positives” it has been reported as giving. Can we be sure this tool is actually foolproof, even if vetted?
  • What gives a group outside of LL the right to determine  which Viewers should or should not connect to Second Life? LL themselves are already in the process of rolling out their Third Party Viewer (TPV) Policy. While it has a number of flaws within the revised wording, it is nevertheless the official means be which the use of malicious Viewers is to be contained. What gives one or two developers who have no direct accountability to Linden Lab or anyone else the right to take matters into their own hands?
  • The means by which Viewers are added to this tool (assuming it is going to be maintained) is far from transparent. While the best of intentions may have been behind its creation, it is therefore open to potential abuse
  • What happens should a rogue coder decide to retaliate?  If this tool can be developed to target “illegal” Viewers, how hard would it be for someone to target a specific Viewer – the one supported by this tool’s creator(s)? If the tool can be worn, it can be rezzed in-world as a mass griefing tool. Do we then enter a war of escalation?

I’m genuinely curious as to whether anyone in authority at Linden Lab was consulted during the development of this tool or prior to its release. I’m also very interested to see how they respond to its presence on the grid.

Again, I have little doubt the intentions behind the tool were good. The major problem with good intentions is the manner in which they invariably pave all the roads leading to hell….