Shad, i could give you many examples were osNPCTouch could be harmfull.

Lets asume someone has a shopping region were parcels can be purchased. Many shopowners offer Clothing and want to use NPCs to show their productsin their shoppingwindows. In this very simple case the region owner will allow NPCs for the parcel owners.

You now have the situation were anyone could purchase land and rezz his npc...

Griefing Example 1: With osNPCTouch you can now block all object in the entire region with a simple while loop

Griefing Example 2: A Landowner can use NPCs to fake votes to boost his ranking, eg. the well known Votestation from Oliveira

Griefing Example 3: Your neighbour doesnt like you anymore and fakes votes, and you get banned from the votesystem

Griefing Example 4: A Vendor can send objects to an Avatar were you give the recievers Name in the chat. To give items, you need the uuid of the Avatar. The vendor system will retrieve the uuid of the avatar using one of many methods available and for future use save the name+ uuid. A NPC can have any name, even if there is a real avatar. So now you have the situation were you have many equal names, but diffrent uuids. Which one is the avatar?

Griefing Example 5: You have a script which only allows access to avas in a name list. With NPC you can gain access.

....

I did add a patch on mantis which adds NPC to llDetectedType. This also enables scripters to work with sensor, collision and touch events and does not rely on any ini settings. One could create walls were NPCs can walk through, but avatars not. The possebilities are there and also can be used to keep spammers away which might even break entire systems.

This change is even very necessary. In my case 4 years of lsl and php development would go down the drain or optionaly my system would become totaly non user fiendly...

[edit] Btw: No region owner or object owner knows how the script system is build up, especialy when they are linked to webfunction. In these cases the 3rd party developers have to make sure that their systems are foolproove and cannot rely on anyone that uses their scripts.

Michelle,

You raise some valid points about llDetectedType, and the Mantis is a great start. Sensors already detect NPCs as an AGENT type, and so this should be a quick fix to add for llDetectedTouch.

I'm not sure what you meant in point 1.

Points 2 and 3 are griefing issues that should be handled via established methods. The voting booth only shows the weakness of a voting or traffic monitor system to determine popularity. Popularity ratings are easily manipulated by the controller of the database. Additionally, what's to stop a user from creating multiple logins and performing the same actions as you describe? Scripts will still need to be modified to include either osIsNpc or further tests against the detected type anyway. More importantly, region and parcel owners have the ability and responsibility to restrict scripts. To blindly allow anyone to run scripts is a security issue that is the responsibility of the region and parcel owners. This can easily be remedied by restricting scripts on a parcel to a group or to the parcel owner. Is it the responsibility of the manufacturer of your TV to ensure that thieves cannot break into your home and steal the TV?

Point 4 shows a weakness in using names to determine actions. Permissions are key based, not name based, thus keys should be in use and this is thoroughly recommended throughout the script forums and wikis. Having also coded for years, I certainly understand investment, both in time spent and products generated. There is no excuse for badly written code, but unfortunately, there are many badly coded scripts in use. This responsibility rests solely with the user of said script, as they should be aware what the script does. After all, how many ppl download random things from the internet with all the danger this activity implies? The blame lies with themselves.

Point 5 assumes that you know the names that have access. While that can easily be figured out, the previous point about using names versus keys should address that point. A users avie key does not change. An NPCs key changes each time it is created.

As far as your last point, region and parcel owners SHOULD know what a script does. Users who enter a region with active scripts pose a risk on a number of levels, and many regions/parcels do not allow scripts, even in attachments, for that reason. This is good security practice, and should be encouraged. Sometimes, it takes a bad experience in order to learn a valuable lesson. That is how the internet operates. When someone does something they shouldn't, the web community usually responds, and not in a nice way. Why should scripters try to accommodate differently, especially considering that as tech evolves, these issues will continue to arise, and coders will never be able to stay ahead?

I do appreciate the healthy dialog Michelle. Please do not be offended by my willingness to argue points.

Shad MOrdre

Hi

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.


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.


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.



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



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.

Michelle