Category: SL Tech

Server 1.38 rolls outs

Posted on by Inara Pey

Following the recent announcement on the subject, sever release 1.38 has started arriving, and with it the first steps in script management, together with other goodies.

Some 20% of the grid will be used as a pilot environment during the roll-out, with the rest of the grid receiving the update (assuming the pilot goes well) by the 6th April.

For scripters / builders, there are a series of new LSL commands than mean that (a) a lot of us are going to be busy for a while and (b) overall script counts / memory loading for certain functions should be reduced as the new functions are adopted. Initially, the ability to incorporate the new functions (for those that use them) will be limited to those working on 1.38 server sims (obviously) – so many of us are going to have to wait until after the roll-out has been completed before we start determining what needs to be changed.

As far as the script management tools are concerned, these are only available for those using Viewer 2.0; the functionality is not being back-ported to Viewer 1.2x (unless third-party developers opt to do so).

Ciaran Laval currently gives an overview of the new About Land script information tabs, and if it is not old hat by the time my home sim receives 1.38, I’ll likely have a few words on the information displays as well – unless, of course, Linden Lab keep to Jack’s stated promise and provide the necessary Information themselves. In this regard, and even allowing for the current roll-out being a pilot, I was somewhat surprised that nothing on the situation was posted in the LL blog (although a brief note did eventually appear in the Grid Status links).

Reaction to the new server code has so far been good –  those in the pilot are reporting good stability and overall improvements in sim performances. Doubtless, part of the latter is down to 1.38 fixing the Mono rezzing / start-up bug that would cause massive lag spikes.

Providing LL communicate the new script management tools and their limitations clearly, and estate owners can communicate matters to their tenants as well, 1.38 will hopefully be a boon to SL overall.

Third Party Viewer Policy – Further update

Posted on by Inara Pey

LL have quietly slipped out a revised Third Party Viewer (TPV) Policy.

While its heart was most definitely in the right place, the initial draft was flawed in several areas, as commented on by myself and others at the time.

Pretty much everything that appeared to run against common sense seems to have been fixed – with the passable exception that LL still insist of laying claim to the word “Life”. In particular Part 1h is gone from the document (good!) and Point 6a(ii) has been revised so that personal information such as rl name and address will not be published in the Viewer Directory. A minor niggle here is that it should be spelled out clearly in the Policy itself, but it is clarified in the accompanying FAQ.

Point 7a has been also  been cleaned-up. The original stated:

You are responsible for all uses you make of Third-Party Viewers, and if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute.

This was a dangerously ambiguous statement and one that could be taken to read that the original developer will be held to account for each and every use their Viewer is put to – even if modified by others outside of their control. As such, this one statement, more than any other, served to potentially undermine the entire policy: who in their right mind would agree to such a clause when knowing full well anyone could maliciously seek to download, alter and use their code?

In the revised document Point 7a now reads:

You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

The difference is subtle, but it is there; The reference to features, functionality and code allow a distinction to be drawn between being a developer being held accountable for their “original” code and being responsible for modifications to said code made outside of their control. This should in theory be enough to allay fears in this direction.

Only it doesn’t. Many are still up in arms about the Policy, largely due to the manner in which Section 7 has been re-cut.

The problem here seems to be part technical and part social – and frankly, it is the Lab’s fault that the two issues have become confused inasmuch as they have chosen to draft a policy that intertwines the technical development of a Viewer and its means of distribution with its social use (Section 7, “Your Responsibility for Third Party Viewers” is actually now sub-titled “If You are a user or Developer of Third Party Viewers”).

The specific point that has upset some Viewer developers is Point 7d: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute (my emphasis).

The mixing of use with development and distribution of third-party Viewers creates an unfortunate ambiguity wherein this statement could be taken to mean that third-party Viewer developers could still be held accountable for the uses to which their code is put once it has passed beyond their control. This is clearly unfair.

While it could be argued that a user taking an established Viewer and tweaking it for malicious purposes could be regarded as “development” of the Viewer, the fact remains that such issues should really defined within the Terms of Service, which a) themselves relate to the use of both the Second Life service and the tools used to connect to it; and b) are actually likely to be read by users.

Both as a part of this blurring of use and development, and as a matter in its own right in terms of overall technical liability, several raising objections to Point 7d have done so specifically in terms of “GPL violations”. I have to admit, I don’t fully buy-in to their arguments, and I’m not absolutely certain any court would agree with their black/white view of the text of this Point because:

  • Linden Lab have sought to clarify the Policy with a FAQ, where the meaning of various clauses in the Policy are spelled out in lay terms. As a supporting document, complete with explanations given by Linden Lab themselves and presumably approved by their lawyers, the FAQ does have bearing in a court of law. As such, were Point 7d to result in a Viewer developer being held unduly to account for the use of their code, the FAQ could be used to counter any action
  • More importantly, no legal document stands in isolation. There is the established precedent of law and the forbearance of pre-existing agreements and understandings. As such, a court is unlikely to go against a Developer who has acted fully and completely both with the spirit of the GPL and this policy, simply on the basis of point 7d. In fact, in many respects, it is hard to see such a case reaching court
  • On the wider, more controversial front, many view GPL as automatically granting immunity under the terms of the agreement. This is actually not the case. Clause 16 of the GPL broadly absolves the developer from liability, it does so with the caveat of unless required by applicable law or agreed to in writing (my emphasis). Thus, and while some developers may howl and scream at me for saying so, LL are technically within their rights and within the spirit of the GPL to introduce whatever clauses they deem fit into their policy. While this is a cause for concern – as this is how LL are adding the onus of liability – it doesn’t prevent developers in turn limiting the extent of their exposure with an EULA that includes a mandatory agreement as a part of the Viewer installation process.

Thus, while there are problems with Section 7, I don’t actually believe they are insurmountable.

Ideally, the issue of confusing Viewer use with Viewer development would best be dealt with through Linden Lab simply redrafting the section to clearly differentiate between the responsibilities of the Developer and the responsibilities of the user (for example, have Point 7a list the responsibilities of the Developer as enumerated items (i, ii, iii, etc), followed by Point 7b giving a enumerated list of responsibilities for the user). Doing so would probably account for around 98% of the gnashing of teeth and wailing currently being evidenced.

That said, and failing any re-write of the TPV, developers still have recourse to the use of an EULA, as mentioned above. If I understand things correctly, doing so would not be in violation with the GPL. Such an agreement / licence statement would likely supersede  statements such as Point 7d in the TPV policy, given that by allowing such a Viewer to connect to the grid, Linden Lab are tacitly acknowledging the developer’s own Licence Agreement with their users.

One also wonders whether Linden Lab will actually be pro-active in blocking Viewers from accessing SL where the developers have not signed-up to the TPV.

That said, at the end of the day, the TPV seems less a matter of legal action and far more a matter of public perception. Take away the inadvertent ambiguity and the rest, and the Policy really hinges on two thing in order to “succeed” in its aim of reducing the risk of malicious Viewers connecting to the grid:

  • The unwillingness of people behind such Viewers to provide proof of identity to LL.
  • The unwillingness of users to go beyond the list of “compliant” third-party Viewers and use a Viewer which might be perceived as being malicious and result in their being banned from the system as a result.

As such, if both of these goals are achieved, or perceived to have been achieved, then the Policy can be regarded as a “success” – even if it does (sadly) come at the cost of some developers continuing with their efforts to provide better and more stable means for users to experience Second Life.

Viewer 2.0: updates and iterations

Posted on by Inara Pey

New Release

LL have released an update to Viewer 2.0. It incorporates some positive actions, but still leaves a lot of issues uncommented on. LL are at least still taking feedback, but I’d venture to suggest that they’ll stick with Tom Hale’s put-down made back on the 23rd Feb that what we’re seeing is pretty much *it* and that large-scale changes (even those that make sense) aren’t going to happen.

Nevertheless, the improvements are somewhat welcome and we’ll hopefully see more tweaks as time goes on.

Of Polls and Surveys

A new survey on Viewer 2.0 has also been released. After the outstanding joke of the original “poll”, as put up by Amanda Linden, this one at least has the appearance of seeking feedback from residents.

The original poll is, sadly, still available on the front page of the Viewer 2.0 forum, where it appears to make glowing reading – 67% of those asked apparently love the new Viewer! It is only when the actual poll itself is viewed that one gets the full measure of the spin involved:

  • Only three responses were obtained before the poll was locked
  • The three options that followed the question, Do you like Viewer 2.0 were utterly skewed towards favouring a “positive” outcome, given they were:
    • “I love it!”  – i.e. overwhelmingly “in favour”
    • “I like most of it” – i.e. still “in favour”
    • “I’m indifferent” – i.e. can be counted as “in favour” as it doesn’t actually say “dislike”
    • “I don’t like it” – i.e. only giving a 25% chance of wholly negative feedback

Many of us took Amanda to task over the poll when published, and this may have influenced the shut-down.

I’m curious as to the new poll on four counts:

  1. Whether the results will be made public – I’ve yet to find a link allowing me to view results.
  2. What degree of spin will be employed on the results should they prove negative (remember, Hamlet Au over at the Herald managed to turn one poll that had a 66% negative feedback into a positive, simply by only mentioning that 33% of those polled were “in favour”  – making it sound as if this was the largest portion of votes received).
  3. How the poll compares to this one, which does include the ability to view the results
  4. Whether LL will even publish the results or simply push them to one side if the feedback tips strongly towards the negative.

Security Worries

One of the new features in Viewer 2.0 that has caused much commentary is shared media. However, the commentary hasn’t been entirely positive, raising issues over security and privacy. So much so that it prompted Samuel Linden to post on the subject.  It was supposed to smooth over the concerns and calm residents.

It didn’t. While it is reassuring to know – as posted in response to the thread – that LL are “working on” the specific issues vis-a-vis potential exploits provided by shared media, which really weren’t addressed in Samuel’s blog post, it is still somewhat worrying that LL were seemingly aware of the risk that resident’s computers may be exploited through the unscrupulous use of shared media and still opted to set Viewer 2.0 to a default of auto accepting shared media.

It’s also worrying that while most web browsers – which seem to be the paradigm for the new Viewer – give the option to turn off things like Javascript support, etc. (or rather, turn them on) – LL’s wisdom was to have them turned on by default, with no option currently included – or originally going to be included – in the Viewer to turn them off.

Samuel states LL will now be providing this functionality in the next Beta release, albeit it somewhat grudgingly:  Obviously disabling JavaScript will severely limit the functionality of websites, and turning off plugins will render Flash inoperable, but these are features that were requested, and we are providing them in the next Beta release.

It is comforting to see that LL are listening and responding to user concerns relating to security around shared media – but it is also worrying that they opted to take such a cavalier attitude towards security in the first place. If nothing else, this again points to the fact that Viewer 2.0 is – primarily – viewed by LL as “business tool” aimed for those whole will (in theory) be using it alongside their SLE product, nice and safe behind a corporate firewall, where fears flash and other tools being hacked are pretty much eliminated.

The First of the Third Party V2.0-based Viewers

Elsewhere, the first of the third-party iterations of Viewer 2.0 has popped up. KristenLee Cinquetti has always had a reputation for producing really top-notch Viewers which incorporate a lot of very useful features. Of all the Viewers out there, hers has always been my favourite simply because of the fact that her custom graphic pipe means that things like dynamic shadows actually work, and her graphics settings allow a whole new level of realism. Sadly, she does not embrace RLV functionality, which means I stick with Emerald – which, admitedlly, is almost there with the shadows.

Her first attempt at a “Viewer 2.0” compliant KLee Viewer incorporates elements that have found their way into the latest Beta update – so some may wonder at the fuss. That her mods were slightly preempted by LL is a shame – but they at least show how things can be done.

The major changes made are:

  • The Sidebar no longer shunts the world view to the left when opening (now in the latest official relase)
  • The Camera controls have been tweaked to something like the old system – both move and rotate are on the same toasty (pop-up). Admittedly, they still vanish if you click elsewhere – which is annoying and the control itself is still overly large, but at least there is no need for painful toggling
  • About Land is back on the top bar as standard – an XML tweak has previously been provided by Alexandrea Fride for Viewer 2.0, and its inclusion here is very welcome and makes the Viewer land management friendly once more
  • Some attempt has been made at making pop-ups, etc., transparent when the focus is moved from them but – frankly –  the interface really doesn’t lend itself to this. While this is hardly Kirsten’s fault, it still renders the effort on her part as almost wasted (transparency has also been somewhat introduced to the official Viewer)
  • Preferences -> Graphics includes an additional tab that allows the more “advanced” user an even greater degree of control over how their SL experience looks and feels – and this is very welcome
  • The Map and Mini Map button have been returned to the bottom toolbar. While both are very welcome additions, the former is huggable, as it means the bloody Sidebar can be totally avoided when trying to use the map!
  • Inventory is also back on the toolbar – so **HUGS** again as the Sidebar can be avoided!
  • Speed – as with all Kirsten’s Viewers, the average fps (for me) is around the 30 mark – considerably faster (and smoother) than the official viewers.

There are some things that are currently missing – but this could be down to the fact that the interface doesn’t (if Tom Hale is to be believed) make for significant changes. The Sidebar, for example, does not turn transparent when left open and the focus moved from it. Again, it may be entirely possible that making it so wouldn’t so much to change the impact it has on the immersive experience but there is a lot of black in the Sidebar, and it would be nice to see some of it “vanish” when forced to keep the bloody thing open. But then, like the official Beta, this is just a first stab at V 2.0.

Overall, I have to say that Kirstenlee’s approach is a major step forward in developing a Viewer that actually addresses two somewhat disparate audiences – the “old” and the “new”. What is more to the point, it goes a long way to ensuring that Viewer 2.0 doesn’t become increasingly annoying to “new” users as they gain grater familiarity with the Viewer and the platform and simply want to enjoy their in-world experience as a 3D experience rather than a 3D background to a clunky interface.

Viewer 2.0 update

Posted on by Inara Pey

For those still struggl persevering with Viewer 2.0, a further set of tweaks (from Kitty Barnett – thanks, Kitty!) can be found in the official forums.

I have to say that for now, I’ve stopped using Viewer 2.0. This is simply because for much of what I do in-world, I need Viewer 1.X – and I’m a little bit fed up with Viewer 2.0 screwing my appearance up each time I load it up (it forces me Avatar to “roll back” to whatever I was wearing the last time I was logged into V 2.0 – regardless of subseqent outfit changes in V 1.X. Most irritating).

If I come across any other V 2.0 goodies, I will of course post them here. In the meantime hints and tweaks continue to be logged in Alexandrea Fride’s thread.

Third Party Viewer Policy Update

Posted on by Inara Pey

Sometimes you can’t help but sympathise with Linden Lab – to some degree. They must at times feel like they are trapped between a rock and hard place.

Last week the Third Party Viewer Policy rolled out – and caused everything from flag-waving to howls of despair.

On the one hand, people were happy to see the policy – warts and all – while on the other there were screams about it violating GPL and Creative Commons.

For myself, while I applaud LL for taking action, I was concerned over a number of aspects of the policy: the ambiguity expressed in some sections, etc.

Such was the storm of feedback received, Linden Lab did the right thing and started walking through the minefield of opposing views to try and nail down concerns and produce a policy that can do what needs to be done. While I had to smile at a reported comment from one Linden Lab employee, “Linden Lab has approached outside legal experts with your feedback, and one of these experts is a lawyer who specializes in open source license compliance issues.” *cough*, a shame this wasn’t done from the start –  what we have here is an attempt by the Lab to produce a document that meets the demands of those worries about such things as data and content theft, honours the Lab’s own need to maintain the integrity of the grid and which avoids falling into a legal pothole around the issue of GPL / open source, etc.

In the interim, they’ve issued a FAQ to address many of the issues around the policy. Chief among the clarifications are:

  1. The policy applies to ALL Third Party Viewers wishing to connect to the grid, spelling out non compliance = no connection
  2. It “clarifies” concerns I personally had (as did many others, it seems), section 1h – inasmuch as by “clarifies” I mean Linden Lab are eliminating it from the policy.
  3. Matters around publishing personal data (real name, address) has been clarified. Real names and addresses must be supplied to Linden Lab, but do not have to be listed in the Directory.

These are all to the good. (1.) in particular is beneficial – the policy may have implied such – but it needs to state as much outright.

There is much more to be done – and it is going to be interesting to see what comes out of the current re-drafting of the Policy. However, these are pretty much moves in the right direction.

Whether this policy also spells the “end of saving full permission textures” remains to be seen. I rather suspect not, and that the argument being put forward that it does is both too narrow and too selective of specific phrases within the FAQ passages it points to. If nothing else, it’s a demonstration of my comment on LL being between a rock and a hard place; whatever they do on some matters, there will always be someone ready to start shouting “the sky is falling! the sky is falling!”. What’s more, even when LL react to such cries and revise their position – they still hear “the sky is falling!” being shouted across the forums  – sometimes by the very individuals / groups that shouted for the change in the first place…

Viewer Policy

Posted on by Inara Pey

Alongside the announcement of the Viewer 2.0 Beta, Linden Lab also announced their Third Party Viewer policy is moving forward.

The policy itself can be read in full here. At first glance, it is pretty comprehensive, listing items related to required functionality and disclosures, prohibited functionality, intellectual property rights (both the protection of, in the case of in-world content, and ownership of, in the case of the Viewer code), data access and privacy, branding, and other aspects.

Deeper analysis shows that while it is attempting to cover the bases, there are some statements that require clarification / reconsideration. There is also the not-so-small matter of the policy being almost entirely one-sided.

To start with the former, where clarification  / re-wording is needed:

Point 1h: Central to Second Life is the principle of shared experience. The services we provide through our viewers, for example, our Land Store, the LindeX exchange, and the Xstreet SL marketplace, are designed to enhance Residents’ shared experience. We may ask you to make changes to your Third-Party Viewer if it disables certain of our services, or if we believe it is inconsistent with the principle of shared experience or otherwise negatively affects the Second Life user experience. If we do, you agree to make the changes we request.

  • Where does this leave “lite” Viewers supplied by third parties (i.e. variants on the SLIM product, such as the Second Inventory “remote login” tool)? Or text-based applications? We may assume these are excluded from the above statement, but…
  • Where does this leave Viewers that may opt to promote what might be considered rival services. XStreet is all well and good, but what if Viewer X opted to include a link or links to another on-line web service that is viewed as an alternative (aka “rival” in LL’s eyes) destination? While it fits the bill of the “Resident’s shared experience”, we’ve already seen the removal of posts from the forums that simply reference such sites. Will the same heavy-handed censorship find its way into how Viewers are seen, because such references are seen (by the Commerce Team in particular) as “negatively affects the Second Life user experience”?

Point 5b: Your Third-Party Viewer name must not be confusingly similar to or use any part of a Linden Lab trademark, including “Second,” “Life,” “SL,” or “Linden.” For example: You must not have a Third-Party Viewer name that is “________ Life” where “________” is a term or series of terms.

  • “SL” “Second Life” (note the quotes) and “Linden” are all quite reasonable; but singling out the use of the word “life” is perhaps going s tad too far; it’s a generic, everyday term (as is “Second” for that matter). While one can see the need to protect both the brand and the naive user from attempts to confuse or obfuscate via deliberately provocative names (e.g. “Pey’s Invincible SL Viewer”) – banning the use of a term like “life” is a tad unreasonable, particularly when Viewer developers have to comply with 1C, to wit: The name of the Third-Party Viewer and a disclaimer that “This software is not provided or supported by Linden Lab, the makers of Second Life.
  • It is unclear where this leaves Viewer options such as Restrained Life. Now more predominantly known as “RLV” – to the point where “RLV” could be considered its branding – is this Viewer code now banned on the basis of its name, despite the fact that in every other respect it is complaint. Where it called “the SL Restrained Life Viewer” (or even “the SL RLV”), I’d be more sympathetic towards LL – but as it is, discriminating against the use of the word “Life” comes over as pettymindedness.

Point 6a(ii): You must provide true and correct information in the Viewer Directory Application Form, and you agree that the information you provide in the fields that are marked by a cross (†) may be published in the publicly available

This again appears to go beyond what is required. Yes, the Directory is a good idea, and having a list of “certified” Viewers from third party sources increases user confidence. But….

…why is it necessary to openly publish information relating to the real-life business address of the Viewer developer (and possibly a real life identity, although not having seen the application form, I have not idea if this in mandatory – I can only make a call on the business address is this is shown is being publicly available in the sample directory listing)?

Such public disclosure serves absolutely no purpose whatsoever. Period.

  • YES – developers should give real life information: name, contact details, business / home location to Linden Lab
  • YES – this information should be retained by Linden Lab for as long as the developer supplies the Viewer
  • YES changes to the developer’s real life information, or information relating to a Viewer “changing hands” between developers should be recorded and passed to Linden Lab
  • NO none of this information should find its way into a publicly accessible list
    • It does nothing to improve the “validity” or “safety” of the Viewer the developer is supplying
    • It does nothing that helps the user understand the veracity of the codebase
    • Ir does however open the developer to the risk of harassment, griefing and God knows what else

Given it is unlikely that the majority of third party Viewer “developers” are going to be corporate entities in any way, shape or size, but rather they are:

  • EITHER going to be individuals working from home, in their spare time and out of a passion for Second Life – such as Marine Kelley, Henri Beauchamp et al,
  • OR going to be a part of a loose-knit, hobbyist team working on a distributed project, such as the Emerald team

….do those at LL responsible for this policy:

  • Really expect such individuals to go out and take on the expense of forming an off-the-shelf company that can use a (fee-charging) registered address on order to provide themselves with some protection
  • Actually believe making home addresses of users available to the public at large is justifiable?

Some will say that development of a third party Viewer removes a developer from the protection of anonymity. To these people I can only say, “cobblers”; the development of a third party Viewer only removes a developer from the protection of anonymity in their dealings with Linden Research. There right to anonymity in their dealings with the rest of the community remains unchanged.

Point 7a: You are responsible for all uses you make of Third-Party Viewers, and if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute.

This is at best ambiguous. Exactly what does the term “you develop or distribute” mean? If I develop my “Pey’s Invincible Viewer” and make it available via a website in due compliance with this policy….

  • Does my responsibility for the code end at the point of download, or
  • Will I be held responsible for the actions of those who download my code and then amend it for their own nefarious ends?

“Distribute” can cover a multitude of sins, not all of them the developer’s fault.

Beyond these issues lies a bigger problem with this policy: the fact that it is totally one-sided.

From start to finish, the onus is on the third-party Viewer developer entirely. No-where does the policy imply any actions are required by Linden Research – particularly when it comes to stopping / blocking non-compliant Viewers.

This is Failure One: Not only is the policy voluntary and self-certifying, Linden Research clearly state they’ll do the absolute minimum to police it, vis: We may analyze any Third-Party Viewer and its code, content, and data for any reason, including to ensure that the application complies with our policies and is safe for users. Although we do not guarantee that we will conduct such an analysis, we may do so in our sole discretion.

Note the terms, “may” and “sole discretion”. Yes, reviewing every line of code of every Viewer submitted is clearly beyond the pale. However, by having third party developers document specific instances of code that branch from the accepted standard for the Viewer, or which introduce new functionality into a Viewer should be enough for Linden Lab to test  / review that particular functionality  – and it is not as if we’re going to be talking millions of lines of code.

What is wrong with a Viewer developer having to go through a QA cycle whereby new iterations of their Viewer can only connect to the test grid and subjected to user testing much as the official Viewer is bumped around, prior to being formally released? Obviously, there are issues around this, but they are not insurmountable – and they’ll again increase user confidence.Again, we’re not talking about dozens upon dozens of new Viewers…

Failure Two, however, cuts right to the core of the issue. Absolutely nowhere is it asserted the Viewers failing to register with the Directory will be blocked from accessing Second Life.

By not specifying the fact that Viewers failing to register their compliance with the policy, and what actions will be taken against such Viewers, Linden Research is overtly suggesting that things will be pretty much business as usual for such Viewers.

It’s a thorny issue. I don’t profess to have all the answers – I openly admit to the fact that software coding and development is as foreign to me as the bottom of the Atlantic Ocean. I would, however, expect to see a policy that is a little more proactive when it comes to LL’s position than is currently the case.

Of course, any proactive action LL tries to take is going to be prone with issues and is hardly going to be foolproof – but this is no excuse for not trying to be more aggressive / assertive with this policy. At the end of the day, a passive policy is potentially as bad as no policy at all. Worse, it’ll be seen as further proof that Linden Lab are interested in little more than papering over the cracks.

ADDENDUM

When I drafted this, I included comments on digital certification but, as stated above – I’m no coding expert, so I cut the section out, thinking it was potentially a load of dribble. However, I’d like to thank Spikeheel Starr for pointing out that, in essence, my idea was correct, and for making the original point I wanted to make more robust.

That point is simply that *if* Linden Lab wanted this policy to be effective, they could have insisted upon a form of digital certification for ALL Viewers wishing to connect to the grid:

  1. Developers must apply to be registered.
  2. LL vets them and supplies a compiled Digital Certificate.
  3. The Certificate is added to the Viewer code.
  4. The Viewer source code (including the code required to PRESENT the Certificate to the LL servers) is published
  5. LL update their servers to only accept Viewers which present a Certificate.
  6. The Certificate itself is issued in a secure form within the Viewer installation script.

I understand the code changes wouldn’t be that hard to implement, and providing a Certificate / certification process wouldn’t break GPL.

So again…assuming all the is right – and I’ll bet my hair Spikey is right, the question must be asked, why aren’t LL even appearing to move in this direction?