Difference between revisions of "User:Robin Cornelius/ExecSummary"
| Line 30: | Line 30: | ||
* How would we update the list? | * How would we update the list? | ||
* Are we really going to have to jump through hoops | * Are we really going to have to jump through hoops every time we make a minor change? | ||
Things like gnupg could avoid much of this as you could check the key was for an example the "Emerald developers" key, you wound not need to change the registry at all and the 3rd party devs could push out as many releases as they liked they just sign with there private key and the viewer registry contains the public key. Debian uses this system for there official apt repositories BUT there is *no requirement* in Debian to use there official apt repository, a user could simply download a deb from a web site or use a 3rd part apt repository and this should not be a requirement here either | Things like gnupg could avoid much of this as you could check the key was for an example the "Emerald developers" key, you wound not need to change the registry at all and the 3rd party devs could push out as many releases as they liked they just sign with there private key and the viewer registry contains the public key. Debian uses this system for there official apt repositories BUT there is *no requirement* in Debian to use there official apt repository, a user could simply download a deb from a web site or use a 3rd part apt repository and this should not be a requirement here either | ||
The other extreme of the viewer registry is only allowing approved viewers to connect to SL, this is related to the Authentication topic which i will discuss next. But this falls in to the whole category of limiting access to SL. Limiting SL access would IMHO be a very very bad move by LL, again the same questions of how to get approved come up, but now they have a real urgency and seriousness to them which much not be understated. There are many many viewers out there, all kinds of service bots, text clients, web clients as well as the ones produced by LL. Just trying to process this number of viewers would be difficult, and you will result in many authors just not bothering at all. There are viewers being developed for light operation with out graphics for low end systems, viewers designed for the blind user. There are also viewers for systems systems as 64bit linux, *BSD etc. These mostly require custom viewers to work on the grid. Often the end user is recompiling the viewer themselves just to get in SecondLife. In some cases such as omvviewer, this was allowing a lot of 64bit linux users to connect that otherwise would not be able to, or would suffer frequent crashes due to 32/64bit mixed issues. Loosing many of these viewers would prevent significant numbers of users connecting to the SL service and also break significant in world content and systems that require bots to operate. | The other extreme of the viewer registry is only allowing approved viewers to connect to SL, this is related to the Authentication topic which i will discuss next. But this falls in to the whole category of limiting access to SL. Limiting SL access would IMHO be a very very bad move by LL, again the same questions of how to get approved come up, but now they have a real urgency and seriousness to them which much not be understated. There are many many viewers out there, all kinds of service bots, text clients, web clients as well as the ones produced by LL. Just trying to process this number of viewers would be difficult, and you will result in many authors just not bothering at all. There are viewers being developed for light operation with out graphics for low end systems, viewers designed for the blind user. There are also viewers for systems systems as 64bit linux, *BSD etc. These mostly require custom viewers to work on the grid. Often the end user is recompiling the viewer themselves just to get in SecondLife. In some cases such as omvviewer, this was allowing a lot of 64bit linux users to connect that otherwise would not be able to, or would suffer frequent crashes due to 32/64bit mixed issues. Loosing many of these viewers would prevent significant numbers of users connecting to the SL service and also break significant in world content and systems that require bots to operate. | ||
Revision as of 03:26, 28 October 2009
ToDO TODAY!
I'm sketching out ideas here over my working day and expanding out on topics, feel free to ping me on AWG/#opensl for live discussion
Key areas
- Viewer registry
- Viewer Identification
- Encryption
- Server/Protocol security issues
- Open source contributions to the stability and features of LL viewer
- Open source inventions, new ideas, creativity with 3rd party viewers
- non LL code base viewers and utility programs (text clients and bots)
- Clari faction of TOS points
Viewer registry
Currently the entire concept of what is proposed by LL is very unclear and there is concern from the community that the entire concept may not work at all. Discussions on the Initial blog comments and at our pre-BB meeting has highlighted many of the concerns. The possible implementations we can visualize of this idea range from a simple list of "approved" viewers to only allowing "approved" viewers to connect to the grid.
Starting from the simple list extreme - There is some support for some ideas in this area from many in the opensource community, but this depends on exactly what is proposed. Some basic questions that cover all possible implementations include :-
- How would you get on this list?
- Who is making this decision?
- How are "approved" viewers actually checked?
Subject to the above questions, the most basic implementations is just a list of viewers linking to there websites. Almost like we already have on the wiki now [link needed]
One issue here is that a list could give users some confidence in the viewer as a common concern is, "how can i trust a 3rd party viewer with personal information such as username/password combinations?". But conversely NOT being on the list could be seen as being an evil viewer and this is not a good situation either.
Moving along the scale we have things like providing some kind of crypographic signature for viewer binaries so that the list of approved viewers also contains, for a trivial example, a MD5 sum, or even a gnupg signature, so the user would then know they were getting the real thing from the 3rd part developer, whist the basic concept of "signing" a viewer is ok to many, if this was on the list it open up new questions :-
- How would we update the list?
- Are we really going to have to jump through hoops every time we make a minor change?
Things like gnupg could avoid much of this as you could check the key was for an example the "Emerald developers" key, you wound not need to change the registry at all and the 3rd party devs could push out as many releases as they liked they just sign with there private key and the viewer registry contains the public key. Debian uses this system for there official apt repositories BUT there is *no requirement* in Debian to use there official apt repository, a user could simply download a deb from a web site or use a 3rd part apt repository and this should not be a requirement here either
The other extreme of the viewer registry is only allowing approved viewers to connect to SL, this is related to the Authentication topic which i will discuss next. But this falls in to the whole category of limiting access to SL. Limiting SL access would IMHO be a very very bad move by LL, again the same questions of how to get approved come up, but now they have a real urgency and seriousness to them which much not be understated. There are many many viewers out there, all kinds of service bots, text clients, web clients as well as the ones produced by LL. Just trying to process this number of viewers would be difficult, and you will result in many authors just not bothering at all. There are viewers being developed for light operation with out graphics for low end systems, viewers designed for the blind user. There are also viewers for systems systems as 64bit linux, *BSD etc. These mostly require custom viewers to work on the grid. Often the end user is recompiling the viewer themselves just to get in SecondLife. In some cases such as omvviewer, this was allowing a lot of 64bit linux users to connect that otherwise would not be able to, or would suffer frequent crashes due to 32/64bit mixed issues. Loosing many of these viewers would prevent significant numbers of users connecting to the SL service and also break significant in world content and systems that require bots to operate.