It’s a bit of old news now (in Internet time, at least), but not long ago there was quite a bit of buzz in the Second Life® blogosphere about a new program called Second Inventory, whose stated purpose is to allow a Second Life® user to create a local backup of their Second Life® inventory - Scripts, notecards, textures, the works.
Of course, there was an immediate buzz (see Dedric Mauriac, Vint Falken, and Your2ndPlace for example and comments) in the SL™ blog scene and lots of interesting speculation, discussions, and outright accusations on SL-related forums about how the software could be used to steal from content creators. I don’t know and won’t speculate here on whether that’s true, but I could actually envision myself using this software for it’s intended purpose, as there have been many times when I’ve wished that I had a local copy of a script or texture that I can no longer find or that Second Life® seems to have lost.
Most recently Second Life® had lost the notecard for my ZHAO animation override, but even more importantly (and more frequently) I’ve lost several important scripts over the last two years. Unlike my real-world software development environment, Second Life® has no version control, automated backups, or even adequate inventory search functionality, and this has led to my rigidly following a practice of doing *all* of my SL™ scripting work offline using SciTE-ez, lslint, and Subversion.
So, as I say, I can see wanting to use the Second Inventory program myself, but I just can’t get past the most powerful of trust issues : It requires your Second Life® username and password. Having developed several kinds of utility software for myself using libsecondlife, I’m well aware that this is a requirement for which there is no workaround, and that’s not the part that makes me uncomfortable. The part that makes me uncomfortable is that I am just fundamentally wary of giving my password to anything but official Second Life® software.
There’s another program generating a lot of buzz in the blogosphere right now that provides a pretty concrete example of why that unease is justified : G-Archiver. Jeff Atwood of Coding Horror fame recently received an email from Dustin Brooks (who reverse-engineered the program) describing how he had discovered that the program sends user’s GMail login and password info to the software’s creator. Mr. Brooks apparently discovered the sign-in credentials for 1777 GMail users!
Now, I’m not saying Second Inventory is a phishing scam, I don’t know if it is or isn’t (I tend to believe it’s not, but not as strongly as I believe that the Nicholaz viewer is not), and that’s not the point I’m trying to make. The point I’m trying to make is that thousands of people get fooled by malicious programs because they don’t have a fundamental mistrust of software that asks for sign-in credentials. Even fairly intelligent and tech-savvy people fall for these kinds of things, perhaps in part because they *do* understand the technical reasons behind the software asking for such sensitive information, and they are very comfortable with technology.
I strongly suspect that with the Second Life® viewer being released as open source and libsecondlife growing steadily more capable, we can expect to see an explosion of third-party utilities and programs. While that’s generally a good thing in my book, and I look forward to seeing what kinds of things such software will enable with respect to bridging the real and virtual worlds, I think it’s important to remind potential users to proceed with caution.
The software is not open source as many programs are. I suppose we could just use Lutz Roeder’s Reflector to take a look at the internals of the programs to see what is happening with our credentials. Perhaps it would be better if there was a centralized body of individuals that would certify protected software that we could trust. Kinda like how gambling works in the US. casino machines are tested and verified that they are not cheating out the gamblers. A centralized body could do some packet sniffing to make sure nothing is going to any other site except for second life servers, and that no instant messages are being tossed about with sensitive information.
Reflector is an absolutely awesome tool, and almost required for compiler-writers and low-level developers (yes, they do exist in the .NET world), but even it can’t really make obfuscated code any easier to understand. I thought about using it to do an analysis, but I just don’t have the time for such things. Between my RL work and my C:SI development, I’ve got a pretty full plate right now.
It’s easy enough to use a tool like Ethereal to see whether there’s any unwarranted communication coming from the program, but again I just don’t have the time.
Second Inventory is just one program out of the many we can expect to eventually see, and that’s where good personal minimal-trust practices are going to come in handy, I think. Most of those programs will likely be legit, and only caution will keep people from being taken by those that are not.
Interesting point about a central certifying authority, and it’s one that I think would be very powerful and effective if done right.
What I would *really* like to see is a “Certified Second Life Developer” program, much like you can get a “Certified Ebay Developer” or “Certified Authorize.Net Developer” accreditation, where there is an official process by which you have have your third-party software product reviewed for important criteria such as security, best practices, etc. Unfortunately, I don’t expect to see Linden Lab implement such a thing any time in the near future. I’m already in the “LSL Certification” program, and it appears to have completely stalled
You know honestly I think there is a much more secure way of creating third party utilities and software for second life. CCP the company that produces eve-online uses a thing called API key. Documentation on the API key is located here: http://myeve.eve-online.com/api/doc/
Example of an API script: http://myeve.eve-online.com/api/doc/example-python.asp
But basically in short users have the ability to login to their main account control panel and grab this api key that along with a numerical user id. This allows third party software to access the information on specific users and manipulate it to do whatever it is the software was designed to do. Linden Labs to use a similar system actually very easily I think.
Hopefully Studio IceHouse will complete their alternate authentication scheme for SL viewers. With that implemented, people would only enter their password on the official SL website and authentication would occur via some methods I’m not all that familiar with.
I’ll bet it could be used for other third party programs as well.
Not for nothing, but… certification will become necessary somewhere down the road. Packet sniffing has little to do with that - NDAs and a peek at the source code would be sufficient. I’ve actually considered doing that myself, but then… who watches the watchmen? I’m not saying that I’m not trustworthy - I am - but the responsibility of certifying code is bound to be one which displeases some.
I’d be up for it, though. The trouble is that I’m a no nonsense person when it comes to code… and some developers can’t handle such a person looking at their code.
I am all for certification in theory, and depending on who does the certification and what the quality bar is, I’m all for it in practice as well. I think a certification program is definitely going to become critically important to Second Life in the future, and in fact I’d prefer see such a thing sooner rather than later.
I think NDAs will also gain in prominence over time. I signed an NDA in order to join the C:SI team, and am quite used to doing so regularly in my “day job”, though I often wonder how other SL developers would view such a requirement.
Hello guys, I’m Angelo Biondi in-world, the main developer of Second Inventory. I just read this article and I’d like to post my opinion.
I can agree with your fear, I know, any alternative client could grab your sl password and send/store/use it, in various way. That’s true. It also true that any other utilities installed in your computer could access to your sensitive data, even a screensaver, and spy/use/send them.
The company behind SI, the Medialeader (www.medialeader.it), recently decided to invest on Second Life, so it has moved some developers on this new branch. I can’t say right now if it is a good choice, is too early, but we are trying to follow this decision. You can easily understand how is far the possibility that we made all this investment right to steal your sl password
but I agree with this Topic:Proceed with caution. You should always proceed with caution when you install a third party software on your machine.
You can also believe how it would have been better, if we would have had malicious intentions, to sell an ‘Enhanced Copybot’ for 2000L instead than a professional software, it would have sold thousands copies more than SI in just one week, maybe from a ‘outsider’ website. But this wasn’t and isn’t our project, we are trying to contribute to the SL growth and not viceversa.
We planned some other projects in the same way (Opensim integration, large events hosting, other builders tools, etc) and we’ll try to develop them with the same approach of SI, following the community suggestions and dealing with them, even when they just try to go against us.
We also submitted Second Inventory to the Linden Lab (Glenn Linden) approval, and we are available at any other inspection or details request from anybody would like to know more about SI.
Regarding the certification debate, i have also my opinion, but I guess that I already wrote too much
No, actually, I’d very much like to hear that opinion.
That is almost certainly true, and I’m quite glad that you didn’t choose to take that route. Anyone with the knowledge and time to create Second Inventory could quite easily have done so, I’m sure.
Someone else will do so in the future, though, of that I am quite confident.
I don’t remember seeing that information before, but it’s nice to know.
I hope you don’t think I was picking on your product or putting it down, I tried to be very careful to not say that it was a phishing program or the like, but I did kind of hold it up as the kind of appealing program that little is known about that could quite easily have been malicious and we would not (could not) know.
I was just urging caution about such things in general, and your product was mentioned because it was the biggest news in third-party Second Life stuff that week
Well, that and there was a huge amount of speculation about it, but that kind of buzz made it the perfect example.
Hey, thanks for taking the time to leave a comment here!
.
Actually I agree with what you said. ‘Proceed with caution’ should be the right behavior anytime you install something on your computer, it doesn’t matters how much it costs or what it does.
Regarding the developers certifications, usually I’m against them, I’m kinda against any sort of title and label. But in this specific case (SL) I agree with you, some certification should be necessary. Especially if we want to preserve the sl economy.
Sl is no more a simple game, today (and I hope more in future) it’s became an real economic opportunity for content creators. A lot of people are investing time and resource on it. So there should be a way to protect their investment. I’ll be more clear: it could be very easy, for a developer, to make some simple changes to the official client source code and allows it to download any skin/texture/object present on the sim. Skin’s creators, spend a lot of time on their creations and these items could be stolen with one click. That’s not good. People was scared from S.I., but they didn’t think that it’s more easy to remove some permissions check on the official client to make more damages…
————— STRICTLY THEORETICAL PERSONAL OPINION ————-
(Proceed with caution)
I would go over the developers certification, I’d like to see (I know it’s impossible to realize) a Client certification, I would spend time to find the way to limit the third part client access to SL. I don’t mean block, that would stop also the SL growth, I mean just limit the full access to the authorized ones, and some restrict access to the other ones.
It would be great if they could find a way to grant the privileged access to their grid only at those client that were previously verified. Of course the approval process should be easy and fast, else this would be a damage for third parts company. Maybe once trusted a Developer/Company, all their upgraded versions could be considered trusted. This verification should be free to allows also the single developer to submit his own client, and it shouldn’t limit the potentiality of the client, it should just ensure that the examined doesn’t allow permissions circumventions. Unfortunately this approach would exclude the full access to all the home compiled client. Only verified binaries could access to all the functions. And unfortunately textures would be stolen in any case…
I know that it’s almost impossible to realize and maybe it could strongly limit the third parts potentiality, it is just a theoretical idea.