Second Life Wiki - User contributions [en]

Talk:Pre 1.20 Client parameters

2015-02-04T22:13:10Z

Prodigal Maeterlinck: /* grids.xml */ new section

Reworded -skin option and removed link to [[skin]], since this refers to the User Interface skin, not the avatar's skin. [[User:Simon Nolan|Simon Nolan]] 10:12, 15 May 2007 (PDT)

Added directions for Linux users. --[[User:Katheryne Helendale|Katheryne Helendale]] 00:37, 26 May 2009 (UTC)

== grids.xml ==

This file doesn't exist in the official installation, and this page contains the only reference to it in the wiki. Is there a source for this? [[User:Prodigal Maeterlinck|Prodigal Maeterlinck]] ([[User talk:Prodigal Maeterlinck|talk]]) 14:13, 4 February 2015 (PST)

Talk:Plugin architecture

2008-04-28T16:48:34Z

Prodigal Maeterlinck: /* Security Concerns */

{{Open Source Talk Page}}

Glad to see a conversation blooming here. Any chance we can see a little consolidation of these pages, though? Looks like we're sprawling out quite a bit. -- [[User:Rob Linden|Rob Linden]] 20:01, 12 February 2007 (PST)

== semantics ==

This should probably be moved to [[Project:Plugin architecture]]
<br />[[User:SignpostMarv Martin|SignpostMarv Martin]] 13:17, 14 February 2007 (PST)
:No, Project: is used for official metainformation about the open source project from linden lab. Things like policy statements and such. This namespace is fine. [[User:Gigs Taggart|Gigs Taggart]] 13:30, 14 February 2007 (PST)
::Is that LL policy, or a practice borrowed from the Wikipedia ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 13:35, 14 February 2007 (PST)
:::Yes, it is LL's policy. The bug in Jira to use multiple namespaces was shot down and closed WONTFIX. Fragmenting the namespace has negative effects on searching and no real benefit. Namespaces should be used for pages that are fundamentally different in some way, not as a way to partition articles. Please don't use the Project: namespace for articles. Just create the article and then tag it with categories it fits in. People can bring up the category page to look through pages in that category. [[User:Gigs Taggart|Gigs Taggart]] 13:45, 14 February 2007 (PST)
::::{{JIRA|WEB-22}} was Rob shooting down Strife's request to have "LSL" added as a custom namespace, '''not''' Rob shooting down any and all uses of built-in namespaces.
::::If this article is intended to be a hub for the standardisation and development of plugins & plugin architecture, then it should be moved to [[Project:Plugin architecture]], as it would be a "project" within the SL Wiki, as opposed to an article which describes the plugin architecture once it's defined.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 14:35, 14 February 2007 (PST)
::::P.S. This wouldn't go under "This wiki should function as one wiki, rather than as a bunch of tiny wikis that happen to share the same domain name.", as it is purely for organisational purposes, whereas Strife seems to want to segregate the wiki.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 14:40, 14 February 2007 (PST)

Actually, "Project:" should be reserved for meta information about this wiki itself. On most MediaWiki installs, the "Project:" namespace is equal to the name of the wiki itself, but I unset that option, thus "Project:" is the sole way of getting to that namespace. The things that go into the "Project:" namespace should be limited to those things that are about editing policy, etc. -- [[User:Rob Linden|Rob Linden]] 14:47, 14 February 2007 (PST)
:Ah. So is [[User talk:SignpostMarv Martin/Sandbox/Project:Internationalisation|Project:Internationalisation]] a good use of the namespace or not ?
:[[User:SignpostMarv Martin|SignpostMarv Martin]] 15:16, 14 February 2007 (PST)
::Looks good to me. [[User:Gigs Taggart|Gigs Taggart]] 15:56, 14 February 2007 (PST)

== plugin creation complexity ==

#How complex are plugins going to be to create ?
#Could plugins be written in notepad, or would they have to be developed in an IDE then compiled ?
#If a plain-text scripting language were to be used, what languages would be advocated for use ? Javascript <small>(yay greasemonkey!)</small> ? Perl ? Ruby ? Python ? All of the above ?

[[User:SignpostMarv Martin|SignpostMarv Martin]] 19:34, 14 February 2007 (PST)

:We're not even close to this point in development or planning. I'm pretty sure higher level scripting languages will make it into client plugins eventually.
:--- [[User:Baba Yamamoto|Baba Yamamoto]] 19:10, 16 February 2007 (PST)
== parameter passing ==
I don't like the idea of anonymous pointers for parameter passing. I think that some kind of parameter list is essential.
<pre>
typedef struct {
int sl_param_id; // Defined in the particular function's API
enum {
SL_INT32, SL_INT64, SL_FLOAT32, SL_FLOAT64, SL_STRING, SL_ALLOCED_STRING, ...
} sl_type; // Plugin may ignore parameters
int sl_required; // If set, plugin MUST handle this parameter
int sl_changed; // Zero before any plugin called, non-zero if any plugin has changed it
int64_t sl_value; // If the type is only 32 bits long, high 32 bits must be zero.
} sl_param;
typedef enum { SL_OK, SL_INCOMPATIBLE, SL_ERROR, SL_BREAK } sl_result;

sl_result sl_plugin(int count, sl_param params[], sl_param *error_info);
</pre>
The function calling the plugin can have all these set in a static structure, and only needs to zero out the sl_changed parameters and set up the initial values. Plugins do not call plugins, the list of plugins for the function are called sequentially by the sl_handle_plugins routine.
<pre>
if(my_plugins != NULL) {
my_params[0].sl_changed = 0;
my_params[0].sl_value = whatever;
final_result = sl_handle_plugins(my_plugins, 1, my_params, &error_param);
if(final_result == SL_BREAK) return success;
if(final_result == SL_ERROR) {
panic(error_param);
return failure;
}
}
</pre>

The plugin must at a minimum:

* verify that the sl_param_id values are what it expects and handle (even if by ignoring) the wrong values
* handle (even if by ignoring the parameter) the "wrong" types
* return SL_INCOMPATIBLE if any of the parameters it's ignoring have sl_required set.
* set sl_changed for any parameters it's changed
* fill in error_info if it returns SL_ERROR
* free an SL_ALLOCED_STRING if it changes the string
** make sure that the type of the new string parameter is SL_ALLOCED_STRING or SL_STRING to let the caller or later plugins know how to deal with them

The plugin may:

* Handle changes to the order of parameters as indicated by sl_param_id
* Handle changes to the types of parameters as indicated by sl_type
* Behave differently if a previous plugin has changed a parameter

Return values:

* SL_OK - Normal return, go on to the next plugin
* SL_INCOMPATIBLE - This plugin no longer works with this call. Let the user know and don't call this plugin again.
* SL_ERROR - This plugin has detected an error sufficiently severe that this call must abort. Should be rare.
** error_info must be set to { original_param_id, SL_STRING or SL_ALLOCED_STRING, TRUE, TRUE, error_message }.
* SL_BREAK - Don't call any further plugins, don't run the rest of the function, the plugin has completely handled the call.

-- [[User:Argent Stonecutter|Argent Stonecutter]] 06:48, 22 February 2007 (PST)

== content from Implementing new features ==

=== Embedded scripting language for client-side plugins ===
[[User:Heather Goodliffe|Heather Goodliffe]], [[User:Yumi Murakami|Yumi Murakami]], [[User:Argent Stonecutter|Argent Stonecutter]]

* Make the client more powerful and plugable
* Embed a scripting language, such as Javascript or Tcl or LUA or Python, within Second Life to enable client plug-ins to be written in a modular fashion. Client plugins would be distributed via Second Life itself; hopefully LL would eventually agree to create a new object type for these, but for testing purposes notecards would probably suffice.
* Let me second that: I'd like to see client-side scripting as well. It should be easy to add that (in particular, using Lua), and it would let users fix so many usability problems. At a minimum, the scripting language should be able to access the functionality available through the menus, it should permit key bindings and grab keys, access preference settings, and it should be able to listen to chat and IM, so that commands can be triggered from there. [[User:Jherek Cerminara|Jherek Cerminara]]

:One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.
:The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).
:This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.
:[[User:Duffy Langdon|Duffy Langdon]] 12:34, 10 January 2007

* Something to note: the above plugin architecture would make automatic glue code for scripting languages easy to write. [[User:Argent Stonecutter|Argent Stonecutter]] 06:56, 22 February 2007 (PST)

[[Category:Future Roundtables]]

== Automated Agents ==

Just curious, how does "Automated Agents" become a plugin ?

Or are you referring to "headless agents" in the context of having all IMs for a Resident's alts routed through into one instance of SL ?

[[User:SignpostMarv Martin|SignpostMarv Martin]] 22:15, 23 February 2007 (PST)

== Security Concerns ==

I believe the hardest part of the plug-in system will be to overcome to security concerns. How many trust being able to download and plug-in arbitrary code that might set off a money event. I've heard the casual user of SL not want to deal with such concerns. For that reason, I believe a scripting language is the way to go. We can limit the availability of the API to the scripts. This can be the default to allow arbitrary code in the form of scripts. [[User:Dzonatas Sol|Dzonatas Sol]] 01:54, 7 April 2007 (PDT)
: Unless a plugin disables the big-ass blue box notice that says "You just have Resident X L$10k", I think that it'll be difficult to wholesale rip people off.
: The suggested method for getting around the security concerns thing would be to have something like https://plugins.secondlife.com whereby each plugin listed on the site has been given the all-clear by Linden Lab as "not ripping people off".
: The API cannot be limited, as it'll be just a case of modifying the source code.
: [[User:SignpostMarv Martin|SignpostMarv Martin]] 04:56, 7 April 2007 (PDT)
::I'm pretty sure that a review system as you suggested above won't scale. [[User:Dzonatas Sol|Dzonatas Sol]] 11:29, 8 April 2007 (PDT)
::: Of course it won't. It's more reliable than limiting the API though.
::: [[User:SignpostMarv Martin|SignpostMarv Martin]] 02:53, 9 April 2007 (PDT)
::::It would be easier to allow an option to limit access to the API by default. Let the user decide to over-ride that. Also, there could be certification key like web browser do now. It wasn't the intent to make it impossible for even certifiable plug-ins to gain greater access. [[User:Dzonatas Sol|Dzonatas Sol]] 13:49, 9 April 2007 (PDT)
:::::L$ handling should go through the same permissions system an LSL-initiated call goes through.
:::::''''Plugin Foo created by Bar requests permission to debit your account''''
:::::A web-based interface along the lines of flickr should be a usable means of managing permissions.
:::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 16:45, 9 April 2007 (PDT)
: Some of this discussion happened a couple months back during Rob's office hours. Really, if the plugins are dynamically loadable libraries, you can't do much for security. Even if you don't expose something in the API, it's still accessible so long as the plugin has access to the memory space. What would make a lot of sense is creating scripting engines as plugins. If a scripting system proves to be secure, we might be able to eventually convince Linden Lab to ship the scripting system themselves.
: Creating a scripting system plugin should be pretty straightforward once the plugin system exists, so long as the scripting language has a nearly a one-to-one mapping of script functions to plugin API functions. --[[User:Soft Noel|Soft Noel]] 13:23, 10 April 2007 (PDT)
: All the same security issues apply to any third-party clients anyway. So why consider solutions that wouldn't be feasible in a discussion of the security of the whole executable? --[[User:Prodigal Maeterlinck|Prodigal Maeterlinck]] 13:59, 29 November 2007 (PST)
:: Not everyone uses third-party clients. Many people avoid them for security reasons. [[User:Argent Stonecutter|Argent Stonecutter]] 14:35, 31 December 2007 (PST)
::: And many of those same people will avoid plugins for the same reason, which only further demonstrates how moot the point is; the population of users who ''won't'' use third-party development isn't useful on a discussion forum concerned with developing third-party software. Plugins need no more or less of a reliable security certification process than client browsers themselves, and security isn't a good reason for delaying a plugin architecture. [[User:Prodigal Maeterlinck|Prodigal Maeterlinck]] 09:48, 28 April 2008 (PDT)

===Scripting API for security===
Some scripting languages have "Safe" interpreter modes: Javascript and Tcl immediately come to mind. Also, scripts are more easily eyeball-firewalled. [[User:Argent Stonecutter|Argent Stonecutter]] 14:35, 31 December 2007 (PST)
===External plugins for security===
While an external plugin, connected through a socket of some kind, could still use code injection attacks on the viewer it does raise the bar a little. On the other hand external plugins are limited in what they can do in the viewer... you would need to have them communicate (by chat, say) to a HUD to provide a user interface in-game. Still, this would be a useful option for many applications. [[User:Argent Stonecutter|Argent Stonecutter]] 14:35, 31 December 2007 (PST)

Talk:Viewer Authentication Critique

2007-12-06T21:07:47Z

Prodigal Maeterlinck:

{{Talk}}

== Process for editing the critique ==

By virtue of jumping first, I think [[User:Matthew Dowd|Matthew Dowd]] should be the working group chair for editing this document. What I think that means is this:
* Anyone can still make no-brainer edits to the article
* Matthew will be arbiter for dispute resolution, should that be necessary.
* If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.
* If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).
* If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to [[User:Matthew Dowd/Viewer Authentication Critique]], and other critiques could also be done the same way. This page would become a list of critiques.

Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- [[User:Rob Linden|Rob Linden]] 12:56, 29 September 2007 (PDT)

== Third party viewers/code ==

What's the substantive difference between these two points?
# Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
# Most of these attacks could be performed by any third-party software designed for use with SL
Both have many subpoints. Could they be consolidated into a single point? -- [[User:Rob Linden|Rob Linden]] 20:10, 29 September 2007 (PDT)

The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.

The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.

-- [[User:Argent Stonecutter|Argent Stonecutter]] 21:00, 29 September 2007 (PDT)

Is this better, Rob? -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:11, 29 September 2007 (PDT)

:Yes, that is. Thanks for the clarification! -- [[User:Rob Linden|Rob Linden]] 21:44, 29 September 2007 (PDT)

== No balance ==

This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each.
Even if this form of log in has these disadvantages it could still be an improvement over what we currently have.
We need a common point of reference to discuss if this is an improvement and what alternatives exist. [[User:Ahab Schmo|Ahab Schmo]] 12:31, 30 September 2007 (PDT)

== Nicholaz's Summary to SLDev ==

I think (and would be surprised otherwise) there currently consensus
among those who replied here on the list that ...

1) the new auth mechanism does nothing to significantly increase security
in terms of protecting user assets from malicious viewers (once the
viewer is logged in, you're at the mercy of the viewer, no matter how> you logged in)

2) the new auth mechanism makes login to SL cumbersome and breaks many
ways in which people are currently using SL (alts, switching between
viewers, etc.)

3) the new auth mechanism will make it impossible for some environment
to log in from at all (proxies, firewalls, security software, ...)
or prevent specific forms of viewers (lean viewers, mobile systems,
viewer on a memory stick, ...)

4) the new auth mechanism will break existing applications (bots, libsl,
etc.) and these will have to work around these.

5) Allowing these (4) to work around it, means that 3rd party viewers can
also work around it, meaning that you'll end up with 3rd party viewers
which are a lot more convenient than the official viewer, essentially> driving people away from the official viewer.

6) other mechanisms exist, which a) actually increase security and which
b) do not break existing use and c) are less cumbersome

7) (this is my personal addition but I'd be amazed if anyone disagreed)
people are losing a lot more assets and value through Linden
malfunctions (lost inventory, search & classifieds being not seen
because of outages, etc.) than have ever been lost through spoofing
or malicious viewers.

8) __whatever mechanism is implemented, should be a *choice* with the__
__existing mechanisms remaining in place__

9) (see (8) )

10) (see (9) )

Bottom line is that the new auth mechanism is something that offers neglectible
improvement in security and will cause countless problems or developer
hours on both sides.

== Anti-fraud measures! ==

It appears there is a greater desire to find anti-fraud measures than to just stop phishing attack by malicious code. Of course, both are of interest, but it appears the anti-fraud bit was stated weakly when in fact it the stronger point. I suspect a major miscommunication occurred here. The viewer itself was addressed by LL rather than augmented security for anti-fraud. I'm under the assumption that LL is not able to release some details to the public at this time, so we get bits and pieces of more minor points rather than the major points with priority.

The article mentions anti-fraud as an objective, but the criticisms are mainly focused on anti-phishing.

In fact, there is mention that anti-fraud is the priority! [https://lists.secondlife.com/pipermail/sldev/2007-October/005621.html]

Also, we can see the light of this from Robin Linden as pasted below.

I believe the critique needs to address the issue of anti-fraud more significantly. That is to allow such measures even if the anti-phishing has been addressed more (actually too much).

We need to help LL solve fraud in the many forms it appears besides just the login!

<pre>
http://slrecord.typepad.com/the_second_life_record/2007/10/vat-attack.html

(highly edited and cut to remove the mass discussion about VAT)

[11:00] LilMatty Althouse: recently absue reports have been ignored regarding a child sex parcel owner, multiple pictures have been provided and the response from the support team via a ticket has gone ignored and answered as 'if we do somethign we will do it' type attitude..... countless users have been reported by people at the sim
[11:00] LilMatty Althouse: conversations logged and re reported
[11:01] LilMatty Althouse: we would rather have something we can lgo as well please -
[11:01] Robin Linden: Lil - can you please email me at robin@lindenlab.com with the information?
[11:02] LilMatty Althouse: robin i have compiled a note card if that would be easier to drop you now
[11:02] Robin Linden: We can discuss whatever you'd like to talk about. :)
[11:02] LilMatty Althouse: and i can email you more information within a 12 hour period while i compile things into there
[11:02] LilMatty Althouse: if i may robin
[11:02] Robin Linden: I assume you're here to talk about VAT?
[11:02] LilMatty Althouse: as i have something non vat related :)
[11:02] Robin Linden: OK Lil
[11:12] LilMatty Althouse: how do you want me to email you, do i include documentation
[11:12] Robin Linden: LilMatty - let's take that offline. It's a serious charge and I'll need to get the authorities involved to investigate
[11:13] LilMatty Althouse: Ok then I have another question Robin :)
[11:13] LilMatty Althouse: Well robin the issue i mentioned earlier
[11:13] LilMatty Althouse: or evidence, abuse report tickets?
[11:15] Robin Linden: I have the notecard and will follow up.

[11:16] Jessica Holyoke: I have a question, when you stated that the ebay sellers of lindens were engaged in fraud,were they reported to law enforcement?
[11:16] Robin Linden: Not all eBay sellers of Lindens are engaged in fraud.
[11:18] Jessica Holyoke: but the one's that you said were engaged in fraud and took action against their accounts(sorry about the lag)
[11:19] Robin Linden: For the most part jessica people who engage in fraud have been tough to catch. We rarely know who they are in RL.
</pre>

----

There's really not a lot that software design can do to prevent social-engineering frauds, and it's not really the software's responsibility. The best you can do is inform and educate those who stay alert to communication, and hope word of mouth ripples out...even if that's in the form of urban legend hysteria, people will be more careful about what they exchange and who they exchange with.
[[User:Prodigal Maeterlinck|Prodigal Maeterlinck]] 13:07, 6 December 2007 (PST)

Talk:Plugin architecture

2007-11-29T21:59:30Z

Prodigal Maeterlinck: /* Security Concerns */