I will not go into detail for all, on most parts I agree anyway. Its just the approach from which we are looking at it which differs.
Shad MOrdre wrote:
I'm not sure what you meant in point 1.
I tryed to see how many touches a NPC can do within 1 second. I came on 1200 touches per second on avarage. No what happens when someone has a npc touching everything available and a agent touches the the object while a view thousand touches are still beeing processed? What affect will it have on a sims cpu/ram/load usage and the viewer? It definatly has the potential to crash the entire server.
Shad MOrdre wrote:
...Additionally, what's to stop a user from creating multiple logins and performing the same actions as you describe?...
Nothing can prevent that. These logins however have unique key + name combination and require registrations, email validation and bots. Each bot needs to loggin and teleport to the region of desire. A NPC system can be scripted in less than a minute to create thousends of individual NPCs a day for manipulations.
Otherwise, I fully agree to what you said on permissions and responcebilitys of region owners etc. However, that all aplies to a System which only runs in an isolated enviroment were the stolen TV only affects the 1 customer and were the customer can blame himself for not providing the security.
Lets look at it from the view of a 3rd party developer who needs to make sure that nothing will result in dataloss for each single customer in a gridwide linked aplication. To reach a max possible security one has to asume the worst case scenario for the application (therefor also for all customers together). Worst case is:
- the regionowner, parcelowner and/or scriptowner does not know what they are doing
- griefers and hackers are taking advantage of the enviroment others are giving them
- the minimum available script functions can be used, but the maximum available script function can cause damage
In our OpenSim enviroment, the minimum available script function are the plain simple default lsl functions which only can be altered in the source code. If someone has scripts enabled, then these functions will always be available for use without any additional setup required. All saftymessures for the aplication must be limited to the minimum available function, because all other function are optional and might not be available for use. At the same time all optional functions (ossl, ls....) must be considered that could create damage to the system, therefor also to each and every customer of the aplication.
Now a gridwide operating application has the possebility to have a backend (web, regions with backend scripts etc.) which can filter many potentialy harmfull situation. Some issues do however need to adresses in localy (single regions) because there are no possibilities to get the required data from outside the single region, eg NPC functions.
Just like in any other enviroment there are constantly changes done,new functions get added or removed and griefers find new methods. In a 3rd party aplication this leads to required updates, action = reaction. And yes, coders will not always be ahead of the changes been done, especialy not in opensource. Opensource however also makes it possible for others to find possible scenarios were damage can occure which then leads to implementations to prevent further damage. In a perfect world potential harmfull code provides safty messures at the prior to the new implementation...
So if we take the TV again, the manufacturer is not responsible if the TV gets stolen at the customers home. The manufacture is however responcible for creating a TV which is not a signal transmitter which affects the TV signal of the neighbours. The manufacture also cannot asume that a customer can build a faraday cage around their living room to prevent those signals from interfering the neighbours TV signal.
Shad MOrdre wrote:
Point 4 shows a weakness in using names to determine actions
Yes, uuids are what most script functions use. But dont underestimate the power of the names. In our daily lifes, eg chat, we use names, and not uuids. Not everyone has a viewer which gives the uuid of an agent, not everyone has a script to extract the uuid. But using names in eg. access lists is mainly a user friendly method which makes life easy for customers. Product designers will also be looking at what the competetors are doing and what the customers prefer/wishes. Were possible and were it makes sence, a user friendly aplication will manage to cope with the name only and do some backend work to get the uuid.
Now lets take it a step further... linked aplications in multiple grids with hypergrid enabled. We now have relationship uuid + name + grid. A hypergrid visitor will give us the required grid data via the name. The name is also the only possible method to detect the grid origin of a agent for the 3rd party aplication. uuids are not reliable, as anyone can create a agent with identical uuid + name in another grid/standalone. At the same time we have NPCs were the name is not reliable...so we atleast need to be able to filter agents from NPCs
Shad MOrdre wrote:
I do appreciate the healthy dialog Michelle. Please do not be offended by my willingness to argue points.
Np, there are many diffrent approaches and noone can think of every possible scenarios. I myself have scripts were I can use osNPCTouch and at the same time I have projects were it can become a huge issue unless additional methods for filtering are implemented aswell.