Someone cue up Taps....

"Emerald Viewer Blocked From Second Life

Dear Second Life Resident,
As of 10am PT Wednesday, September 8, the Emerald Viewer will be blocked from logging in to Second Life as a result of violations of our Policy on Third Party Viewers. Residents who have been using any version of the Emerald Viewer will need to use a different Viewer to access Second Life.

You can download the official Second Life Viewer, developed by Linden Lab, here. Or, you can learn more about alternative Viewers, developed by third parties, here.

Please be aware that attempting to circumvent our blocking to access Second Life with a banned Viewer is a violation of the Policy on Third Party Viewers and may result in the loss of one's account. For more information, please read the blog post.

Joe Linden
VP, Platform & Technology Development"

 I love the wording in that blog post, by the way... <insert sarcastic smile here>

Rather than make it seem like they saved SL from some great peril, why not just say something more along the lines of  'We wanted them to do A, B, and C in X amount of time, in order to right the wrongs and pay their penance according to the guidelines we set out for them. They weren't able to get it done, and the repercussion for that is we're blocking the log ins of the viewer." I guess that wasn't melodramatic enough *bites bottom lip*.

Farewell Emerald Viewer, it was fun.

*Waves buh-bye as she opens Phoenix and carries on with her SL* ...What, you didn't think I'd desecrate my computer with Viewer 2 did you?

*Smiles*  ~ Krisy

Missing Comments?

I woke up to a message on Skype indicating that there are comments that may have been missing from one of the blog entries. In response to this, I want to assure everyone who's commented that I don't intend on censoring the comments made here, whether I agree with them or not, without really good reason. However, until I can figure out (I'm still new to this website, still learning everything) what happened with those comments in question, I'm changing the way the comments are allowed. For the time being, there will be no 'anonymous' comments, and I've chosen to have the comments all go through me first, and then I will make sure they go up.

So basically: I am the only one who should have the ability to remove any content on this blog. I did not remove anyone's comment, as I've been asleep for the past nearly four hours. Until I can figure out what happened, everyone who wants to comment will have to sign in via one of the options that Blogger gives.

Guest Blogger: Mindy Spiritor

The Big Picture:  Look Beyond the Trees.

If ever there were an appropriate time for cliches, this moment in Second Life history is a prime candidate for “you cannot see the forest through the trees.”  In the case of the Emerald “scandal,” the trees have been stared at, chopped down, shredded, reconstituted, and still not yet drained of all perceived viable uses, yet even still the community as a whole cannot take their eyes off the trees for one moment long enough to see the big picture.  In fact, I’m not sure most people even realize that there is a big picture, and I find this depressing.  Oh I see your perplexed faces behind those computer screens as you read this asking yourselves, “what the hell is this woman on about?”

The trees I’m referring to are the various issues that I’ve seen beaten to a bloody pulp in-world and all over the internet during the last few weeks with respect to Emerald--emkdu, DDoS, data-mining, banning, blocking, user safety, the Third-Party Viewer Policy (TPVP) and its Directory (TPVD), the viability of Emerald, and so on and so forth.  I’m in no way delegitimizing any of these discussions any more than one could suggest a forest doesn’t need trees.  However, with what appears to be the heart-breaking demise of a viewer enjoyed by roughly 125,000 unique users each  day, and the information that has come to light during that process, it’s high time people shift their focus and start looking at the bulldozers surrounding the forest. 

Now, before I delve into the big picture, I think it wise to give you some facts about me and my perspective through all of this, since, quite frankly, many of you don’t have the foggiest idea who I am and have no reason to listen to my ramblings or give them any credence whatsoever.  I’ve been deeply involved in Second Life for a year now, which for me, is long enough to know a thing or two, but not so long as to be completely jaded or have developed an “I know it all” attitude.  If memory serves, I’ve been an Emerald user (erm, that makes me sound like some crack addict *laughs*) for about 6 months.  Despite loving the viewer, I still attempted to use Viewer 2.0 when it came out and nearly gouged my own eyes out after 15 minutes.  I joined the Emerald Support Team *drum roll please* the week before the DDoS news broke.  Prior to getting involved in the Emerald Viewer group, I had no history with any of the Emerald Development Team or the Support Team for that matter.  I had no personal vested interest in the Emerald Viewer except for one thing, and one thing only--its community of users, for whom their preferred viewer is what helps make their Second Life experience that much more enjoyable. 

My stated vested interest has been the only thing that’s driven me through this time, and for the last couple of weeks, I, along with the entire Support Team, have worked tirelessly to continue to provide the best support we could to our users.  Throughout this entire affair I believe I have remained rather even-handed in the positions I’ve taken.  I have been both supportive and critical of several members of the Emerald Development Team on both sides of the internal conflict that lead to the end of the project.  I never assume anything as fact or truth without having the information necessary with which to base my own opinion or come to my own reasoned judgments. 

So after having said all of that, here is my reasoned judgment of the “trees” that make up the recent Emerald events.  Although it may have been the actions of one or a few who truly caused the downfall, the Emerald Development Team failed as a whole in allowing a structure to persist that created the opportunity for what has occurred.  I’m not passing judgment on anyone personally, and actually have a large degree of respect for most of the team, some of whom I am now proud to call friends. Rather, I have come to the conclusion that those who acted to rectify the wrongs did so too late and after too much sordid history to have any reasonable chance of saving it.  This is a testament to what happens when a group of people manage to successfully create something bigger than themselves without ensuring a system of transparency and accountability necessary to serve as a check and balance on individual behavior.  For that, and for the breaches of trust that resulted therefrom, the project earned much of what it got in terms of the strict requirements to continue functioning in Second Life.  Notably, most of the team rather gracefully accepted that fact, sucked it up, and put nose to the grindstone to try to accomplish the impossible. However, there can come a time when the punishment is no longer reasonably related to the “crime.”  I have witnessed Linden Lab change the rules along the way and go too far in their demands, and it became patently clear that this was not simply about user security or trust. 

Finally, I come full circle back to the forest.  While the vast majority of you are still bickering and debating the trees, Linden Lab has parked bulldozers outside the forest.  Let’s examine this a bit closer, shall we?  The Lab's original reasoning for requiring Emerald to remove emkdu from its viewer is that it is not GPL compliant:

The Emerald viewer’s closed source emkdu library is not in compliance with the GPL.  Bring all current and future versions of the Emerald viewer into compliance with the GPL by omitting emkdu.  Use OpenJPEG or other GPL-compatible code.

Despite this issue never being raised before or during Emerald’s listing on the TPVD and the reasoned disagreement between those intimately familiar with the GPL as to the accuracy of that assessment, I can still swallow this as a “legal” excuse for preventing what might otherwise pose a security risk to users.  Keeping in mind that the emkdu file was used to gather private information from the user (full path names), it is fair enough and understood, although I’m unclear as to why the Lab couldn’t simply use that fact alone as the reason for their requirement.  That is, of course, unless there are other motives behind the stated justification that go beyond just Emerald.

After issuing their written list of requirements to Emerald and just days before the deadline for compliance, Linden Lab changed the rules.  The Lab informed the Emerald Development Team in a meeting that in addition to removing emkdu from the installer package, the viewer code itself must be re-written to remove the calls necessary for the viewer to use any such file, including llkdu.  In other words, for those of you who have enjoyed the ability of copying and/or downloading llkdu and dropping it into your chosen viewer installation, the llkdu file would simply no longer be used by the viewer because the code wouldn’t “see” it.  Certainly, Linden Lab isn’t concerned about viewer security in utilizing their own Kakadu library, so what is the justification for this new rule?  The Lab claims that upon further review, they seem to have “misinterpreted” their Kakadu license, and that the license does not permit distribution of llkdu. Accordingly, Linden Lab informed the Emerald Development Team that this new coding requirement is going to be added to their TPVP.  In other words, every TPV will be prohibited from containing code that calls up llkdu for use and will only be considered compliant with the TPVP if it’s using openjpeg or “other GPL-compatible code.”  Phrased another way, TPVs containing code that calls up llkdu for use could be considered illegal and malicious viewers, subject to banning.  For those of you who question the accuracy of this information, I can only tell you that the members of the Emerald Development Team who were present at the meeting with Linden Lab separately confirmed this information.   Notably, this includes members who were  on very opposite sides of the conflict that ultimately resulted in the end of the project.

From what I understand, many TPVs have relied upon Linden Lab's distribution of llkdu to improve their rez times and texture handling.  There is no question that for some, being forced to use openjpeg in their viewer will not make a huge difference in their SL experience.  However, there are many users, myself included, who find it excruciatingly difficult to function in the SL environment using openjpeg, which is not prepared to efficiently handle texture rendering in many ways.  Countless users find themselves living in a mostly grey and clouded world, while others suffer with completely corrupted textures.  Just ask the rest of the Support Team about the barrage of problems we encountered from users who were running openjpeg after the release of Emerald Viewer Beta 2587 and how easily most of those problems were remedied with use of emkdu or llkdu.  From my experience on the Support Team alone, I could write you a list longer than this blog post. 

There was a time when the discussions were properly focused on Emerald, what transpired, and what would be done to remedy or deal with the breaches of trust.  That time has now passed.  With the much anticipated blocking of Emerald Viewers, its users are clamoring to find an alternative viewer they can live with.  The vast majority of Emerald’s users came to discover it because of dissatisfaction with the Linden Lab viewer, a movement that increased to a large degree after the release of Viewer 2.0.  Therefore, the thought of going back to those viewers has caused sheer panic and chaos.  Many are attempting to quell the panic with the comfort that there are several other TPV options available to them, even if not entirely comparable to Emerald.  Are you seeing the forest yet?  While features are certainly deeply important to users, it’s almost undeniable that the availability of the lldku file to offer comparable or even improved rez times than that of the Linden Lab viewer has become somewhat of a foundational level of functionality for TPVs to build around....but the bulldozers are parked outside. 

There is no question that Emerald opened the door to its demise, but if you think for a moment that Linden Lab isn’t milking this opportunity for all that its worth to rid the grid of its competition, I’m afraid you may be sadly mistaken.  If you do not start asking the right questions now, the bulldozers will have flattened your chosen viewer before you ever saw it coming.  Even if you think I’ve completely bought the farm on all of this, before you pass final judgment, I implore you all to please take a moment and ask yourselves and others the following questions:

1. What legitimate user security purpose is served by requiring Emerald to remove a call to llkdu, when that is the file users are to trust as it belongs to Linden Lab?
2. Given that Linden Lab has permitted the use of llkdu by other TPVs for quite some time, why are they suddenly interpreting their Kakadu license to prohibit it?  I, for one, would love the opportunity to read the relevant portions of that licensing agreement.
3. In light of the potential change in the TPVP regarding llkdu, will other TPVs be permitted to license their own Kakadu libraries as Emerald did with emkdu?  (Remember that Linden Lab now claims the use of such closed-source libraries would violate the GPL).
4. If, in fact, the GPL prohibits use of such closed-source libraries (I’d start questioning this position as well by the way), does this mean Linden Lab will now also prohibit TPVs from using fmod and vivox for media and voice?  If not, what makes the Kakadu library different from other permitted closed-source files?
5. If you cannot get reasonable and satisfactory answers to the above questions, then you really must ask yourself, what exactly is Linden Lab's motivation at this point with respect to TPVs and do their actions coincide with their public statements in support of them?

 If you’ve made it to this point still questioning my information or position on this issue, two more recent developments may be of interest to you.  First, I personally inquired of Linden Lab as to their plans to cease distribution of llkdu and to modify their policies to prohibit TPVs from containing code that calls up the llkdu file.  In what I consider to be classic corporate non-speak bollocks, today I received the following reply:

If we decide to stop distributing llkdu and/or make changes to our Third Party Viewer policy, we will make an announcement via the official SL blog.

Second recent development--the just released Phoenix Viewer does not contain code that calls up the llkdu file, because they were advised of the intended change to the TPVP as I indicated above.

If at this stage, you do in fact see the bulldozers outside the forest, what are you going to do about it?  Don’t ever lose sight of the fact that although we would have no Second Life without Linden Lab, they too would have no Second Life without the users. However, Linden Lab can never be effectively called to task unless and until the users are willing to remind them of what a vacated Second Life would be like.  It is, after all, a business and bottom line matters.

The "Phoenix" has risen...

I woke up today to a frantic message on Skype asking where I was and being told I was missing a big story. So I read what had been pasted to me, and the first was a resignation letter from former Emerald Support team member Nisa Maverick... In that was an interesting link which I'll get to. The second was from Jessica Lyon's blog with her latest post entitled "From the ashes...." which I'd encourage you all to check out if you haven't already.

Former Emerald users now have a new project to support, the Phoenix Viewer. The website is http://phoenixviewer.com where you can get a copy of the download for your computer. I've decided to download and install it so that I can accurately blog what I see, given that I expect Emerald log-ins to start being disabled next week, possibly Monday at the earliest (and note that this is my own guess, not something that's been confirmed). Want to know what I've found with this first release of Phoenix Viewer 1.5.0.1? Keep reading.

I've found my replacement for Emerald. I have all of the basic features that I had before, such as sim-wide radar, building tools, spam blocker, tattoo and alpha layers, the two-page menu for Phoenix specific settings, and yes, for those who will undoubtedly ask, the enhanced breast physics option is still in place. I don't personally use that feature, so I haven't tested to make sure it's functioning, but it's there. The recent popular 'tag color' feature doesn't seem to be working in this first release, but I feel that's a minor feature, as it doesn't really affect viewer performance. "Get More" in the Skins preference tab doesn't appear to be working at this point in time either, so if you have problems with the 'Gemini' skin that appears to be the default on first load up, you still have two other default options with "Default" and "Silver". I still had my preferred "Metallic Blue" skin available, but it's possible that it's due to the fact that I had installed it on Emerald, and still have my 2587 copy of Emerald installed on my system.
[Edit: one of the support team offered this information regarding skins: " users need to make a copy of the entire skins folder, then they can safely delete emerald.  Then when they reinstall they can add the skins folder to the Second Life user settings folder". Note that this will only carry over the skins you had while on Emerald.]

Also, I must note that Phoenix does not access kdu files at all, instead they use the OpenJPEG library as shown in this comment from the "About Phoenix" window: J2C Decoder Version: OpenJPEG: 1.3.0. It seems concern may have been premature regarding the speed of rendering with OpenJPEG, as I didn't see any real difference in my rendering time. Although again, I still have 2587 on my system and the texture cache wasn't deleted prior to my installing and logging in with Phoenix. I'll also point out that with this viewer being in it's infancy and still not known about by likely the majority of current/former Emerald users, the rendering time may also not have the anticipated load on it at this point in time.

I took a moment to upload an image of the interface, it should look very familiar to Emerald users. The only things I blurred out were my location and my linden balance, as I didn't deem either necessary to include. As you can see there, you're dealing with the same interface, basically the same options, and at this point what seems like nothing is lost when you make the transition.

Take the time to check it out, decide for yourself, and know that hope is not lost. For those who are interested in making the change but have questions, and for those who choose to go to Phoenix, there is an inworld support group already established, Phoenix Viewer, which is open join and can be found in my profile as well as the Phoenix team's.

As always, thank you for reading.   ~Krisy

He said WHAT?!? This might take a while o.O

Now making it’s way through various interweb channels is a notecard with two separate but related conversations between Loney Bluebird (aka Phox) and Soft Linden. The majority of us will read them and say ‘I don’t really know what it all means, but it doesn’t sound good.’ and they’d be right... but not in the way they’d initially think. Read on to see what I mean.

2010-03-18 16:41:57]  Lonely <3: Speaking of which, has Fractured mentioned EmKDU/OnyxKDU to you at all?
[2010-03-18 16:42:12]  Soft Linden: Nope
[2010-03-18 16:42:46]  Soft Linden: We haven't talked much of late. I think he was annoyed that I offered to rename groups for the *Life viewers, after asking him to get clearance from Kyle for a group rename before
[2010-03-18 16:43:19]  Lonely <3: Ah, well, we needed some way to identify people using our kakadu library, we came up with something really clever: The Emkdu variant encodes the window title into the j2c comment.
[2010-03-18 16:43:32]  Soft Linden: Nice!!!
[2010-03-18 16:43:41]  Lonely <3: The OnyxKDU variant contains the other end of the cipher, and an exported function to retrieve said comment.
[2010-03-18 16:43:44]  Soft Linden: I'd figured that library would be the place to hide things. So it shows up in their baked texture.
[2010-03-18 16:44:07]  Lonely <3: Yup, Linux variants encode 128 characters of the path, since window title depends on window manager etc.
[2010-03-18 16:44:27]  Lonely <3: I've got it nicely tied in to the radar here, it's fun to see the various names I get when all I see on people is a shiny emerald tag.
[2010-03-18 16:44:45]  Soft Linden: I'd look at other places you might store that. We were at least planning to start encoding some info there to help us with DMCA takedowns
[2010-03-18 16:44:56]  Lonely <3: We caught the HXO/Sl Black edition creator that way.
[2010-03-18 16:45:11]  Soft Linden: Does the jpeg2k format support arbitrary tag/value pairs?
[2010-03-18 16:45:12]  Lonely <3: Hmm, well there are various places we could encode that.
[2010-03-18 16:45:21]  Lonely <3: Yes
[2010-03-18 16:45:25]  Lonely <3: At least I think it does
[2010-03-18 16:45:33]  Soft Linden: You could make something misleading like "encode parms" or w/e
[2010-03-18 16:46:38]  Lonely <3: Unless someone starts poking at it with a disassembler all they'll find is a string of mixed printable and unprintable characters in the comment.
[2010-03-18 16:47:18]  Lonely <3: We figured it was a good way to keep track of who's using the proprietary library without a license, not to mention identifying those viewers that want to hide, which is always a goal.
[2010-03-18 16:47:29]  Soft Linden: :3
[2010-03-18 16:47:33]  Soft Linden: I love that you guys are doing this
[2010-03-18 16:47:55]  Lonely <3: Saves you guys some work I guess.
[2010-03-18 16:49:01]  Soft Linden: I'd also be inclined to get the end of the path for Windows & Mac builds too. Odds are people are going to rename the viewer filename, even if they don't change the window title, etc
[2010-03-18 16:49:12]  Lonely <3: Yeah that's what I said >_>
[2010-03-18 16:49:15]  Soft Linden: just w/e is in **argv
[2010-03-18 16:49:19]  Lonely <3: Zwagoth and Fractured wanted the window title.
[2010-03-18 16:49:19]  Soft Linden: I thought you said you just did it on Linux?
[2010-03-18 16:49:27]  Soft Linden: Gotcha.
[2010-03-18 16:49:32]  Soft Linden: Yeah, I'd shoot for both.
[2010-03-18 16:49:35]  Lonely <3: Only because linux doesn't offer a single function to grab the window title in all window managers.
[2010-03-18 16:49:55]  Lonely <3: Yeah I know the path is more useful.
--- next conversation---
[2010-03-25 16:35:40]  You sense a disturbance in the force...  (Soft Linden is typing)
[2010-03-25 16:35:51]  Soft Linden: Are the marked textures in the current release version?
[2010-03-25 16:36:01]  Lonely <3: Yes
[2010-03-25 16:36:06]  Soft Linden thumbsup
[2010-03-25 16:36:27]  Lonely <3: After we spoke I decided to make a bit of a change to kdu
[2010-03-25 16:37:40]  Lonely <3: I made it check the top corner of the image for transparent pixels, if it finds any it encodes the folder name like the linux lib originally did.
[2010-03-25 16:37:50]  Lonely <3: If not it encodes the window title.
[2010-03-25 16:38:28]  Soft Linden: ah cool hack :3
[2010-03-25 16:38:56]  Lonely <3: That hasn't been released yet, but it can go out at any time since the pack is seperate from the binary.
[2010-03-25 16:39:00]  Soft Linden: the transparent pixels specifically - last I knew you were only doing the meta tag
[2010-03-25 16:39:04]  Lonely <3: We are
[2010-03-25 16:39:08]  Lonely <3: Just the image comment
[2010-03-25 16:39:14]  Soft Linden: right

Okay, if you’re anything like me, you’ve read that more than once and still couldn’t make out sense of the technical aspects of it. If you understood most or all of it, then here’s your imaginary cookie lol, you’re a few steps of where I was. However, if you’ve read my first post you’ll know that I wasn’t going to stay in the dark any longer than I had to. With that said, let’s see how well I’ve come to understand what it all means and if I can relay it to all of you properly so you can start to make sense of it as well.

So let’s start at the top, pointing out that both conversations took place in March of this year. I want that little tidbit to stay in the back of your mind as you read on. What you’ve read is a conversation between an Emerald developer and a Linden Labs employee. In it, the two use terms such as ‘hide’, ‘tied into’, and ‘misleading’... terms which can be scary when taken out of context. We live in a time where the potential for identity theft via the internet is a huge reality, and anything that makes people wary about their safety and security is something that should never be taken lightly. Let me interject the addage ‘Knowledge is power,’ at this point, because it’s oh-so-appropriate thought out this entire ongoing situation. The more you know, the less likely you are to make decisions based on fear.

So the technical side of this starts almost immediately in the chatlog. “The Emkdu variant encodes the window title into j2c comment.” The first thing to explain here is j2c is short for jpeg2000, an image compression standard and coding system. The “comment”, simply put, is a field in the file that’s designed to hold additional metadata. Metadata describes other data, an easy to understand definition can be found here. The second part of the statement quoted mentions a “window title”, which is pretty much what it sounds like. In this situation, the window title would refer to the viewer being used by a person. So the emkdu file at that time was set up in a fashion that it would take the name of the viewer you were using and encode it into metadata that was then attached to a baked texture in your avatar textures. Baked textures simulate things such as lighting, shadows, and bumpiness on an object... think avatar skins or shadow maps on sculpted prims. Not really life altering if you weren’t doing things you shouldn’t have been doing.

So you have the emkdu which was set up to encode and attach metadata, then you have onyxkdu, from the now infamous Onyx viewer. The onyxkdu was set up so that it’s library was seperate from that of the emkdu’s. Onyxkdu had the capability to decode (read) the metadata that the emkdu embedded in the av. textures. The limitations on this, however, were that they could only view the data inworld, and only if the avatar was in view of the Onyx user. They were not able to actually export or otherwise use the av textures, as some concluded, otherwise the viewer and coding would have been in direct violation of LL’s TOS. What’s shown in this screenshot is not a texture being stolen aka ‘copy botted’ or ‘ripped’, as some might want to sensationalize it as, but rather the encoded information being read by onyxkdu. The texture is being viewed in what’s called an ‘avatar texture floater’ which actually comes from LL’s own coding, and is hidden from the menu options in their official releases. You can find a modified version of the avatar texture floater in the latest Emerald beta release (2587) by using the pie menu on any avatar, including your own, but you’d only be able to make changes to your own textures in this floater, provided they’re modifiable by permission. It doesn’t circumvent the permissions system. The purpose of the metadata encoding and collection was to identify who was accessing the ‘proprietary library’ aka the licensed kdu library, as well as who was using a malicious or illegal viewer that was spoofing itself as a legal one, as mentioned by Lonely.

In relation to the previous two paragraphs, I’ll take this time to address the line where Soft says that LL was “at least planning to start encoding some info there to help us with DMCA takedowns.” What this means is that LL, at that point (whether it’s been done, I’m not aware, some one is more than welcome to comment if they know the answer) part of their plan to combat copyright infringement (DMCA issues) was to also encode metadata into the baked av texture section of llkdu. They won’t need to have an alternate viewer to read the data, as it’s all accessible to them. DMCA, if you’re not familiar with the term, stands for Digital Millennium  Copyright Act. It’s part of United States Copyright Law and deals with the copyrights of Intellectual Property on the Internet. The wikipedia definition is here and LL’s policy and process is outlined here. The suggestion by Soft for Lonely to relocate where their metadata wrote was so that LL’s coding wouldn’t overwrite Emerald’s.

The parts of the conversation that deal with executable paths, encoding paths, and end of paths, all deal with identifying the executable files where the viewer was located on a user’s system. This also wasn’t in place to be used to hack into some one’s system, it was so those who were using illegal/banned viewers couldn’t sneak around pretending to be on legal viewers based on their tag data, by simply changing the name of the file. Think of it in terms of, you save a SL snapshot to your computer using the ‘save to disk’ option in the snapshot window, then on your computer you change the name from snapshot_01 to ‘hanging out’ (just an example, but you catch my drift). Well, you’re not changing the fact that it’s a snapshot from SL, you’re only changing the name that it’s viewed as.

So that all basically covers the technical aspect of the conversation, and has hopefully allowed you all, the readers, to have a better grasp of what they were talking about. With that out of the way, we can get into what’s not likely to be recognized between all the jargon (and yes, some editorial commentary)... The fact that in spite of LL’s claims of ignorance to what the emkdu file was doing, and the onyxkdu file as well... at least one of their employees did. Now if this is a case of the right hand not talking to the left, which it may very well indeed be, then it’s understandable that statements claiming ignorance could be issued... but one would imagine (or myself, at least) that it would be good corporate sense to have all of your ducks in a row first. Is that a criticism made by me about LL? You bet it is. This is not to say that I agree completely with the methods employed by those on the Emerald and Onyx teams who were involved in this coding system, but it’s obviously not as devious as LL would like Joe Public to believe. This leaked chatlog is a frank discussion by two people who expected it to stay between them, and I suspect it was just two conversations out of many, given the actual context.

In a recent conversation I had with former Emerald Support team member Mindy Spiritor, she expressed her viewpoint on the situation “At some point, though, people really need to realize that the Onyx project was never part of the Emerald Viewer.  The same goes for the datamining project.  It was NOT Emerald.  Yes, it was in fact Emerald developers, who were also running their own projects on the side, and the fact that they engaged in something even potentially questionable (let alone outright questionable) shows a blatant disregard for how it would reflect upon Emerald given the undeniable ties.  However, the conversation between Phox and Soft also clearly shows that at a minimum, Soft not only knew of what was being done with both emkdu and Onyx, but also offered ideas, guidance, and at least apparent approval by virtue of his position with LL.” This is, naturally her opinion on the situation, but I’m drawn to agreement with it. It raises valid points that should not be overlooked.

There are those who will succumb to the fear and panic, even if they’ve read this as I’ve lain it out. Those will be the ones who, regardless of their love for the Emerald viewer and it’s capabilities, will move away from it and onto other third party viewers, or even back to an official viewer. This is in addition to those who’ve already gone to other viewers after the initial tactics and rumors were employed, the ones that were blogged about in my first two posts. Those people did what they needed to do to make themselves feel secure, and I don’t fault them for that. For those of us who will stick with Emerald until the day we can’t log in with it anymore, I give you much respect. It takes guts to stick with something and make a statement like that. Stick to your guns, so to speak, and remember that there is power in numbers, even if, in the end, it doesn’t seem to have accomplished much... someone always notices.

Thank you for reading and I hope this helps you understand more of what’s been going on. Please feel free to comment below, and share this blog with others.

Krisy