I wanted to take a few moments to publically reply to Linden Lab’s recent changes to content management policy. I think overall it is a step in the right direction; however one subsection of the policy leaves me with grave reservations – the suggested standards for backup utilities. To quote from the original posting on this subject:

To those developing copying tools, we urge the simultaneous development of standard industry practices that protect against intellectual property infringement. For example, consider the following standard practices for tools copying content from Second Life:

1. Check that the user of the tool is the Second Life “creator” of the content;
2. Do not facilitate the export of an entire Second Life inventory; and
3. Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

To summarise in other words, “You may only export content you created, and only if you label them as something you created in Second Life first, with your second life avatar name; and you cannot back up your whole inventory at once – you must do so piecemeal.” – every single one of these restrictions eliminates a large swathe of legitimate users and uses. Let’s go into them in detail.

Check that the user of the tool is the Second Life “creator” of the content

You have now eliminated all the content that is explicitly marked as compatible off-grid; everything licensed under creative commons or Open Source licenses, everything in the public domain. While I concur with ‘Full Permission != Permission to Export’; there is no way right now of programmatically indicating whether you want to allow content to be exported — however there are ways of legally indicating it, such as license files, README notecards, et al.

While Full Permissions are not an ideal situation – the overlap between content allowed off-grid, and full permission freebies is significant enough that a full permission check is a acceptable compromise. I personally would say ‘Full Permission OR Creator’; as both indicate a high level of permissiveness with the content itself (and the creator should always be able to export their own content). It is worth noting that Second Inventory (the popular backup tool) has been using ‘Full Permission’ as its own metric for over a year now; with I believe mostly acceptable results (it is not used as an infringement tool – the infringement part is always done by a illegitimate tool first).

Do not facilitate the export of an entire Second Life inventory

Hello.

The only possible reasoning for this I imagine is simply to prevent competition – by allowing full inventory export; you make it easy to translate content you developed from Second Life, to the numerous third party grids. If someone high profile wants to leave for one of these, these tools definetely help streamline the process. With 50,000+ downloads of the OpenSimulator software since December – I suspect there is an alterior motive for this ’standard’ that is not related at all to helping content creators; infact I cannot see a reason at all where this helps Content Creators.

The unintentional targets of this are now people who perform inventory backups – the Second Life Inventory server is about 99.99% reliable – which means 1 in 10,000 users can expect to lose their whole inventory, and 1 in 10,000 items will mysteriously vanish over the course of a year. There are reasons why Second Inventory market themselves as a backup tool for the unreliable asset & inventory services – and it is distinctly related to deficiencies in the platform itself.

As far as I can tell, this rule makes backups harder – which hurts content creators, because legitimate backup tools are now out of the question. It’s also saying something about the supposed ‘You own your IP’ line Linden Lab has been stating for the last 7 years. If we own our IP, how can you state what we can do with it?

which brings us to…

Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

Many probably want to be able to do this optionally; but it is not a mandatory feature. Mandating this indicates that you do not have control over your IP – because Linden Lab is going to demand attribution to Second Life. We at DeepThink developed a whole bunch of content over the last 2 years for use in both Second Life and OpenSim – I dont want that attributed to our content creation account, I want that attributed to:

DeepThink Pty Ltd. <www.deepthinklabs.com> – Copyright©2008, See attached license for licensing information

and not…

Adam Zaius – Second Life

Forcing the latter is stupid, and less effective than the former. The latter does not hold any form of copyright, it does not imply any license – and it does not imply any contact information for the creator or copyright holding entity [especially if they leave SL]. The tools should include the capability to add attribution metadata, and maybe they can default to showing a Second Life name (eg ‘Adam Zaius inSL’) – but ultimately, *I* want freeform legal attribution – which carries a lot more weight in the real world, where copyright matters.

This personally reeks of an disingenous alterior motive – particularly the last bit (Created in SL) – I’m very skeptical that Linden Lab would be able to legally enforce this; Textures and other assets have no ‘creative’ input by Linden Lab. The procedural primitive modelling may have some effect, but since a process is not legally creative – I dont believe the procedural algorithms themselves contribute creatively to the final work significantly enough to give Linden Lab joint copyright — although a legal experts opinion is definetely required here.

Ultimately, I think this is a counterproductive effort.

While I think this came from a earnest and honest discussion internally at Linden Lab – I dont believe it has any real world capacity to solve any real problems. Second Life needs a permission system that is capable of indicating an export permission. It should be clearly marked ‘Allow Export’; and be tied hand-in-hand with full permissions (so you can only check ‘Allow Export’ on existing full permission content — this way people are under no pretenses)

It’s not an ideal solution to the permission model’s deficiencies – but it would be a much better start than the three listed above. Since permissions are implemented as a 32-bit bitflags on the backend, and 28 bits are currently unused, implementing this would require no significant database or architectural modifications to Linden Lab’s backend (if anything it is just a viewer modification.) – it would be a very simple modification to make.

As a administrator on the most popular alternate grid – I dont want content on the grid that doesn’t belong. Infact we do spend a great deal of time making sure that our freebie locations and newbie content is all legitimately licensed (tell us if you find something that isn’t!), and the original creator intended the content to be there; anything that simplifies that process has my wholehearted approval.

Illegitimate content is not just irritating to deal with, it is also a legal minefield – we do have a DMCA process for OSGrid, and we’ve got some pretty sophisticated ways of removing every instance of an asset off the core servers, but it is a painful and annoying process. DMCA takedowns require certain legal procedures to be followed to the letter – which makes things a liability if they are done wrong; and there are significant extra considerations for non-US residents and servers.

Speaking with four hats on – that of a Grid Admin, Software Developer, Copyright Holder and Consumer – my firm response to this proposal is ‘go back, and try again.’ – because it’s not satisfying the requirements; and won’t do squat to solve the problem of content piracy; infact it will likely have the opposite effect where legitimate tools are handcuffed, and users favour of ones of illegitimate design.

There are good solutions to this problem, and I’ve got a proposal of my own in the works (one that I have been working on for a number of weeks already) – but these ‘Standards and Practices’ are complete hogwash; and degrate creator rights by imposing restrictions on what creators can do with their own content.

A non-OpenSim post for a change. This time on HTTP SSL certificates and the people who think self-signed certs are actually doing something.

I see this a lot on places like Slashdot, people’s blogs, mailing lists, etc. “SSL Certificates are worthless, self-signed certs are perfectly fine, Verisign are a rort charging money for nothing.” – and it’s completely false.

Simplified, SSL certificates consist of two main security properties – property #1, they facilitate public key encryption, which secures the transmission between you and a foreign entity from interception by a third party, and property #2 – they verify that the foreign entity on the other end is infact the server you want to be transmitting data to (ie, they are who they say they are.).

Both of these principles work in tandem – each server certificate is signed by a higher authority who vouches for the identity of the bearer; they are “signed” using cryptographic principles which prevent them from being tampered with. If a trustworthy third party cannot verify the certificate; then you do not know that the other party is really who you want to send data to.

While verification of identity has slipped with the price of certificates; you can be assured that the provider has at least verified the requestor is affiliated with the domain in question (ie; you cant just go out and get a certificate in paypal.com’s name). The stronger certificates, such as “EV” certificates (which get a green browser bar in modern browsers) – still require a full identity check.

This means, when you see that little padlock and dont get a self-signed warning; you know that the server you are speaking to is at least affiliated with the domain in question.

Which brings us to self-signed certificates. These are missing that little bit of verification – and the problem is, encryption’s purpose is to hide data from untrusted third parties; however with self-signed certificates, you dont know who you are communicating with in the first place – and hence the encryption is effectively worthless.

It’s quite possible for an attacker to generate a self-signed certificate in an identical name to the self-signed certificate you made, and then ‘proxy’ the connection; seeing the encrypted data, with you none-the-wiser. The only way of telling them apart would be to examine the certificate fingerprint; however there are no real effective ways of validating the fingerprint of a site easily.

You might ask where would an attacker be able to do this kind of intercept if they didnt work at say an ISP between you and the server, and a very common answer would be wireless hotspots and public networks. The same techniques which allowed an attacker to replace every image served on the DEFCON conference WiFi network with Goatse are the exact same techniques that would allow you to do a SSL-interception on a self-signed certificate.

So no – while the faux-SSL would raise the difficulty level slightly; it is not securing the connection; only a certificate signed by a trusted independent third party is secure. That does not have to be a subsidiary of verisign – but it does have to be a group who provide enough identity verification that they don’t hand out certificates to anyone who asks for one.

The default trusted authorities (CA’s) included in most major browsers consist of groups who provide some degree of identity verification. The browsers decisions on which CAs to include are based on this principle more than any other.

This also means, when Firefox shows you a big warning saying ‘This site has a screwed up security certificate’ – take heed. It’s saying it for a reason; the site isn’t secure.

Edit: for those who still dont believe self-signed certificates can be forged quickly or easily, read this.

I’ve been afflicted by this very problem myself lately, which is why this post has been sitting in my head (along with a slight hangover) for the last few days.

It should go without saying that a single developer can only achieve X number of features/fixes/improvements in Y time (and not every value of X is equal), but the moment you substitute “X” with specific feature names, it suddenly becomes urgent priority for everyone to stop work on it and get that done, to hell with everything else – although we want that too … and a pony.

The facts of life

The reality is – we’ve got a finite number amount of time, a finite number of developers, and a not-quite-so-finite list of features and improvements we have to spend time on, this means we prioritise stuff. We say “We think stability is a prerequisite before you go about implementing an example micropayments system.” – and with good cause, if the system didnt have that prerequisite stability, why the hell would you trust it to handle important or sensitive information?

This is not to say some of us havnt devoted time to thinking about it, it’s just that we each have our own ideas about what we think is important, and unless you are actively assisting in some capacity (food, booze, code, testing, etc), your personal wish list probably isn’t going to get any attention.

It’s harsh – but there it is. At the end of the day, each developer has a finite amount of time to work on projects, and when they are working on things – there is a strong chance that a specific goal is in mind and needed. If you want to change that goal, you either must have a convincing reason that that person is interested in and agrees with, or you need to provide an incentive to compensate for time that would otherwise be spent elsewhere. It’s also quite possible to just get in there, and do it yourself then submit those changes back.

Backseat Driving

There’s a lot of developers working on the OpenSim project – and each of them has their own ideas, goals and projects. Some of them are working on commercial projects that rely on OpenSim – and hence have some very specific feature and stability requirements that they work on. Others have more free reign by virtue of doing this in their spare time. There is a common misconception that the OpenSim team has an agenda – there’s somewhere around 200 developers on the project which means there’s 200 sets of agenda’s.

Right now, my personal agenda (which by proxy does carry a little across to what the DeepThink developers are working on) looks something like this:

• Abstract login and client initialisation to a more generalised interface to allow third party login and authentication routines to be fitted more easily as loadable DLLs.
• Find where we have remaining hard-coded references to LLClientView bits and bobs, and recode them in a more vendor neutral manner.
• Have a look at some of the terrain control issues reported on the mailing list recently.

It’s a pretty short list – this list gets revised, updated and changed pretty regularly based on what I need to do at the very moment, it’s the same for a lot of the other central developers – they are built on a task-by-task basis.

So – if you have a feature you really want to see happen, that you really think is important we tackle and address, your options include:

• Do it yourself – the code is there and we dont bite when it comes to new contributions. (Just as long as the code matches our other guidelines about quality, modularity, etc.)
• Convince someone to do it for you – this it the hardest of the options since we’re already very busy as a group, but it’s certainly possible. Make a convincing argument – it helps if you can research it and break it down into specific tasks. (”Improve stability” is not a task – “Fix crashes when/while XYZ happens” is.)
• Hire someone to do it for you – it’s an option on the table too. There’s a lot of developers familiar with the codebase now, lots of them are looking for beer money and can implement your pet project or ideas for a fee.

So in conclusion – if you have something you really think is important, really want to see – think it through, ask yourself “Is this more important than what people are working on already”, “Is this something that OpenSim is ready to support”, “Is this important enough that I am willing to work to see it done?”, and finally “If no-one thinks it’s that important, ready or <insert reason here>, am I willing to pay to see it happen?”. Because at the end of the day, features take time, and time is a non-renewable resource – people like to see it invested wisely.

Let’s run through the quick checklist for the recently semi-announced “LivePlace“, who claims to do some pretty nifty things with distributed server side rendering.

• Buzzwords like “Cloud Computing” and “Virtual Worlds”? Check.
• VC Capital Funding? Check.
• Implausible Technology that doesn’t stand up to basic analysis by an industry professional? Check.

Say hello to serverside cloud based renderered virtual worlds. Somehow, against all odds a small unheard of Silicon Valley company has developed a real time renderer that not only exceeds the current best of breed distributed real-time rendering research projects by huge margins – does so in a way that’s scalable to deploy a major concurrent project on.

Doesn’t anyone in Silicon Valley do basic fact checking with a technical adviser before giving capital?

Assuming this company has actually succeeded in developing such a renderer (big if) isn’t there the additional problem of bandwidth? Let’s be kind and say the average user has a 1024×768x32 screen – that’s 24mbit of data that needs sending 30 frames a second (720mbit/sec), now yes you can use some video encoding to cut that down significantly – but that’s a heck of a lot of data, and the compression is going to induce processor load seizures too.

The answer to the above question is apparently not.

There is a big reason we do client-side rendering today, and that is it distributes the load better than any “cloud”. 100,000 clients = 100,000 processors, 100,000 graphics accellerators, etc. Yes some of them suck and can’t do pretty graphics (Intel I’m looking squarely in your general direction), but the rendering they can do is going to be better than what a foreign service can do for you, and it’s going to be speedier – not only do you not have to wait 200ms ping and a x megabyte download to happen before you see the results of your movement.

While I am not claiming that this technology couldnt be made to work – it’s just not going to be pretty, I dont believe it will scale anywhere near effectively, and the bandwidth requirements alone are going to cause some very tough questions to be asked about whether this will run at all. (After all – anyone with a internet connection fast enough to support this is going to probably have a decent video card anyway.)

Count me very skeptical.

Shouts to Belaya for adding to the snark contained within this post.