Talk:Plugin architecture - Revision history

Prodigal Maeterlinck: /* Security Concerns */

2008-04-28T16:48:34Z

Security Concerns

← Older revision		Revision as of 09:48, 28 April 2008
Line 134:		Line 134:
	: 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)		: 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)		:: 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===		===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)		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===		===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)		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)

Argent Stonecutter: /* Security Concerns */

2007-12-31T22:35:50Z

Security Concerns

← Older revision		Revision as of 15:35, 31 December 2007
Line 135:		Line 135:
	:: Not everyone uses third-party clients. Many people avoid them for security reasons. [[User:Argent Stonecutter\|Argent Stonecutter]] 14:35, 31 December 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)
	===Scripting API for security===		===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.		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===		===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.		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)

Argent Stonecutter: /* Security Concerns */

2007-12-31T22:35:19Z

Security Concerns

← Older revision		Revision as of 15:35, 31 December 2007
Line 133:		Line 133:
	: 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)		: 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)		: 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)
			===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.
			===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.

Prodigal Maeterlinck: /* Security Concerns */

2007-11-29T21:59:30Z

Security Concerns

← Older revision		Revision as of 14:59, 29 November 2007
Line 132:		Line 132:
	: 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.		: 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)		: 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)

Soft Noel: /* Security Concerns */

2007-04-10T20:23:25Z

Security Concerns

← Older revision		Revision as of 13:23, 10 April 2007
Line 130:		Line 130:
	:::::A web-based interface along the lines of flickr should be a usable means of managing permissions.		:::::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)		:::::[[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)

SignpostMarv Martin: /* Security Concerns */ response

2007-04-09T23:45:31Z

Security Concerns: response

← Older revision		Revision as of 16:45, 9 April 2007
Line 126:		Line 126:
	::: [[User:SignpostMarv Martin\|SignpostMarv Martin]] 02:53, 9 April 2007 (PDT)		::: [[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)		::::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)

Dzonatas Sol: /* Security Concerns */

2007-04-09T20:49:00Z

Security Concerns

← Older revision		Revision as of 13:49, 9 April 2007
Line 125:		Line 125:
	::: Of course it won't. It's more reliable than limiting the API though.		::: 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)		::: [[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)

SignpostMarv Martin: /* Security Concerns */ response

2007-04-09T09:53:25Z

Security Concerns: response

← Older revision		Revision as of 02:53, 9 April 2007
Line 123:		Line 123:
	: [[User:SignpostMarv Martin\|SignpostMarv Martin]] 04:56, 7 April 2007 (PDT)		: [[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)		::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)

Dzonatas Sol: /* Security Concerns */

2007-04-08T18:29:04Z

Security Concerns

← Older revision		Revision as of 11:29, 8 April 2007
Line 122:		Line 122:
	: The API cannot be limited, as it'll be just a case of modifying the source code.		: 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)		: [[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)

Rob Linden at 22:16, 7 April 2007

2007-04-07T22:16:45Z

← Older revision		Revision as of 15:16, 7 April 2007
Line 1:		Line 1:
			{{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)		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)

← Older revision		Revision as of 09:48, 28 April 2008
Line 134:		Line 134:
	: 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)		: 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)		:: 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===		===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)		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===		===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)		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)