Nailing the data harvesters

There has been more sturm und drang over data scraping on the official fora and elsewhere, and I admit I’ve contributed.

Most of the focus has been on RedZone – the most visible and, given the somewhat rabid nature of its proponents, potentially most odious of them (but by no means the first). Some of these threads are simply seeking clarity on how things work. Others are more mischievous in nature, resulting in heated debate (and a wholly misplaced sense of superiority on the part of some “sunny” posters, up to and including the arrogance to inform others as to when they should post feedback).

The concerns over these tools are warranted; RedZone in particular appears to be far more about the ability to grief and stalk than it is about offering any form of (highly flawed and utterly questionable) “security”. Why else would the creator boast that the tool can attack users outside of the parcel it is protecting, that the tool can crash Viewers, etc? Why else would he made a HUD-based system that allows users to roam at will across the Grid, gather user data?

However, the risk is that in focusing on a single tool, the wider concerns are overlooked. Sling Trebuchet has attempted to broaden the issue by focusing on the technical deficiencies within the Viewer that enable these tool to work, and her JIRAs are something to support, voting coming to an end or not.

Prokofy Neva does much to raise the bar on the situation in the broadest terms, and in doing so sets out a very concise argument as to how these matters should be tackled. In doing so, Prok points out that on the broadest front, Section 4.3 is the ground on which to fight the issue, rather than Section 8.3 – which has been, it has to be said, the focus of many (including myself) when replying to posts in the official fora.

Having had time to digest Prok’s post, I have to say I’m pretty much in agreement with it. Perhaps the only divergence I have with the thinking is that I would say that both 4.3 and 8.3 have relevance, rather than dismissing one or the other as “irrelevant”.

Prok makes a very strong case for using 4.3, to be sure – but there remains the issue of those of us using Second Life having a reasonable expectation of privacy while going about our business in-world – and this is most certainly where Section 8.3 does have relevancy, even thought it might well have been originally intended to relate primarily to First Life information.

I say this because RedZone (and potentially other tools of its ilk) break down certain walls of privacy within Second Life. Leaving aside the entire hot topic of “alt linking”, they enable avatar profiling to take place and stalking to be undertaken. These are, however you look at it, invasions of our virtual privacy and should be dealt with as such, both immediately through the use of the AR system but on a broader front by bringing it to the attention of LL that as well as the wider issues relating to such tools enabling such violations of privacy to occur in-world. Thus, Section 8.3 (and potentially Section 8.2), has relevance.

The risk in focusing solely on the likes of Section 4.3 is that LL cannot be held responsible for policing third-party websites (which is in part the underlying sentiment of Section 4.3); thus too much focus in this direction can have the opposite effect as to what is desired, in much the same way that too much emphasis on Section 8.3 can allow those in favour of these tools to “trump” it using Section 4.3 or cause LL to back away with a “well, we’re really referring to RL information here,” stance.

But, this view aside, Prok’s argument for a wider basis of protest is both valid and one that we should all consider – just as we should provide support for Sling’s attempts to deal with the technical issues that make these tools possible in the first place. In this, a two-pronged response is required: the technical to deal with the exploits themselves, and a broader argument based initially on dealing with such tools on the basis of the ToS (both Sections 4.3 and 8.3) as a whole, but which is ultimately aimed, as Prok rightly states, on matters of policy.

The fact is that problems such as this – and indeed the problems that ostensibly lead to the development of such “tools” as these (content ripping, etc.), need to be approached and dealt with as a matter of policy, rather than simply on the grounds of either technological determinism or Linden Lab whim. In this, the ToS  – indeed the Community Standards themselves – cannot provide the solution alone. We really need to see LL invoke a policy in support of the ToS that will both help prevent situations such as this from occurring again in the future and provide a means of dealing with them should they in fact do so.

It’s not going to be easy, but I would support such moves wholeheartedly; kudos to Prok from framing things so well.