Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

New Linux enhanced viewer: The Cool SL Viewer

Henri Beauchamp
Registered User
Join date: 8 Oct 2006
Posts: 253
03-15-2009 06:34
Here are two new releases of the Cool SL Viewer, available now for Linux from http://sldev.free.fr/:

Cool SL Viewer v1.19.0.5 release 52 (stable branch, legacy renderer)
Cool SL Viewer v1.22.11.0 release 2 (stable branch, Windlight renderer)

They both implement RestrainedLife v1.16c and the v1.22 release got a couple of bugs fixed.

Enjoy ! :)
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 02:30
Hello.

I see latest Cool Viewer integrated the @putinv RLVl-ike command everyone wished for.
While I am excited by the idea of how many things I could script now, I am quite worried about its griefing potential:
- the obvious issue:*any scripted item can be force-put into inv, and force-worn. And you should know how nasty scripts can be. In the RLV world that could mean forcing an auto-accepting, auto-locking relay, for instance (which kills the original idea that RLV commands only work by items you wear and that, for other objects, security is relay-enforced). But I am sure there is worse. It would be safer if it only worked with "dead" items like non-prim clothing and body parts.
- less important (maybe?): if it becomes widely used, it will become difficult to manage your inv. Why not restricting this command to a #RLV subfolder (like /#RLV/#Autoaccepted/) you could safely clean up?

Perhaps this is more something I should discuss with Saunuk Flatley. But well, Henri, you decided to include this into your viewer, so you should be interested in reviews!

[edit] example of a nasty script: the first RLV+LSL virus. It would spread through invs of agents using both Cool Viewer and an open relay. Very easy to script: the virus would force-give and force-attach itself to its victims, which would then be running their own copy, force-giving itself and so on.
Please fix this quickly! ^^
Saunuk Flatley
Registered User
Join date: 23 Sep 2007
Posts: 2
03-16-2009 04:35
Hello, Satomi

From: Satomi Ahn

- the obvious issue:*any scripted item can be force-put into inv, and force-worn. And you should know how nasty scripts can be. In the RLV world that could mean forcing an auto-accepting, auto-locking relay, for instance (which kills the original idea that RLV commands only work by items you wear and that, for other objects, security is relay-enforced). But I am sure there is worse. It would be safer if it only worked with "dead" items like non-prim clothing and body parts.


Actually, I was thinking about this security issue. I think it's not very serious. This issue was introduced by #RLV folder scripted attach feature itself. You can't control or check scripts inside of all your attachments. And they can perform malicious action independently. Many relays that I've seen require confirmation even in "Open" mode when accessed by scripts other than owner or landowner. So I think there won't be any serious virus danger. But I agree that @putinv puts severity of this issue higher.
So I can propose some resolution for this issue. For example any RLV command that came from attachment inside #RLV subfolder can be turned off.

From: Satomi Ahn

- less important (maybe?): if it becomes widely used, it will become difficult to manage your inv. Why not restricting this command to a #RLV subfolder (like /#RLV/#Autoaccepted/) you could safely clean up?

It can be done. But still we need to have more peoples opinion on this subject.
Lance Corrimal
I don't do stupid.
Join date: 9 Jun 2006
Posts: 877
03-16-2009 05:55
From: Saunuk Flatley
It can be done. But still we need to have more peoples opinion on this subject.



after hearing some of the bad experiences that a friend of mine had with some of the more benign "mistresses" out there in SL, i would strongly advise that a feature that has the potential of forcing a sub to accept and then wear a scripted attachment w/o consent that could do some serious not bdsm related damage, like for example stealing all the subs money, should be switched on and off separately, and be switched off by default.

a friend of mine first ran into a domme who demanded a five digit "submissive acceptance fee", then later ran into one that made her use RLV without explaining the various possible restrictions to her, and used her as a whore in her brothel.
and i am pretty sure that that "usage" was way out of what my friend would have consented to.

Even with RLV in use, the whole BDSM "play" should be based on mutual consent and trust.
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 06:16
Well, @attach:xxxx=force, alone is not that a security threat, as you can choose to put in #RLV only items you have good reasons to think they are safe.
@putinv alone is not too dangerous either, sure. Only @putinv+@attach together is dangerous.

As for relays: a lot also accept commands from everyone too (I personnally prefer that kind of setting!), and well, even in ask mode, most of relays (if not all) do not show the command that will be sent.
If @putinv remains like this in Cool Viewer, I'll have to filter that command seriously in the relays I make (first rlv command ever to receive such a treatment!).

Your proposed resolution won't prevent virusses from spreading, as you don't need to issue RLV commands to the viewer to propagate it (blocking chat on relay channel would work, but as scripts run on the server, you can do nothing about that).
Should I write this virus as a proof of concept? (I am quite reluctant to take the risk to be responsible for such an epidemy, though!)

Then what can be done? I don't know. I suppose it is not possible to analyze objects/scripts you force-accept into your #RLV (the bytecode is on the server).
Would it be possible just to filter out prim objects (as only those can contain scripts)? It has to be possible, as objects have a different icons in your inv than other assets.
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 06:25
/me thinks how ironic the situation is.
Indeed, I had recently a talk with Marine Kelley on how she should be more open to new commands, and now I am arguing in favor of serious limitations ;-).

Anyway, I believe it would really be good to have a (wiki?) page for discussing RLV extensions and reviewing each other's proposals.

If we keep like this, it is obvious people will propose their own patches and integrate those into some custom builds (like Cool Viewer, Imprudence, or their own flavor) by themselves, as Marine refuses those in her RLV. "By themselves" means those extensions are likely not to be seriously enough reviewed.
Boy Lane
Evil Dolly
Join date: 8 May 2007
Posts: 690
03-16-2009 06:43
There is no way that any script can steal any money from you unless you give your explicit consent to this by clicking on a yellow alarm popup first.

It's also not an issue of CV at all. The RLV feature is off per default and it behaves like every other "normal" viewer. Unless again you decide to switch RLV mode on AND restart the viewer to activate it. And you wear a relay in auto accept mode.

Both are decisions of every individual using technical options provided. And they are responsible for their decisions, the same way as they are in RL.

It's important to inform people about risks of toys they are using, but thats part of BDSM education, not part of a technical discussion.
_____________________
Cool Viewers for Virtual Worlds, Home of Rainbow: http://my.opera.com/boylane
Download: http://coolviewer.googlecode.com
Source: http://github.com/boy

Be plurked: http://plurk.com/BoyLane/invite :)
Boy Lane
Evil Dolly
Join date: 8 May 2007
Posts: 690
03-16-2009 06:46
From: Satomi Ahn
Anyway, I believe it would really be good to have a (wiki?) page for discussing RLV extensions and reviewing each other's proposals.


That wiki page is here :): http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI
_____________________
Cool Viewers for Virtual Worlds, Home of Rainbow: http://my.opera.com/boylane
Download: http://coolviewer.googlecode.com
Source: http://github.com/boy

Be plurked: http://plurk.com/BoyLane/invite :)
Lance Corrimal
I don't do stupid.
Join date: 9 Jun 2006
Posts: 877
03-16-2009 07:18
From: Boy Lane
There is no way that any script can steal any money from you unless you give your explicit consent to this by clicking on a yellow alarm popup first.


and yet there are enough people stupid enough to click on any "yes" button they see...

From: Boy Lane
It's also not an issue of CV at all. The RLV feature is off per default and it behaves like every other "normal" viewer. Unless again you decide to switch RLV mode on AND restart the viewer to activate it. And you wear a relay in auto accept mode.


see my comment above.

From: Boy Lane
Both are decisions of every individual using technical options provided. And they are responsible for their decisions, the same way as they are in RL.

It's important to inform people about risks of toys they are using, but thats part of BDSM education, not part of a technical discussion.


Still sometimes i think a little popup informing the user of the possible risks would be a good thing, maybe when the user enables RLV for the first time for a given avi... similar to the "this is your inventory" popup you get when you open your inv for the first time.
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 07:20

No, the status of that page isn't that clear.
As I see it, it is a description of Marine's API.
Sure you can comment the page, but she does not read the discussion page, and as she is the only "official" RLV developper, this makes no sense.

A discussion page as I suggest only makes sense if RLV (or some fork of RLV, if it comes to this!) becomes a communautary project.

From: someone
It's also not an issue of CV at all. The RLV feature is off per default and it behaves like every other "normal" viewer. Unless again you decide to switch RLV mode on AND restart the viewer to activate it. And you wear a relay in auto accept mode.

Here again, I partially agree: when turning on RLV, you expect it to behave like Marine defined it, not with some hidden features/loopholes.
And even if @putinv became more official, as it has a lot more security issues than other commands, it would make sense if it had its own switch (like setenv commands).
Still, I don't like the idea to have "partially activated RLV" viewers, it makes really difficult to know what to expect when you script. It would be far better to be able to expect the same behavior from every RLV enabled viewer.
Innula Zenovka
Registered User
Join date: 20 Jun 2007
Posts: 1,825
03-16-2009 07:31
While I tend to agree, in principle, that anyone who uses RLV and an auto-accept relay deserves to learn the hard way what this can actually entail, I think the relevant question here is, how do Henri, Boy and Hyang feel about the spam that's almost inevitably soon going to start flooding groups about, "Don't use the Cool Viewer. My friend did and it let someone steal all her money"?

/me braces herself to explain to the dozens of friends to whom she's recommended the Cool Viewer that no, their money is perfectly safe unless they behave like complete idiots....
Henri Beauchamp
Registered User
Join date: 8 Oct 2006
Posts: 253
03-16-2009 08:00
From: Boy Lane
There is no way that any script can steal any money from you unless you give your explicit consent to this by clicking on a yellow alarm popup first.

It's also not an issue of CV at all. The RLV feature is off per default and it behaves like every other "normal" viewer. Unless again you decide to switch RLV mode on AND restart the viewer to activate it. And you wear a relay in auto accept mode.

Both are decisions of every individual using technical options provided. And they are responsible for their decisions, the same way as they are in RL.

It's important to inform people about risks of toys they are using, but thats part of BDSM education, not part of a technical discussion.


Thank you Boy, for replying. I would have done it earlier without some recent issues with secondlife.com not loading here...

I will add that you can always mute the resident whose script is giving you stuff in #RLV. After being muted, all the scripts pertaining to this resident will be unable to give you anything (so if someone creates a worm, muting them and/or banning them from the parcel prevents propagation).

Also, like you pointed out, in order for a @putinv command to reach your viewer you must first have accepted and worn a scripted item, or be wearing a relay and have accepted the relayed command (if you choose the auto-accept for everyone mode in the relay, it's your responsibility... I personally don't recommend it).

This said, and like I told to Marine, I am ready to reconsider the implementation of this feature and discuss further security tightening. This is why I did write "PRELIMINARY SPECIFICATION" in the RLV Wiki for @putinv. I means that this command can still be amended. However, this feature is very much desired and big plus to the TF (transformists) community (but not only: think about the number or devices which require that you wear accessories when using them... I could cite the Real Slut display, the latexification machines, etc...).

One possible improvement would be to allow @putinv only for devices on which you are already sitting on... Any thought about that ?

@Satomi Ahn:

Be sure that I won't add commands without carefully thinking about it. For your info, I took one full week of testing before releasing the @putinv feature publicly, based on a patch given to me by Saunuk Flatley (and for which we discussed quite a bit about the implementation together) and that I further modified. I'm not a script kiddy. I've got 3 decades of experience (both personal and professional) into computing and programming.
Boy Lane
Evil Dolly
Join date: 8 May 2007
Posts: 690
03-16-2009 08:08
From: Innula Zenovka
I think the relevant question here is, how do Henri, Boy and Hyang feel about the spam that's almost inevitably soon going to start flooding groups about, "Don't use the Cool Viewer. My friend did and it let someone steal all her money"?
Honestly? I don't care. Happened before and happens all the time that someone spreads FUD. I commented once on my blog:

"There are people spreading rumours about the Cool Viewer inworld. That it saves your password, and that it sends it to the "Lindens". To be honest....yes, this is true. All of it. CV saves your last password locally as every other viewer does, to make your next login more convenient. And....to make it worse....it even sends the password to the "Lindens". Otherwise you could not login into SecondLife *giggles*. Makes sense?! :)"

I make CV for my own use and I never touched anything else since I do so. If people like it they can use it, if not...up to them :). It's non profit and there are not even advertisements on our websites. But if someone really pisses me off I may also just stop. Simple as that. :)
_____________________
Cool Viewers for Virtual Worlds, Home of Rainbow: http://my.opera.com/boylane
Download: http://coolviewer.googlecode.com
Source: http://github.com/boy

Be plurked: http://plurk.com/BoyLane/invite :)
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 08:29
Thank you for your answer Henri.
No, I don't think you're a script kiddy^^. Your viewer proves otherwise.

I am just a bit worried here. And your answer does not fully satisfy me:
1 - muting everyone around is as nice a resolution as quarantines in a plagued city (muting only the resident who started it won't work)
2 - you don't necessarily notice what is going on (like 99% of zombified computer owners, by the way!)
3 - moving all the security relay side is not something we should wish for... and it is not possible, anyway: the only way to do this would be to display the full text of every relay command before asking, and this assuming the user can understand them! And well... what is the point of having a command that forces acceptation of items, if you have to ask beforehand?

Until now, you could safely assume no permanent damage would be done by auto-accepting relay commands. Now it is not true anymore.

As for the justification of @putinv: yes... it is really an interesting command, and maybe a killer feature too (if only security issues were adressed). Please keep it in some form!
I am actually quite happy to see that RLV extensions are not anymore Marine's exclusivity.

From: someone
One possible improvement would be to allow @putinv only for devices on which you are already sitting on... Any thought about that ?

We could try to work on this...
Accepting scripted objects from trusted* sources shouldn't worry us too much.
Still preserving the ability for other sources to send unscripted items (clothes, body parts) would be nice too. As a remark, for the TF community, body parts is already 80% of what is needed!

*: but who is to be trusted? Choosing this into a script (the relay) would be great, but still, how could we make it so that older relays do not accept @putinv for untrusted sources, even in auto-accept?
I don't know, maybe you're right that this is not the viewer's job, but I can predict some troubles in the future...
Henri Beauchamp
Registered User
Join date: 8 Oct 2006
Posts: 253
03-16-2009 09:12
From: Satomi Ahn
1 - muting everyone around is as nice a resolution as quarantines in a plagued city (muting only the resident who started it won't work).
What I meant is that if someone is known to spread (tentative) worms (these are not truly worms since they need each user/victim to do a stupid action in order to be able to propagate), it is an easy task to break all the worms, just by muting them.

From: someone
2 - you don't necessarily notice what is going on (like 99% of zombified computer owners, by the way!)
This remark goes for any RLV command...

From: someone
3 - moving all the security relay side is not something we should wish for... and it is not possible, anyway: the only way to do this would be to display the full text of every relay command before asking, and this assuming the user can understand them! And well... what is the point of having a command that forces acceptation of items, if you have to ask beforehand?

Until now, you could safely assume no permanent damage would be done by auto-accepting relay commands. Now it is not true anymore.
Please, don't spread FUD, and define "Permanent damage"... There is NO such possible damage with @putinv, and no more and no less risk than with other commands, or even with non-RestrainedLife stuff: after all, 90% of the scripted stuff in SL is closed source, and any of this stuff could contain malicious code: do you worry about such an eventuality after you buy (or accept) a scripted item and wear it for the first time ?... You should if you do worry about @putinv...

From: someone

As for the justification of @putinv: yes... it is really an interesting command, and maybe a killer feature too (if only security issues were adressed). Please keep it in some form!
I am actually quite happy to see that RLV extensions are not anymore Marine's exclusivity.
OK, let me be clear about this: if I made this feature public, it's because:
- I myself wanted such a feature and participated in defining its implementation;
- I spoke about it to Marine and showed her the diff between her 1.16.1 patch mine (I always do that, so that she can catch up with the bug fixes and improvements i add to her patch): she admitted that the feature would be useful and she only mildly objected about security (I then gave her the reasons why I thought it was not a true security risk, see above for them). Marine however wrote me after the release to voice more worries (so, this feature will stay in a preliminary state for now, and no guarantee is given to whether it will stay or not, and if it does stay, in what form).

*However*
I am *NOT* going to take over Marine to develop further the RestrainedLife specifications. I will keep communicating with her (like I always did since v1.0) whenever I feel like a new feature should be implemented or an existing feature amended. If you want a new feature, please speak to Marine about it.

From: someone
We could try to work on this...
Accepting scripted objects from trusted* sources shouldn't worry us too much.
Still preserving the ability for other sources to send unscripted items (clothes, body parts) would be nice too. As a remark, for the TF community, body parts is already 80% of what is needed!
This won't cover 20% or the actual needs, since most of the accessories given by devices are prim attachments (for example, the Real Slut display gives you a "barin implant" and a gag).

From: someone
*: but who is to be trusted? Choosing this into a script (the relay) would be great, but still, how could we make it so that older relays do not accept @putinv for untrusted sources, even in auto-accept?
I don't know, maybe you're right that this is not the viewer's job, but I can predict some troubles in the future...
I predict a lot of fuss and FUD, and no consequence at all..
Saunuk Flatley
Registered User
Join date: 23 Sep 2007
Posts: 2
@putinv issue
03-16-2009 10:10
Speaking of tightening security, I have another proposal. There could be done some menu with the list of trusted/distrusted avatars. Some kind of mute list in reversal. Every object that tries to use @putinv command, that not in the list, would cause allow/deny request. And all other requests from that avatar would be permitted or denied accordingly to this list. But this feature would require much more effort than original patch and I personally think that we should wait a bit and see how it would turn out.
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 10:19
From: someone
What I meant is that if someone is known to spread (tentative) worms (these are not truly worms since they need each user/victim to do a stupid action in order to be able to propagate), it is an easy task to break all the worms, just by muting them.

Is using cool viewer with an auto-accept relay a stupid action? This makes a lot of people "stupid".
Or rather: people who used not to be stupid, now suddenly become that, and could get muted without knowing what is happening...
(as a sidenote, worms for other platforms often require "stupid" actions... )

"permanent damage": helping a worm spread is not something you can easily undo, or only at the price of drastic counter-measures, as it is not only about cleaning yourself.
Here you involuntary and unknowingly grief other people, don't tell me it was already so in RLV!
(Btw, I am curious how you can actually block every instance of a particular script... Don't they have all a different uuid? Can't they also have a randomly generated name/behavior? Or do you mute every infected agent? Couldn't this muting by itself be considered as a victory for the worm in griefing people?)

Note that if malicious scripts always existed, none until now had the power to infect agents without requiring any special action from them (wearing an auto-accepting relay is hardly an action! It is even a normal behavior among RLV users.).


Well, I believe I don't need to explain further and that you know what I am afraid of (and don't call that FUD!). If you believe the issue is not serious enough, I'll stop arguing for now^^

Now I am more excited at the idea of scripting with @putinv (and being targetted by it!) than worried anyway. Let us deal with abuses later if there is any (as long as @acceptpermission does not work for L$, that's ok^^).
Henri Beauchamp
Registered User
Join date: 8 Oct 2006
Posts: 253
03-16-2009 11:13
From: Satomi Ahn
Is using cool viewer with an auto-accept relay a stupid action? This makes a lot of people "stupid".
Or rather: people who used not to be stupid, now suddenly become that, and could get muted without knowing what is happening...
(as a sidenote, worms for other platforms often require "stupid" actions... )

Well, as far as I am concerned, auto-accepting anyone's RLV relayed commands is as stupid as opening the attachments in all "You won $1 billion" emails... Yes, this is what the simplest "worms" do rely upon. True worms however do not require such actions to spread.

From: someone

"permanent damage": helping a worm spread is not something you can easily undo, or only at the price of drastic counter-measures, as it is not only about cleaning yourself.
Here you involuntary and unknowingly grief other people, don't tell me it was already so in RLV!
Self-replicating scripted items existed since day one of scripting in SL... Back in 2006, they even used to spread havoc on the grid and caused grid crashes, till Linden Lab found a way to detect and get rid of such worms/virii.

This said, targeting the BDSM community, and among them, the ones using a RLV viewer, and among the latter, the ones with a relay in "auto-accept everyone's stuff" mode, would be a very poor way of spreading a worm...

From: someone

(Btw, I am curious how you can actually block every instance of a particular script... Don't they have all a different uuid? Can't they also have a randomly generated name/behavior? Or do you mute every infected agent? Couldn't this muting by itself be considered as a victory for the worm in griefing people?)
Simply mute the owner of the offending scripted object, or any object pertaining to them (including the offending object itself). Then all the scripts pertaining to this person cannot give anything to you, IM you, attach to you, etc..
Of course, if you are wearing the offending object (i.e. it was already given to you), you will have to detach it (if locked, relog with RestrainedLife off and detach).

From: someone

Note that if malicious scripts always existed, none until now had the power to infect agents without requiring any special action from them (wearing an auto-accepting relay is hardly an action! It is even a normal behavior among RLV users.).
Let's see it this way: why do you think Marine refused to allow @rlv commands to be issued by anyone but the owner of the script ? If she had allowed it, there would be no needs for relays... Now, if you use a relay in a mode where no security check (trustfulness) and no question is asked before the commands get relayed, you pretty much defeat what Marine tried to avoid... While it is legit and fun to use such a "trust everyone, accept anything" mode on your relay in a safe environment (private parcel and known people around), you cannot decently complain to be the victim of grievers if you do this in a random sim, with random people around...

From: someone

Well, I believe I don't need to explain further and that you know what I am afraid of (and don't call that FUD!). If you believe the issue is not serious enough, I'll stop arguing for now^^

Now I am more excited at the idea of scripting with @putinv (and being targetted by it!) than worried anyway. Let us deal with abuses later if there is any (as long as @acceptpermission does not work for L$, that's ok^^).
I personally think that even as it is now, the @putinv feature does not represent a significant threat to anyone, but like I said, I'm open to *constructive* proposals to improve its security.
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 11:33
(trying to be constructive)
As I*see it, the alternative is now between:
1 - restricting @putinv
2 - leaving it as it is now, and implement more restrictive security into relays

1 - makes @putinv a lot less attractive (but 100% safe)
2 - is functionnally better, but makes new relays even more complicated, and old relays unsafe (even in ask mode, as you usually don't know what the command is)

However (2) has an advantage as it will make a lot of relay protocol extensions useless, as they can be implemented into a force-worn script.
If worms start spreading, people will quickly forsake their old relays too.
I believe I prefer (2).

Hm some thought: what about a different command for enabling auto-accepting unscriptable items?
This command could be auto-accepted by relays, while @putinv could still be filtered for untrusted sources.
Having 2 commands would be like having advantages from both (1) and (2).
Kitty Barnett
Registered User
Join date: 10 May 2006
Posts: 5,586
03-16-2009 16:11
From: Henri Beauchamp
I personally think that even as it is now, the @putinv feature does not represent a significant threat to anyone, but like I said, I'm open to *constructive* proposals to improve its security.
*waves*

I would agree that any potential "danger" is limited to mischief (attaching a scripted attachment that will lock on which would take 2 relogs to get rid of - one to detach, one to get back in RLV), but it can still be rather annoying to have to go through that.

When I thought about looking into a similar command my thought was to move things into an #RLV-Sandbox folder rather than the standard #RLV folder.

Scripted attachments within the "sandbox" would just have their RLV commands silently ignored (the loophole would be to have the attachment rez a prim that issues RLV commands instead but that can be taken care by deleting the prim, tp'ing away, or moving out of draw distance in which case the garbage collector will clean up the restrictions).

@attach*/detach*=force for folders in the #RLV-Sandbox would be limited to the attachment that put it there in the first place as well.

(Since the folder was put there in the first place, there's already an attachment - be it a regular attachment or a relay - capable of executing RLV commands on the avie, so preventing any given attachments from doing so doesn't really limit the usefulness of @putinv that much)
Henri Beauchamp
Registered User
Join date: 8 Oct 2006
Posts: 253
03-16-2009 16:28
Here are two new releases of the Cool SL Viewer, available now for Linux from http://sldev.free.fr/:

Cool SL Viewer v1.19.0.5 release 53 (stable branch, legacy renderer)
Cool SL Viewer v1.22.11.0 release 3 (stable branch, Windlight renderer)

These releases are aimed at RestrainedLife users (others may keep using the previous releases if they so wish), and update RestrainedLife to v1.16d: the @putinv command is now disabled by default (and can be enabled by setting the RestrainedLifeAllowPutInv debug setting to TRUE), and when a sub-folder is given to the #RLV folder after a successful @putinv, this is logged (into the chat log floater) instead of being done silently. This will hopefully reassure the most paranoid users ;-P
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-16-2009 16:55
I hope this is only something temporary until we come up with something better?
(still, having somewhere to discuss it would be great... I don't feel that here is the right place for it... )
Lance Corrimal
I don't do stupid.
Join date: 9 Jun 2006
Posts: 877
03-17-2009 03:06
From: Kitty Barnett
*waves*

I would agree that any potential "danger" is limited to mischief (attaching a scripted attachment that will lock on which would take 2 relogs to get rid of - one to detach, one to get back in RLV), but it can still be rather annoying to have to go through that.



i dunno, with that command a benign sub could seriously hurt others and put all blame on the subs.

forced tp + forced attachment that rezzes griefer objects...
Lance Corrimal
I don't do stupid.
Join date: 9 Jun 2006
Posts: 877
03-17-2009 03:06
From: Henri Beauchamp
Here are two new releases of the Cool SL Viewer, available now for Linux from http://sldev.free.fr/:

Cool SL Viewer v1.19.0.5 release 53 (stable branch, legacy renderer)
Cool SL Viewer v1.22.11.0 release 3 (stable branch, Windlight renderer)

These releases are aimed at RestrainedLife users (others may keep using the previous releases if they so wish), and update RestrainedLife to v1.16d: the @putinv command is now disabled by default (and can be enabled by setting the RestrainedLifeAllowPutInv debug setting to TRUE), and when a sub-folder is given to the #RLV folder after a successful @putinv, this is logged (into the chat log floater) instead of being done silently. This will hopefully reassure the most paranoid users ;-P




that is way better, thanks ;)
Satomi Ahn
Registered User
Join date: 28 Oct 2008
Posts: 15
03-17-2009 03:39
Heh, I may be paranoid, but this change is not what I suggested!
(I have no strong opinion about it... if @putinv isn't enabled by default, isn't there a risk for that command to remain widely unknown?)
1 ... 12 13 14 15 16 17 18 19 20