Tag: Second Life

Sincerely, Disgruntled of Second Life

Posted on by Inara Pey

Dear Linden Lab,

Things have never been easy in Second Life, for you, for us, for anyone. But once upon a time when you were about to start working on something that might affect us all in world, or when you discovered something was going borky, you’d have the decency to tell us. There would be a nice little blue pop-up appear in the top right-hand corner of the screen advising users of this, that or the other. When issues were resolved, there would be a nice little notice telling us so.

It was informative; it was helpful; it was reassuring to know you guys were out there, keeping an eye on things and letting us know what was going on. It gave us a nice warm fuzzy feeling inside. In short, it was communicative.

And then one day it stopped, leaving us with no option but to find out about Things Going Wrong or that planned maintenance had started by experiencing it the hard way: through teleports failing or transactions going astray or No Copy items poofing into the ether, never to be seen again.

Now, I appreciate that you cannot be on top of absolutely everything. The unexpected isn’t exactly predictable; that’s why it’s called “the unexpected”, right? I mean, I understand that. No-one can reasonably ask you to always get the word out before people start having issues and problems. But when you are aware of problems or when you yourselves are about to start Doing Things, is it really too much to ask that you actually, well, let us know in-world?

Yes, I know you try to keep us informed via the Grid Status Page and Twitter; but frankly, not everyone has a Twitter account. And even those of us who do find that having to keep one eye on it and one eye on the Grid Status Page tends to be a tad disruptive of the old immersive in-world experience we all know and love.

Surely it’s not that hard to renew the old in-world notices to all and sundry? After all, what is preferable: being told database maintenance is underway and that logins are suspended, or deciding to log out for a few minutes while you make a cuppa only to have the log-in screen gloatingly inform you you cannot now log back in?

I know which I’d prefer. So how about it? Pretty please?

Sincerely,

Disgruntled of Second Life.

Who is spamming?

Posted on by Inara Pey

We all hate spammers – you know the type, they pitch up in Group chat and fire off an IM, complete with Surl for some sale or event that has nowt to do with the Group itself. Groups with open enrolment are, sadly, particularly susceptible to these idiots.

Deeply annoying.

But, in the case of large Groups, equally annoying is the tirades that then follow said spammer as Group members proceed to gnash teeth, yowl, shakes their fists and generally react – sometimes for several minutes at a time, the comments scrolling up the Group Chat window, and, well, spamming the rest of the Group.

Yes, spammers are a PITA but I really wish people would remember that by the time they’ve pulled up the IM window, typed a reply and hit RETURN the spammer is long gone. They’ll have closed their IM window and sodded off somewhere else – if not left the Group entirely to find another target.

So, before jumping on the bandwagon of condemnation (however tempting it may be), please spare a thought for the rest of your fellow Group members who have been equally affected and try not to become as much an irritant as the original culprit.

Taking stock of your Inventory

Posted on by Inara Pey

The upcoming changes to the Marketplace – specifically, replacing the traditional in-world boxes with a Direct Delivery system is causing a lot of concern. Beta testing for the new system has begun – or is due to begin – shortly. However, even that isn’t without its problems, with people being asked – yet again – to sign-up “blind” to an NDA.

These changes to the Marketplace environment are part and parcel of a wider programme that used to go via the acronym AIS – the Avatar Inventory System. Now known as the Inventory API, this is an on-going series of improvements that are specifically targeting how inventory is handled between the Viewer, the Asset Server(s) that “store” your “inventory” (i.e. hold the “master” data for inventory items) and the simulator servers themselves. The idea appears to be to develop an extensible system that allows for better, more focused tweaking of the inventory handling code that, among other things, should allow Linden Lab to more readily identify and fix problems related to inventory management as well as making the inventory system more scalable and robust overall than is currently the case. Hopefully, this will provide:

  • A more stable inventory management environment, one that can comfortably handle active inventories of 60K+ per avatar without the current issues and frustrations people experience on hitting these levels (inexplicable inventory losses, inventory failing to load or constantly having to box-up “unused” inventory simply to get the damned inventory “list” to download to the Viewer in a reasonable space of time, etc.)
  • A more robust means of ensuring Viewer, simulator and asset server remain synchronised in terms of inventory asset data, leading to fewer user-experienced problems when moving around the grid in terms of object rezzing failures, etc.

Overall, the changes being planned are all to the good; one of the biggest banes of comfortable Second Life living is problems associated with inventory; as many are all too aware, when problems occur with inventory vanishing, 98% of the time users are effectively left to suck-it-and-see in attempts to resolve the problem using a variety of care-worn techniques such a manual cache clearing in the Viewer, frequent relogging, frequent sim hops and inventory loads – with (sadly and most irritatingly) an almost “well, t’ain’t our problem,” attitude from LL’s own help desk.

Discipline

However, the new system is not going to be all plain sailing. In order to work effectively, the new system apparently requires your inventory to be reasonably-well ordered and structured. In particular, Merchants using the new Direct Delivery system will have to have their goods specifically arranged and ordered, while there will be a limit as to the number of individual items that can be placed in a single folder (rumoured to be around the 650 mark).

Some have seen these requirements as being negative points against the new system; I have to say that personally, I find it hard to understand why. While it is true that many don’t manage their inventories that well, the fact of the matter is that we’re actually provided with a basic system of default – and protected – folders for inventory items by Linden Lab themselves (Body Parts, Clothing, Objects, etc.), which can be readily used to create a well-ordered  inventory system, providing one applies a little discipline.

I also suspect that the majority of merchants are like me, and already have a well-defined folder structure for their goods. While such systems more than likely won’t meet the requirements that the new Direct Delivery system, they do mean that merchants already have the necessary self-discipline to get their products sorted and ready for the new system. For others, many people already use the #RLV “shared folders” system – and not necessarily for BDSM-related items (although this is obviously its primary use); so again the concept of a well-ordered inventory may not be so alien to people as some may think.

Whether the new system will require an complete overhaul of a person’s inventory remains unclear; we’ve had the Client-side code in both Viewer 2.x and Viewer 1.x for night-on two years now with it impacting on everyday inventory manage, so again, undue critique of AIS / Inventory API in the widest sense  may be a little premature. And even if the new system doesn’t require widespread changes, for those that tend to leave everything in the top level of their inventory after unpacking (i.e. in folders directly under MY INVENTORY), the fact that Linden Lab are taking steps to try and make the inventory management system more robust might be seen as a reason to perhaps get things sorted.

If nothing else, the default folders provided by the Lab have a big advantage over user-created folders: they cannot be accidentally deleted. Ergo, moving, say, all of one’s clothing folders under CLOTHING, gives one (albeit small) measure of protection against accidentally right-clicking on a top level folder and deleting it and then purging it from Trash before you’ve taken stock of what you’ve done. Furthermore, and while I admittedly have no first-hand experience of this (I’ve always kept a very well-ordered inventory), there is much anecdotal evident that ordering your inventory within the default folders provided by LL decreases the chances of items becoming lost or vanishing.

Yes, there are issues around  some  of elements of the AIS / Inventory API – such as the Direct Delivery system  – in terms of the impact they’ll have elsewhere in Second Life (such as the impact on in-world stores on a variety of levels, some of which I touched on in my post on Direct Delivery itself. However, I’d respectfully suggest that such concerns are more a part of a wider dialogue that is required about the Marketplace in general, and its potential impact on in-world revenue streams – including LL’s tier-derived income – rather than restricting them to discussions on AIS / Inventory API in and of itself.

At the end of the day we’ve all suffered from inventory issues at one time or another. Given the woeful track record from LL in terms of helping people deal with the issues they encounter – such as frustratingly being able to see a portion of their inventory but be unable to use it, simply because the current system has “moved” folders up to the same level as MY INVENTORY, and thus made them inaccessible – then I’d tend to take the attitude that anything that comes along that decreases the chances of such errors occurring in future and which more readily enable LL to rectify inventory errors is to be welcomed; any additional effort required on our part to help get the system working more efficiently notwithstanding.

Why I’m pissed at RedZone

Posted on by Inara Pey

Yesterday, while in-world, I was in IM with a friend, and I mentioned developments regarding the RedZone farrago. The question that came back, after I gave a 3-line summary, was: “Why are you hung up on all this?”

The question wasn’t followed-up with the usual “but IP Addresses are public, blah, blah,” (irrelevant), or simple platitudes  – it was a question to why it affects me so deeply, given I tend to move around SL without the benefits of media anyway (doubly so now, as my friend knows – as does so herself).

To be honest, the question gave me pause. Why am I so all-fired angry about RedZone and Quickware and the rest? Drama is a part of being in SL, and the very nature of the platform means it will always bring out the worst in some people – so why let it get so under my skin?

Well, simply put, because the platform does enable people to abuse one another so readily. RedZone is created by “zFire Xue” – but who the hell is “zFire Xue” – other than (to you and me), a totally anonymous individual who – ironically – hides behind avatar anonymity while trying to “out” you and I in terms of linking out avatar details with our RL locations.

Worse still is the loudest proponent of RedZone, someone who bangs on about his “right” to use it, denigrating all who oppose his as “griffers”, revels in his ability to create mischief – and yet hides behind the veil of the anonymous pseudonym “Crackerjack”. That such people are empowered by their anonymity (and fail to see any contradiction between their own use of pseudonyms while seeks to “out” others), and use it as a weapon against others on the grid pisses me off.

While Linden Lab have responded  – are responding – to this latest situation, I’m also equally pissed off with them.

Security within Second Life has always been lax; while there have been many (and very excellent) reasons for opening up things like the Viewer to open source, encouraging in-world development, looking towards potential business uses of the platform, the Lab has always taken a far too simplistic approach to matters, trying to having a all-in-one solution (the main Grid) attempt to meet a plethora of markets and uses they’ve repeatedly scampered after.

As a result, they’ve been lax in properly identifying the risks to security and privacy inherent in many of the decisions they’ve made, and policy and terms of service have been left woefully ineffective when it comes to dealing with serious concerns. Again, one only has to look at the contradictions in ToS 8.3. and 4.3 with the RedZone farrago to see how contradictory their own legal documents are in these matters.

It has always been this way; I have no idea if it is “west coast culture” (as some claim), or the “Tao of Linden”, a complete lack of concern (so long as the dollars roll in) or pure ineptitude that repeatedly prevents Linden Lab grabbing issues such as this by the balls and simply doing the right thing and stopping it. What I do know is, it is wearing people down. People have left SL over this latest controversy. Others are giving up and retrenching, reducing land holdings, minimising their financial exposure and the rest, simply because the Lab fail to grasp the nettles in their backyard and remove them.

Even now, with a revision to the community standards in place, we’re still seeing creators of these scanning tools working hard to try to get past the ToS, the new media filters and the likes; yet they continue to request ARs on a case-by-case basis.

Many reasons have been theorised as to why this is the case – but the fact is, as I’ve said elsewhere, technical solutions ain’t gonna solve this problem – or any other problem where users within SL get an elevated sense of entitlement they believe allows them to violate the ToS (or indeed, simply come up with a flim-flam system that appeals to those with such a false sense of entitlement in order to get them to part with their cash). If this issue is to be resolved, it’s going to require a clear-cut policy statement from Linden Lab. Period. It’s a policy statement that has got to be enshrined as a part of the ToS, and put up in lights for all to see. It needs to a clear Thou shalt not backed by the unequivocal reality of permabans.

And if we’re honest here, the RedZone situation has more than demonstrated what needs to be done – yet all we get is a token (and unadvertised) change to the Community Standards relating to the sharing of gathered data; not its collection.

And this is another reason I’m pissed off: tools like RedZone already have the potential to allow sick minds to start profiling avatar movements. RedZone even has a HUD users can wear that has the potential to gather information on avatars they encounter. Even with the “sharing” aspect being “disallowed” under the CS, these tools could still be used to gather information – and make it available outside of SL – for those wishing to stalk, spy and grief, as I mentioned in my original post on this matter.

We need a policy that simply outright bans the use of such tools unless used in very tightly proscribed circumstances. Don’t get me wrong – I’m pleased that LL have made some moves on this matter; it’s great that they are adopting the media filter. But unless and until they draw up a clear-cut policy on situations like this, the problem isn’t going to go away, and more and more innocent users are going to fall afoul of those who would prey on them.

And that brings me to the core reason why I’m so “hung up” on RedZone. Last night, after my friend had asked me her question, I dived into the ongoing discussion on the subject over at SLU, and I read this:

“Well I haven’t logged in a while over the head of all of this. It’s hard to be fancy-footed and carefree, skipping to whatever music is playing when in the back of your head you’re wondering if you’re being scanned or if there’ll be an argument just around the corner. Shouldn’t worry too much I know but sometimes we’d just like everything to be perfect in the world if only for a moment. Forlorn hope possibly and no doubt a little rose tinted but imagination brings those expectations for me in SL and hope is such a hard one to let go of.

“I’m even downloading the Windows SDK to build snowstorm just so I can get some of that nirvana back sooner rather than later. And no, I’ve very little clue what I’m doing other than following outdated wiki pages and scouring snippets. I hear ‘geek’ is the new sexy so it may serve a purpose in the end.”

This simple statement cuts to the heart of the entire matter: Second Life should be a world where our imaginations can be set free, where we can feel secure enough to wander, explore, enjoy, experiment and simply be without the constant worry of who might be lurking around spying, scraping, scanning and pawing at us. Of course, we cannot ever be totally secure – you don’t even get that in real life – but we should have the confidence that those who effectively provide and safeguard Second Life – Linden Lab – are actually ensuring our safety as far as they possibly can.

But they’re not as yet, and their track record suggests they won’t. That hurts people such as the poster above. It hurts you and it hurts me. And that’s why I’m so “hung up”.

Master accounts

Posted on by Inara Pey

This idea is not new. Indeed, even now, I’m coming to it later than others, like Ciaran Laval, who posted at the end of last month on the subject. But it is worth repeating here.

Second Life needs Master Accounts

This idea was first put forward a good while ago, under JIRA MISC 2222. Argent Stoncutter has revamped it under JIRA SVC-6212. This idea has significant benefits for personal security, and general SL use:

  • Accounts could be gathered under a single master account, which instead of logging you directly into SL, allows you to select which avatar you wish to use under that account, as Argent explains: so for example instead of logging in as “Argent Stonecutter”, I’d log in as “Argent007” or something that isn’t actually published… and then picked my “Argent Stonecutter” alt from a pulldown.
  • This master account would be far more secure, as the account name would never be publicly seen – once an avatar name is selected, the avatar’s name is all that is visible. Thus, accounts would be better protected from hacking (at the moment hackers already effectively have your account user name (avatar name) – and so are off to a head start. It’ll also reduce the overheads needed for overall account and password management for both the user and LL.

Potentially, the benefits go a lot further than this:

  • Linden dollars could be held in terms of the Master Account, regardless of which avatar buys them – and thus available to all avatars under that account, without the need to transfer funds between them
  • Inventory could be potentially linked to the Master Account, and also made available to all avatars under that account, with content creators capable of setting permissions so that items cannot be shared between Master Accounts
  • Age and account verification are simplified: verify the master account, and all avatars under that account are “automatically” verified.

The master account could be structured in such a way that there is a limit to the number of alts that can be created under it (perhaps, as a finger-in-the-air-figure: eight alts per master account), together with a limit on the number of “free” master accounts which can be created per user.

While this would not stop those determined to create mischief on the grid (griefing and copying), it could help reduce the need  / drama around sensitive topics such as “alt outing” as exemplified by the recent RedZone farrago: LL can ban by master account, instantly banning all avatars under that account.

Indeed, this could be extended into things like estate and land tools, helping land owners ensure, again, that a parcel / sim ban against one avatar is automatically (and invisibly as far as the land owner / sim owner is concerned) applied to the avatar’s master account, thus blocking all alts associated with it.

The idea is one, as I’ve mentioned, that has been raised before, only to remain in limbo. JIRA SVC-6212, however, seems to have traction in LL, with Yoz Linden commenting:

We would dearly love to have unified account ownership, for several of the reasons already outlined. However, do bear in mind that it would require significant changes to many parts of the infrastructure, especially in the billing systems. That’s not to say it’s not going to happen; on the contrary, we’re actively trying to move in this direction. Just saying that it’s noted, we agree because we’ve wanted something like this for ages, but it’ll take a while.

Given all the recent heartache and upset that has surrounded RedZone, I would strongly urge everyone to get over to the JIRA and support (watch) SVC-6212.  It stands to benefit every single person using SL.

RedZone and security: separating fact from fiction

Posted on by Inara Pey

The mills continue to churn on the matter of RedZone and its ilk. As such, I thought I’d pause for breath and try to sort some of the wheat from the chaff for those still confused. I’m deliberately avoiding any attempt to delve deeply into the more questionable aspects of RedZone and its data-gathering, and focus on the raw facts in the hope of illuminating the bare bones of why RedZone has little or no legitimate use in matters of security.

Myth 1: RedZone prevents copybotting

No, it doesn’t. It doesn’t even deter copybotting. RedZone attempts to identify known malicious viewers – which sounds good until you consider the following:

  • Anyone seriously engaged in content ripping (aka copybotting) knows how to hide the identity of the Viewer they are using so that it appears to be perfectly legitimate – thus RedZone cannot identify it. They can therefore create an alt, enter a sim, be scanned a “legal” and still copy items on display
  • Copybotting existed long before the Viewer was open sourced. As such, while the Viewer is the most convenient way to rip content, it is not the only means. The code for content ripping is still available to those that want to use it. There are also software applications that can be used for certain types of content theft. RedZone cannot even detect such activities – much less stop them- RedZone cannot even detect, much less stop them
  • RedZone works on the assumption that the Copybotter will actively engage in theft within the shop. Some may – and will likely avoid detection, as noted above. However, the simplest way to copy something is to legitimately buy it and then rez and copy it away from the store, rendering RedZone pointless.

So, don’t be fooled. In terms of “stopping copybotting” RedZone will be about as effective as using a wet paper bag to stop a bullet. At L$3999 a pop, that’s an awfully expensive wet paper bag…

Myth 2: RedZone prevents griefing by alts

RedZone is no better than any non-invasive (and cheaper) security tools for stopping griefing. In many respects, it is actually worse.

Much is made of RedZone’s ability to “identify alts” and so “stop griefers returning”. While this makes good reading, let’s look at the facts.

RedZone uses a method of obtaining avatar data and IP addresses (through a media stream exploit) and then compares results, the “theory” being that if two avatars have the same IP address, they “must” be alts of one another. BUT…the system ignores the fact that the vast majority of IP addresses currently in use are dynamic and can be changed frequently.

For example, I can turn my router off for 3 or more minutes, and when I power it back on again, I have a “new” IP address assigned to me by my ISP – an IP address that was previously been used by someone else possibly in the same general geographical location as me, but certainly using the same ISP.  This means that potentially:

  • *If* I were a griefer, I could avoid detection on a sim using RedZone simply by forcing my ISP to assign me a new IP address and then creating a throw-away alt.  There is a better than even chance that RedZone would not detect me, leaving me free to go about my dirty business
  • As someone who does not engage in griefing, I could be innocently accused and convicted of the crime, simply be because my ISP has assigned me a dynamic IP address that was previously associated with a “griefer”

RedZone further fails to acknowledge the existence of “block” IP addressing – such as might be used within an office building, or in an apartment block or by an Internet cafe, and so on. This means that if *one* person is identified as a “griefer” on that IP address – then all users of that IP address “must” be alts of the “griefer” – and are therefore banned.

And if that weren’t enough – RedZone does not distinguish between accounts on the same IP address. Thus, if one person in a household decides to do something silly, then can end up being banned as a “griefer”  – along with the rest of their household.

Proponents of RedZone will say this is acceptable – in other words, condone “guilt by association” – for the “greater good”. Yet all they are actually doing is potentially banning customers from their shops and patrons from their venues. Again, the genuine / serial griefer can circumvent RedZone as easily as the serial copybotter.

Myth 3: RedZone provides better land security features than other systems

No, it doesn’t. For general land security – keeping out unwanted visitors, preventing “casual” acts of “griefing”, removing troublemakers, etc., RedZone offers no more than can be found – free of charge – in the land tools available at parcel level, or at estate level if you own a sim. Using the land tools you can ensure:

  • Residents with no payment info logged with LL (directly or via PayPal) cannot access their land
  • Residents who are not Adult Verified cannot access their land
  • Residents who are not Adult Verified and have no payment information registered cannot access their land
  • Only members of your own Group can access the land.

These options alone should deal with over 99% of potential issues around security. And even if there is the occasional issue with a troublemaker, all parcels have a simple-to-use Ban List.

Similarly, griefing objects can be taken care of  simply by:

  • Restricting object creation / rezzing to Group members only
  • Restricting object entry to Group members only
  • (Worst case) restricting script running to Group members only.

These three steps alone eliminate the means by which the majority of griefers operate.

Sim owners can similarly restrict access to their sims – and in the case of residential sims, restrict access to multiple Groups if they wish, to save having everyone living on the sim a member of “their” Group.

If, for whatever reason, estate / land tools don’t work for you, then there are a number of items out there specifically developed for land security, none of which require your visitors / friends to be surreptitiously scanned. I’ll name two here, because I’ve used them for the last 4+ years at both parcel and sim level with great success:

  • Psyke Phaeton’s outstanding PDS Home Security orb – offers both parcel and sim-level solutions
  • Thomas Conover’s Land BodyGuard HUD, which provides sim-wide protection plus remote access to functions (you don’t have to be on your sim to ban someone, similarly, you can ban someone who is not physically present on the sim at the time of banning (because, say, they’ve created mischief and run away). It can be fully integrated with the SIM Radar system, if required – and both for half the price of RedZone. Find both in-world here.

These are just two systems. There are many more. All are cheaper that RedZone, and all carry out their functions without the need to covertly scan your visitors, as stated, nor do they lead to additional angst and drama over people being incorrectly accused of being alts of one another or having information about them stored on a third-party database outside of SL (which would most likely cause them considerable upset were they to be told this is in fact the case).

The facts that do count with RedZone

  • It cannot prevent copybotting. The most it can give an a false sense of security
  • It may deter the odd griefer, but not those who make griefing a habit
  • It offers an expensive solution to the problem of land security costing far more than dedicated land security tools that offer the same functionality
  • As a basic “security tool” RedZone is invasive of people’s privacy that sends avatar information to an insecure 3rd party database. As such, and given its use is detectable, all it is liable to do is encourage people to stay away from those stores / venues where it is used.

As I said, I’m not using this post to delve into the deeper and more distasteful elements of RedZone or the unethical behaviour of its creator following recent revisions to the Second Life Community Standards. These are all public knowledge. Rather, I’m hoping this post will simply give pause to those who have RedZone, or who are considering it, so they can ask themselves if it is really worth L$3999 when something costing L$750 will do the job without embroiling them in the wider aspects of the RedZone situation.