Interesting posts on
Excerpts from comments to the official blog announcement
- Peer review is what makes applications secure.
- Security by obscurity is no security, and just imagine the countless people submitting bug reports and diffs improving on the code base to LL in the near and intermediate future. And new LSL and Prim editing tools will shoot out of the ground like mushrooms.
- Localized versions in all sorts of languages will appear
- Firefox is open source and it’s way more secure than IE and anyone can download the code but you don’t hear all kinds of nightmare stories about Firefox being hacked. I don’t think there’s any reason to worry about SL being hacked any more than before. In fact, with more eyes on the code, security will likely tighten up.
- Some people don’t like open source (or, as in the case of the use of the GPL, Free Software), which is acceptable. Thinking that open sourcing the *client* will adversely affect the economy is somewhat alarmist – certainly, bad things *could* be done, but more likely bad things will be *patched* before they are done.
- The client is what you connect to SecondLife with. The server code isn’t publicly available, though from what I understand much of the infrastructure is based on open source code.
- Open Source/Free Software has a demonstrated track record in this regard – projects such as Linux, Apache, Mozilla… to name some… have already demonstrated the benefit of code as a commons.
- Proprietary code, on the other hand – well, we’ll see how many patches Microsoft releases tomorrow.
- If you are just a regular user, this probably won’t affect you – except, perhaps, give a more stable client with less LL resources.
- Opening this source to the development community will do:
1. Improve the quality (stability & performance) of the client app in the long run
2. Generate some excellent utilities and spin-off applications from SL
3. Shut alot of ppl up about the amount of work Lindens have to do
- this is what the folks at OpenSSL do with their code – the benefits of having so many eyes look over it to find and fix its flaws far outweigh the costs of having unscrupulous eyes able to see it.
- Linden Lab maintains a large portion of their control over the content in Second Life by keeping the server side closed. Indeed, expect to see script decompilers, just don’t expect them to decompile scripts the client otherwise wouldn’t have access to. Releasing the client’s source is not an all-expense-paid ticket to do everything. The servers can and do deny access to certain content if the content is locked, regardless of the way the client requests the content. This means that the permissions system does provide protection to notecards and scripts and that this protection is in no way impinged upon by the releasing of the client’s source.
- that privacy or security which was “granted” viewer-side was largely illusory anyway. It is good that the view is now open, so that everyone knows the weaknesses. The LL servers are our “trusted computing base”, that’s where privacy and security need to be dealt with.
- The copybot, I think, was and is inevitable. Textures and other “content-y” stuff that are downloaded to the client are and have been always copyable – it was security-by-obscurity at best. The open source code will make this eminently clear (if Copybot didn’t already do that) and people will have a harder time making money with “content”. However, “services” – scripts that stay server-side, real-life services, etcetera, will always be unique and value-adding. I expect a shift in the marketplace towards this end. Content = commodity so either you grab free stuff or pay for bespoke work, services = value-adding so you’ll keep paying for them. Is that good or bad? I don’t know. Just a fact waiting to happen. The WWW seems to have happily survived the exact predicament, so I’m optimistic here.
- While it’s appropriate to worry about the hackers and griefers having access to client-side source code, don’t forget that the public security experts will also have access to it. Maybe we’ll see a McAfee or Symantec or AVG plug-in for the SL client to secure all that precious content. Or maybe secure certificates for content transactions. It’s not just the bad guys who will be playing with the code.
– I expect to see LSL script decompilers/rippers, object duplicators ala CopyBot and much more in the coming months.
– I already have a script disassembler. Of course, since there’s no way of getting the compiled version of a script from the server (the only way of getting it is to snag it as it goes out to the server when you save it), it’s pretty much useless for content theft and hacking. The source is actually easier to obtain – and even that requires you to have the correct permissions.
– The silliest decision ever. We knew it was coming, but there is absolutely no security right now in the SL protocols. Once again LL is making the right decisions at the wrong time.
– Errm… yes there is. The server won’t just blindly do anything the client tells it; most of the security restrictions are already implemented server-side and have been for a while, barring a few mistakes and things that can only be done on the client (e.g. blocking texture/prim shape copying).
– You thought copybot was bad ? Wait until someone comes up with a free L$ generator, a sim/grid nuker or a permission modifier. I’m pretty sure the server side of SL is creaking with the security holes that allowed that kind of hack in the past.
– If there were any holes like this, most of them probably got found and fixed already (thanks either to libsecondlife or malicious hackers – I’m not sure how many security holes libsecondlife has reported, since neither they nor Linden Labs like to talk about it, but I’ve heard there were some.)
– I predict that in the next couple of weeks we shall see at least one “universal object replicator” and one “grid nuker”. I sure hope I’ll be proved wrong
– Predicting security problems/sim crashers is like predicting the sun rising tomorrow — source code or not.