[sldev] Re: SLDev Digest, Vol 26, Issue 24

Adric R hakushakukun at gmail.com
Mon Feb 16 15:34:00 PST 2009


llViewerSay sounds like the only sane suggestion I've read thus far.

Benefits:
1. Not a hack.
2. Usable by multiple clients, doesn't interfere with clients that don't use
it.
3. Ease of access. No need for people to learn your system for tricking the
viewer into supporting the feature you need.
4. More trustworthy.
5. Some as-of-now unknown future feature will rock because this was
implemented.

Risks:
1. Someone might find a way to do something bad with it somehow.

Costs:
1. Some development time to make it happen.

Aside from the obvious benefit of, well, not being a hack, an official
implementation would also discourage the community from implementing even
more hacks and thus locking themselves into them (probably less-secure
versions at that).

Has anyone created a JIRA for this yet? Trying to pre-empt the first
question the Lindens always seems to ask when confronted with a good idea.

-- Adric AKA McCabe Maxsted inSL(tm)


On Mon, Feb 16, 2009 at 1:06 PM, <sldev-request at lists.secondlife.com> wrote:

> Send SLDev mailing list submissions to
>        sldev at lists.secondlife.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        /index.html
> or, via email, send a message with subject or body 'help' to
>        sldev-request at lists.secondlife.com
>
> You can reach the person managing the list at
>        sldev-owner at lists.secondlife.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SLDev digest..."
>
> Today's Topics:
>
>   1. Re: Script to client channel. (Marine Kelley)
>   2. Re: Script to client channel. (Dahlia Trimble)
>
>
> ---------- Forwarded message ----------
> From: Marine Kelley <marinekelley at gmail.com>
> To: Dimentox <dimentox at dimentox.com>
> Date: Mon, 16 Feb 2009 20:28:15 +0100
> Subject: Re: [sldev] Script to client channel.
> Hello all,
>
> I totally agree with the idea of a llViewerSay (channel, string) command,
> and would also support a llGetViewerString (string) to retrieve a string the
> viewer would have set into the sim at login (exactly like what
> llGetAgentLanguage does, but for arbitrary strings). That way the scripts
> will be able to retrieve custom messages in a synchronous and secure manner.
>
> On a side note, llOwnerSay (the way I have chosen to channel special RLV
> messages) is the most secure way to communicate directly with the viewer,
> the only price being it is spammy for non-RLV users. But good scripts check
> the viewer first, and stick to a "@version=2222" message and that's it. It's
> not totally painless, but it's not too annoying I think.
>
> If something like llViewerSay was implemented, I would also keep the "@"
> parsing on llOwnerSay, and also use llViewerSay the same way. Therefore old
> scripts won't become obsolete, and new scripts will benefit of this feature.
>
> Marine
>
>
>
> 2009/2/16 Dimentox <dimentox at dimentox.com>
>
>> Also the ownersay is spammy for people who are not using the custom viewer
>>
>>
>> On Mon, Feb 16, 2009 at 12:50 PM, Argent Stonecutter <
>> secret.argent at gmail.com> wrote:
>>
>>> On 2009-02-16, at 11:15, Thomas Shikami wrote:
>>>
>>>> Tony Dodd wrote:
>>>>
>>>>> As regards return traffic it is very easy to arrange for the viewer to
>>>>> send
>>>>> a string on some selected channel, though I suppose in the interests of
>>>>> clarity and security it might be better to add client to server
>>>>> messages
>>>>> with a new event type.
>>>>>
>>>>
>>>  This secure channel is already in the works, the viewer already supports
>>>> curl and the server side lsl scripts are about to support http_in.
>>>>
>>>
>>> I'm not sure how secure a channel this would be. There's nothing that
>>> tells a script that a connection via HTTP is coming from the client it's
>>> expecting. The chat version can be implemented securely enough for
>>> attachments to deal with any attack I can think of, since you can use
>>> llOwnerSay() for the script-client path, and verify the chat
>>> id==llGetOwner() for the response. If that's not good enough, then going to
>>> something with less authentication wouldn't be a step forward.
>>>
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> ---------- Forwarded message ----------
> From: Dahlia Trimble <dahliatrimble at gmail.com>
> To: sldev at lists.secondlife.com
> Date: Mon, 16 Feb 2009 11:45:40 -0800
> Subject: Re: [sldev] Script to client channel.
> The ownersay method doesn't need to be spammy to non-custom viewer users,
> the scripts that format the special ownersay messages could be triggered by
> the custom viewer only by saying an enable message on a special channel when
> an object containing the script is discovered, perhaps being discovered by a
> special texture UUID or some other uncommon marker. Or a prim bearing a
> special texture could be sent a touch event which could initiate special
> communication.
> I still think this can be accomplished without server modifications.
>
>
> On Mon, Feb 16, 2009 at 10:59 AM, Dimentox <dimentox at dimentox.com> wrote:
>
>> Also the ownersay is spammy for people who are not using the custom viewer
>>
>>
>> On Mon, Feb 16, 2009 at 12:50 PM, Argent Stonecutter <
>> secret.argent at gmail.com> wrote:
>>
>>> On 2009-02-16, at 11:15, Thomas Shikami wrote:
>>>
>>>> Tony Dodd wrote:
>>>>
>>>>> As regards return traffic it is very easy to arrange for the viewer to
>>>>> send
>>>>> a string on some selected channel, though I suppose in the interests of
>>>>> clarity and security it might be better to add client to server
>>>>> messages
>>>>> with a new event type.
>>>>>
>>>>
>>>  This secure channel is already in the works, the viewer already supports
>>>> curl and the server side lsl scripts are about to support http_in.
>>>>
>>>
>>> I'm not sure how secure a channel this would be. There's nothing that
>>> tells a script that a connection via HTTP is coming from the client it's
>>> expecting. The chat version can be implemented securely enough for
>>> attachments to deal with any attack I can think of, since you can use
>>> llOwnerSay() for the script-client path, and verify the chat
>>> id==llGetOwner() for the response. If that's not good enough, then going to
>>> something with less authentication wouldn't be a step forward.
>>>
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> _______________________________________________
> SLDev mailing list
> SLDev at lists.secondlife.com
> /index.html
>
>


-- 
"Work is love made visible." — Kahlil Gibran

"We will not walk in fear, one of another. We will not be driven by fear
into an age of unreason if we dig deep in our history and doctrine and
remember that we are not descended from fearful men, not from men who feared
to write, to speak, to associate and to defend causes which were for the
moment unpopular. We can deny our heritage and our history, but we cannot
escape responsibility for the result. There is no way for a citizen of the
Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090216/98448098/attachment.htm


More information about the SLDev mailing list