*serious* banning tools for all group/estate/parcel admins to fight griefing/spam

I'm not trying to ban "someone" from *crossing* my land.
I'm trying to stop particular people and groups of people who come to my land ONLY to :
1) attack other people with push weapons, from small arms to ICBMs and nukes.
2) harass, intimidate, stalk and generally aggrivate the hell out of my paying residents.
3) impersonate other people (favourite targets so far for impersonation include babyfurs, vores and a few others) - so that when they are banned, the groups they were a part of get bad reputation.


I have nothing against fliers at all. I would like fliers to be able to fly through parcels they have no access to - just not allowed to interact with content in that parcel.
I am not trying to stop flying - I am only trying to protect the people that live on my sim from those who, repeatedly, deliberately and persistently come to their homes and try to ruin their day.

If you really wanted the freedom to fly you'd vote *for* my proposal, because right now fliers are stopped by ban lines, whereas under my proposal they'd still be able to fly they just would not be able to do things in the parcel that would cause inconvenience to the people there.
I've tried to design my proposal so that fliers, too, can get something out of it - they can fly around and the worst they have to deal with is seeing only blank land. That's far less inconvenient than bouncing off ban lines, and it's more secure for the land owners too if those with no access can ghost through the parcel but they and the contents of the parcel cannot interact.

ok.. yes griefing is bad.. but LMAO.. at least they are being creative. The reason you are getting griefers now are cause you are so adamently against them here on the forum. They are probably forum trolls who are bored and thought it would be funny. Just ignore it.

And that just goes to show ya.. no matter what you do.. if someone wants to grief they will. No matter if it's on an alt or if they have to jump out of a group that's banned.

I'm curious as to why LL doesn't do searches looking for the groups of people who cause trouble like this and ban the members of the group--or at least keep an eye on them.
"Hello I am griefing" got a laugh out of me though. Almost as funny as Ted Stevens on the topic of Net Neutrality.

I personally think making groups to grief with is the stupidest idea they can come up with. all we have to do is ban everyone in that group and theyfail right there. And hiding the group info from public doesnt help them anyway. Some people can still see the group, expecially lindens.

Anyway i agree 100% with angel we need these tools or atleast some of them. The odds are it won't happen though. As i have noticed in the last year and a half i been here LL doesn't really care what WE wan't or we would have a instant messenger, better privacy tools, protection against griefing, better land tools, havok 3, ability to mute group sessions, account registration would back how they used to be when i joined, and that free pony would still be there. o.o

Yes, it is stupid to do this. Griefers still do it quite a lot, it seems.


I think that LL does make a genuine good effort to get the stuff done that we need - they're just short in terms of manpower (how many Lindens are on at once.... versus how many Residents?).

I think they *do* care what we want, they just don't have the development time to make all of it happen so they focus on the most important/urgent stuff.

Angel had a chance to re-read through some of the discussion here and so far im still REALLY in favor of your ideas. here are a few specifics for how i've wanted banning to be handled (its roughly the same i coded on a MUD years ago).

Each parcel needs to have both an allow list and a ban list. The banlist needs to have a checkbox that can be (de)selected to prevent the people in this black list from entering. The banlist needs to be able to accept a group name in addition to avatar names. When the blacklist is active (deselecting can temporarily disable it without needing to delete all entries) any avatar belonging to a blacklisted group, or explicitely on the banlist will not be able to enter the parcel. Any object they own (no matter what group its assigned to) will instantly be returned to inventory if it enter the parcel. Anything they type in chat will not enter the parcel NO MATTER WHAT CHANNEL IT IS ON. This implies that scripted objects of theirs using chat will not trigger scripts in the area they are banned from. This portion would need to handled server side. Any gestures or sounds they play directly or via script will not be audible to anyone within the area. This portion can be handled client side. The banned individual should appear 'unrezzed texture' in appearance and not have any attachments display to anyone within the area. This can also be handled client side. The banned individual should be prevented from entering the parcel at ANY height. Not even at 40,000,000 meters. The banned individual should not be able to get 'click focus' on anything or anyone within the parcel. This means they cant easily mouse zoom onto an object (there are other ways to zoom in but im not worrying about those). This means they cant right click on any object or player to get access to any of the pie menu features. And their camera's pos should not be able to enter the parcel. These limitations would all need to be client side, subject to hacking attempts, but detection of any such hacking attempt could have system enforced methods of flagging that account for tampering and ban them COMPLETELY from SL. Any time an avatar is prevented from entering a parcel or have objects returned to them they will be given a dialog of

"You are banned from entering this parcel."
"Your group is banned from entering this parcel."
"Your objects are banned from entering this parcel."
"Your groups objects are banned from entering this parcel."

depending on which is appropriate. Except for the timestamp being updated the land owner should have NO AUTOMATIC RESPONSE that the ban was enforced. It should happen silently wtihout distraction to people in the protected parcel.

SPECIAL NOTE: if anyone is specifically banned by name it should effect all their alts automatically based on the new hardware ID. Again to preserve privacy this should not be disclosed to the landowner or any people within the sim. The message given to the alt should read the same as it would for the explicitely named individual meaning it would be one of:

"You are banned from entering this parcel."
"Your objects are banned from entering this parcel."

with no indication that its because of their alt. The timestamp for the explicite ban should update as normal silently without directly giving away the identity of the individual. For extra privacy these 'timestamp updates' could ALL (both alt and direct) be queued and all applied at a certain time of day on a schedule so that all such cases are ambiguous and to prevent scripts from using other methods to discover the identity of someone.

Now whitelists:

Each parcel needs to have an allow list that accepts both individuals and groups. The allow list would have a checkbox to "Restrict parcel entry to those listed". This would be DESELECTED by default.

When deselected all groups in the allow list are completely ignored. But anyone EXPLICITELY listed in the allow list (even when parcel is not group limited) will still be allowed to enter even if their GROUP is banned. This means if in general the "Greifers Anonymous" group is banned, but you know for a fact that "Joe Avatar" in that group is a nice person you can ban the group, put Joe on the allow list and Joe will not be effected by the ban. So explicite allow trumps group ban.

As a safety precaution you can NOT have someone on both the banlist and allow list at same time. The system should just give an error "That person/group is already banned/allowed. Please remove them from the other list before adding to this list.".

So when land is generally open to the public the 'allow list' is merely used as an exception to the banlist. But when a landowner selects 'Restricted Access' the parcel will now restrict entry to people who belong in the whitelist. This granted access will obey the current limit of 50m (id prefer 64meters though). The blacklist at this point though will still be in effect. So you still wont be able to enter the entire sim at any height if you are blacklisted by group or name. Of course being specifically NAMED in the allow list still trumps being merely banned by group. Being banned by group OR name trumps being allowed by group.

Final clause:

If the allow list is selected so the land is fully limited by it, and the black list is DESELECTED, the blacklist is still used to keep people out of the group area but are NOT restricted from heights above the 50m (64m) group limit.

-----------------------------------------------------------------------------------------------------

Thats the basics of how i want things. With the white/black lists set up in this manner there would not need to be a seperate "group access" option. Its just 'restricted access' to all the groups/people listed or not. No need to have a seperate option for only allowing people with the lands assigned group.

Some extra features for each list:

In the blacklist id set a limit of allowing up to 300 entries. A max of 25 or 50 of these can be groups with all remaining entries being specific names. Along with each entry will be a 'last accessed' timestamp. Initially this value will be equal to the time the ban was added. At any point that a given ban is USED by actively preventing someone from entering or returning their objects the timestamp will be updated to that moment. This applies to both group and specificly named entries. Any entry with a timestamp older than a month will turn yellow. Any entry with a timestamp older than 3 months will turn red. If a script is used to autoban someone it will remove the oldest specifically named individual from the list to automatically act as a FIFO type feature. FIFO functionality will ONLY work on names that are Red or Yellow listed. This measure is to keep people from wasting sim resources by using a script to explicitely ban EVERYONE entering that isnt in a script enabled whitelist. This would only prevent people from having unlimited height bans on EVERYONE since 'whitelist' style bans are supposed to be limited to 50m. Scripts should NOT be able to add groups to the banlist. Scripts should not be able to remove anyone at all from a banlist (yet again to prevent someone from writing their OWN fifo security ban-all system). Scripts should not be able to retrieve the timestamps of entries in the banlist to prevent any means of script assisted Alt detection based on such timestamps when referenced against visitor history.

In the whitelists I see no benifit to keeping timestamps. There should also be a 'everyone' group. Reasoning, is that eacn entry in the whitelist will have checkboxes to enable certain rights. By default ALL checkboxes will be filled in when a group/individual is added to the whitelist.

[ ] Can Rez
This allows someone the basic ability to use 'create' or to drop something from inventory

[ ] Wont Autoreturn
Disabled if CanRez deselected. When selected objects owned/assigned to this entry will not be subject to autoreturn policy.

[ ] Allow Transactions
If deselected restricts a person from paying or recieving money via Pay or llGiveMoney. Can be useful in the 'everyone' group in order to have scammers hindered. Someone owning a mall could have 'everyone' with no transactions and specifically add an entry for each storeowner (renter) on the land.

[ ] Can Push
[ ] Give Inventory
[ ] Use Listeners
[ ] Use Sensors
[ ] Basic Scripts
Now these ones are mostly limits on scripted use (except inventory transfers which could apply to players too) but would allow for control over most features that effect greif and lag.

[ ] Can Damage
This one would effect BOTH give and take. In otherwords both parties have to have this permission in order to participate in damage based effects. So the Federation areas could have 'everyone' as damage deselected and the general public would be safe to 'visit' there. But any individual/group with damage can play consentually with anyone else who is ALSO damage enabled. Another method of preventing greif from both points of view (prevent outsiders causing greif, and preventing innocent bystanders from experiencing greif).

OK i could think of a dozen other things to add as checkboxes. Honestly with the options i have listed "Allow List" and "Ban List" would each already need to be seperate tabs. In the allow list I would envision it implimented as a table with each name being one row. Name on left. On right side above the table would be icons representing each feature with only the checkboxes in the table. An icon key could be immediately above/below the table of entries.

In the whitelist all entries could be sorted by name, with group entries listed above all individual entries. In the blacklist there would be need to sort either by name, or by timestamp, so that land admins could more readily look for outdated entries (for cleaning) without having to scan the entire list.

Well im sorry for writing so much in your thread Angel. Hopefully you think this post fits in comfortably with your suggestions. If you dont think so let me know and I'll edit it all out and post my own thread. Its something i've thought of doing for a few weeks anyways.

I'll break Seronis' ideas down and reply to each individually, but basically I think that :
* there are a lot of good ideas here.
* I appreciate the feedback.
* some ideas violate the KISS principle so I won't include them, but the good ones I will include.

As to your points :
1) Banlist should have an active/inactive, or 'on'/'off' switch.
I agree, and it already does.

2) Objects being edited should be instantly returned if they move into an area their owner is banned in.
I disagree, because this would enable a new form of griefing (buy up all the land around someone, and watch as the objects they're trying to move get returned).
Just preventing them from moving into the land is enough.

3) Chat/sounds/etc from banned avatars and their objects should not pass into the parcels they are banned in, even if the chat is on a >0 channel.
I agree. Common sense really.

4) Banned people should not be able to get 'click focus' on anything inside parcels they are banned in. Meaning : no pie menu, no camera focus, etc.
I don't think this is needed. If we stop them even *seeing* objects inside parcels they are banned on, as I have proposed, we don't need to limit their ability to focus as there is nothing for them to see.

5) Cameras of banned avs should not be able to enter the parcel.
Same as #4, I think they should just not see any objects in the parcel no matter where their camera is. I think that is better then trying to restrict where their camera goes, as the essential function of a camera is to see, not to take a certain position physically. It's like the difference between stopping a car moving, and stopping it being in certain places. Stopping it moving defeats the point of it, wheras stopping it from being in certian places, doesn't do so a priori.

6) Banned avatars should not be able to enter the parcels at any height.
I'm fine with them entering the parcel so long as they can't see or interact with anything there.
If they were going to be able to see/interact with it, then I'd agree that the ban height should probably be infinite, though personally I don't see much mileage in changing this as the 768m it is currently reaching to is so high that really I can't see what further use would be gained from making it infinite.

7) Avatars should be told why they / their objects cannot enter a parcel. "You ___", "Your group ___"... etc
I strongly disagree with this as it will tell griefers EXACTLY what they need to know to get around the ban.
A far better solution would be to simply say "You and your objects may not use this parcel" for *all* those access related errors.
That way, if someone is banned, they have to contact the land owner about it.... the ban stays effective, and yet innocent people who find themselves banned can still get consideration for an unban.

Landowners should get no automatic notice that bans are enforced.
I agree, automatic notice on ban enforcement would pave the way for spamming land owners with ban enforcement notices.

9) Landowners should be able to see a timestamp on each ban that lists when it was last enforced. This would be useful for identfying old bans.
I agree as long as the 'last used time' is updated every time the banned avatar enters THE SIM, or any adjacent sim. I disagree if it is only updated when they try to enter the parcel. I think this is important as otherwise griefers will just avoid flying over the parcels they are banned from in order to make the landowner think that the ban is long obsolete when in reality the griefers are just waiting just out of range for it to expire.

10) Bans should affect alts via hardware ID, and the person banned should not know if they are banned themselves or due to an alt.
I completely agree.
The only potential problem with this that I see is that it would let residents ban themselves on each others' land, to be able to verify that LL does not consider them alts, before going on griefing sprees. Essentially, this would allow griefers to check that LL can't track them before they start griefing. Perhaps the solution is to make 'affect alts' include most but not all of LL's ways of identifying alts, so that in serious abuse cases, LL still have stuff to go on? They'd have to make most of their ways of identifying alts (IP, hardware hash, email, etc) availible to make the system useful, but still, not all.
I hope it doesn't lag the servers to go through all a person's alts and all the access checks for them and all their groups. I think this could be mitigated by checking the av first, then their groups, then their alts names, then their alts groups. Basically trying to reduce the number of total queries as much as possible.

I also think bans on groups should apply to alts of people in those groups. Lots of griefers have many, many disposable accounts. Those accounts can be a useful weapon against them - if one of their alts is in a griefing group, all their alts get banned. That is a VERY useful tool that further erodes the "I can do whatever I want on this throwaway alt and it won't effect my main account" principle, which is what we need to errode to deal with griefing.

11) Those in a banned group but with their av name on the allow list should be permitted.
I agree, and this is a great solution to the problem of "but isn't it unfair to ban a whole group based on the actions of a few members?" - the good people can get exemptions.
I have since made this explicit in my proposal.

12) Being banned by group or name trumps being allowed by group.
Agreed. I have since made this explicit in my proposal.

13) FIFO queuing should only work on bans unused for at least one month
I agree, the ban list should delete the least used entries first, so long as 'used' is sufficiently broad that coming within a sim or so of the banned parcel counts as 'use', to prevent people flying *around* the ban till it expires and the ban not being counted as used.
If someone really is running a script that wastes sim resources by adding anyone that comes near it to the ban list, then this won't stop them, as the ban list will still always be full if the area is low traffic, and if the area has over 500 visitors a month, then there might be no entries that can be pushed out, and thus we're back with the "script error" problem of adding lots of people to the ban list anyway. So your ideas would not prevent that. They would, however, be useful for identifying out of date bans.

14) It should be impossible to add someone to a ban/allow list by name if they are already listed on the opposite list by name.
Agreed.

15) There should be no 'last used' timestamp for the whitelist.
I think there should be, because it'd be useful to know how many of your 'trusted friends' ever bother to visit your place.

16) In the whitelist all entries could be sorted by name, with group entries listed above all individual entries. In the blacklist there would be need to sort either by name, or by timestamp, so that land admins could more readily look for outdated entries (for cleaning) without having to scan the entire list.
Agreed.

17) Checkboxes determining what people on the whitelist can do.
I agree that it would be nice to have a list of groups and a list of permissions for people in those groups.
However... I think this would, to a large extent, duplicate what we already have in the group roles system. In the group roles system, we have a lot of different roles that can be allowed the privilige to do various things, such as build on no-build flagged land, script on no-script flagged land, etc.
I think that we should not re-invent the wheel - we should have group-owned land with members assigned to roles in that group to give them permissions.
I think this would work better than a per-group whitelist system, simply because I'd think it is easier to have one group for your land with permissions based on roles in it, then it is to have lots of groups for your land with all members in the same group having the same permissions.
Plus, we already have a complex group role system - do we need to duplicate that in land allow lists? I don't think we do.

1 Timestamps of 'bans used' should update in some way that doesn't tell the landowner who someone's alts are.
I suppose so, yes. I can think of ways of dodgey land owners using a single ban, combined with a teleport offer to a known av and some misleading information about what they get if they take the TP, that would lead to landowners being able to test if an av they know is an alt of someone else they know, using this system - if person tells the landowner they're banned on the parcel, the landowner knows they're an alt of the one named person on the ban list.
Delayed updates will stop some cases of landowners using alt-banning to find out who someone's alts are, but not all cases, and I suppose this is a good thing.


19) There should be an 'everyone' group assigned permissions in the 'allow' list.
I disagree - we already have this as the parcel flags system - a default that's easily accessible and can be relaxed by group role permissions.
Lets not reinvent the wheel

20) Related idea : in the group roles system, there should be an actions:
"objects (including those set to group) owned by this player on group owned land can be paid money or bought",
"objects (including those set to group) owned by this player on group owned land can give inventory",
"objects (including those set to group) owned by this player on group owned land can push",
"objects (including those set to group) owned by this player on group owned land can use channel 0 listeners",
"objects (including those set to group) owned by this player on group owned land can use listeners",
"objects (including those set to group) owned by this player on group owned land are never subject to autoreturn",
"objects (including those set to group) owned by this player on group owned land can use sensors".
- I definately agree one should be able to limit the use of push, give inventory, accept money, autoreturn, and channel 0 listening scripts on group owned land via "actions" in the group roles system.
It could stop people putting invisiprims over vendors to steal money from the vendor owner, it could stop people using text spying scripts and reduce lag, it could stop people setting up spammer scripts, and it could stop people using scripts that abuse push functions on group land. It could also enable you to use groups to let people access your land without being immune to the autoreturn there.
These changes are definate good ideas and should be suggested to the people working on the group roles system! - I think I might go and do that within the next hour.

21) Related idea : have a system where only people in an opt-in group can damage each other.
It depends. Do you want damage enabled land to ALWAYS make everyone on it vulnurable? Or do you want it to more consensual then that?
Personally I think each avatar should have a "damage enabled" setting. For person A to damage person B:
* A must be damage enabled, B must be damage enabled, and both must be on land that permits damage (permit-damage land)
* OR : both A and B must be on land that forces all to be vulnurable to damage (force-damage land)

Personally I think that is a much better option... You can have some areas set force-damage - e.g. combat sims, but leave most land as permit-damage so if people want to fight they can, but aren't forced to. Safe areas should be 'no-damage', and, though it would be a seperate option 'no-push' (as opposed to 'consensual push' and 'full/forced push'), I'm sure you're the expert on those

22) "Allow" and "ban" would need to be seperate tabs.
They already are.

23) Allow/Ban lists should have a table format, where each name starts a row, which then has cells to the right of it.
Agreed, but I'd like to try to keep the number of cells to a minimum if possible, for the sake of not confusing the Residents too much.
I think : name, time added to list, time list entry was last used (coloured by how long ago it was), who added it, 'affect alts' checkbox, and possibly an 'active' checkbox would be enough, as that is already 6 different fields per allowed/banned name/group, making a total of 6 bits of information already. The 'active' option I'd add so we can track who we've given warnings to by adding them to the ban list and then unchecking the 'active' box. Active should be the default for bans, because most people use them simply to get a bad person off their land, and they don't want to mess around with the advanced options.

Well i said it was my ideal system. (mostly because its one i designed in another game). And i realize some of the suggestions match current options, and others would replace current options and the rest would just increase options available. So counter rebuttals:

2. See your point there. But in all honestly the only way for something of yours to enter a banned parcel is to drive it into the parcel, shoot it into the parcel, toss it into the parcel, or drag it into the parcel while editing. To me every one of those situations is a legitimate reason to return the object. Just a preference thing.

4/5. I dont like restricting view nearly as much as restricting ability. Again just a preference. The focus and camera position would have a lot lower chance of breaking the renderer is my main reason though. I see a lot of opportunity for rendering bugs to arise by doing your idea.

7. Well as a means to help the innocent who happen to be in a group thats banned is where I mostly thought detailed messages were useful. IMPOV any greifer that really wants to be a PITA will just leave their group to test, then rejoin. Or possibly have a buddy show up and start testing the 'fense' for holes. Then again your idea is simpler, no details needing to be parsed for correct response and anyone who feels innocently effected will contact no matter what so i'll conceed.

9. Id strictly do parcel only to reduce the number of checks needed as random avatars pass through the area (example, flying around and barely crossing the tip of a sim corner before hitting the next diagonal sim). Also for the same reason is why i strictly mentioned alt accounts of explicitely named avatars, and NOT any alts of anyone in any group you've banned. Its a lot less resources to grab the list of groups on an avatar actually THERE as compared to grabbing (remotely) all the groups of all the potential alts. And the reason i think that explicite alts would be a simple lookup is that for any given avatar, every "unique id" that has accessed that avatar should be loaded into its memory space at all times for easy use in manners like this. Then when comparing for alts you could check the current avatars list of Alt id's against the explicite entries cheaply without any remote (off sim) asset server checks. Lastly I didnt mention any auto-expire on ban entries. No matter how long they 'fly around' their name wont auto delete for quite some time. Not many greifers have patience levels that are in the magnitude of months.

17. I mostly just feel like its 'wasting' a group slot to have a group solely for access permissions when it could be something done on a per-parcel basis. Most of the ideasin this part would displace the group limitations. Mostly how do you intend on allowing 2 totally seperate groups to have different access rights on your land, that is seperate from the 'everybody' level rights? You cant right now. You would have to create mutliple roles and invite everyone into that group.

23. Honestly your adding more cells than I intended. For blacklist i only wanted two entries, name + last access date. I was flatly dismissing the need to see 'originally added on' date or any reason. They would be useful. Just not in mygoals. For whitelist all i wanted was the name followed by some colum aligned checkboxes with no other text inside the table. Just non moving icons at the column header

Though in general i still think your chosen issues are a great proposal. Hope this gets some more publicity.

A friend and i got into a discussion thismorning about Push scripts and how to control them. Even if we could remove push from our land, theres still the CAGE problem. a Cage uses llApplyImpulse to move its self into orbit, taking you with it if your inside it. Perhaps we need some way to bring back avatar phantoming? WHY OH WHY DID LL REMOVE THAT IN 1.7?!! XD

I'm adamantly against any more restrictions on camera positioning than the ones we already have, and I don't even like those. If I move so my camera's underground, say because I'm on a steep hill or in a hole, my viepoint is thrown completely off and it's not that hard to lose track of your camera completely. It my camera couldn't go into a parcel I didn't have access to, then this would happen just by turning around several places on my own land... because there's idiots all around my place who've apparently bought land, access controlled it to their friends group, then never returned to the land or logged in since.

I have since realised what great things become possible with this proposal, such as automatic enforcement of sim rules such as no weapons via automatic estate banning of anyone who fires guns via scripts that detect fast moving bullet-like physics enabled objects, and ban the person who owns them from the sim. Other uses are even better - such as being able to give lots of people permissions to edit the sim ban list *via a scripted security orb* so you could afford to give security orb access to more people becuase they worst they could do is mess up your ban/allow list, and even then you can always script the orb to restrict what they can do (e.g. not banning other sim admins, limiting the bans they can set to 6 hours long, etc, so there is a list of people who can easily sim ban any griefer alts).

I've also added llReturnObject to these proposals, on the grounds that it's related, many people want it, and it's just such a damn good idea that it's hard not to.

The camera restriction would ONLY apply to people explicitely banned sorry. Would not be in effect for land that is whitelist restricted. Was thinking of that exemption. Forgot to state it (it was 6am when i wrote that post)

Well the new group limitations would apply to group OWNED land. But not group 'set' land. You might want the owners to have more access than the common groups, but in the end with all the group consolidation that will be capable of happening, and the increase to 25, it might be enough.

Let everyone know when you have a voting proposal set up and what it will include.

Our voting proposal is now finalised at : proposal 1632.
The definitative list of everything included in it is contained in the first post of this thread.
I've also finalised it, so I won't be editing the proposal after I have made *this* post. Personally I'd have liked to have kept it open to minor changes, but I think it has most of the major stuff in it. I like ideas such as Seronis Zagato's proposal (to give people permissions on land based on having their name/group on the whitelist and checking boxes next to their name, instead of giving them permissions by requiring them all to join a group and be in a certain role)... I even think that technically, they're a better solution than what I have proposed. The reasons I did not include those in the final proposal are :
1) they're a substantial departure from what people have already voted for.
2) we haven't had enough time to discuss them and for people to pick holes in them.
3) given that LL have spent so much work coding the group roles system already, it makes sense to at least try using that for awhile and see if it's adequate before we start generating more work for LL by proposing an overhaul of allow lists to include the ability to grant specific permissions.

I have included several other points that were not in the original proposal, however, such as :
1) changing the FIFO system for parcel bans into one that removes the least-used ban first. (I forget who suggested this)
2) adding the proposal to enable scripting of ban functions at all levels (LSL functions to add/remove/list estate, parcel and group bans). (credit for this great idea goes to Argent Stonecutter, IIRC)
3) adding llReturnObject and family to the list of LSL functions asked for. (This was suggested somewhere else, by grumble Loudon and co)
4) minor rewrites of various things for clarity and brevity.

I'm going to avoid changing the original proposal any more though, to make sure people are comfortable voting for it and don't have to worry that the proposal will change to something they don't like after voting for it.
So, the proposal won't be changed by me anymore You can vote for it safe in the knowledge that what you see now is how it will stay.

If people want to continue discussing its features on this topic, go right ahead, and while I may back changes from future discussions here, I won't be ammending the proposal itself any more

Crosslink : Yiffy Yaffle's idea : let LSL scripts detect and react to being pushed. - I like this idea because when combined with ban list manipulation, you can do things like rez 'anti-gun' scripts in popular places that detect when people fire push guns and issue parcel or sim bans against them automatically. Check it out

Unfortunatly that isnt a good option yet.. :/

Wow your proposal got lots of votes lol. If i didnt use all 10 of mine in 10 different proposals i would add a point. :/

I'l probably have to use a alt

Certainly gets several votes from me. I'd like to see similar protections for individuals, however, so we are not at the mercy of whatever the land ownr does or does not bother to set up. Your proposal makes it possible for property owners to make their places safe. But there is no way to tell if you will still be safe once you step over the property line into the next parcel...

There's no way of telling when you'll step onto damage-enabled land, unless you use "show property lines" and use about land on every parcel before you enter it. Few people, however, are scared of accidentally ending up on damage-enabled land.

Personally, I agee that it would be nice to be able to see which parcels were push-enabled and which were not without having to step on them. Having said that, I don't think it's a truly major issue because you can always turn on property lines and watch the status bar at the top of your screen for the (hopefully useful) "no push" or "push enabled" icon.

Griefing can be one of the many ways an SL experience can be ruined. Crashing a sim, causing people to be pushed miles into the air, and general stupid activity can force people out of areas that are fun. To me, any action required to stop this should be taken. There is no reason any person who spends any time in SL should cause problems for other members. Irregardless of the fact tha we can be children in here, doesn't mean that you should act like on.

Un homme sage pense deux fois avant qu'il agisse une fois.

Neliss Eldrich

Surprise. Angel Fluffy wants an easier way to ban people.

The problem with this proposal is that it's too much of an omnibus. LL almost certainly won't implement all of it as listed, and if they pick and choose from it you're just as likely to end up with a mishmosh like the new snapshot system as something that's actually an improvement.

The most important part of it as far as I'm concerned is the change in definition of "access". Instead of "no access" meaning "you get bounced off this parcel", it should mean "you never gets any information from this parcel" and "this parcel never gets any information from you". The contents of the parcel vanish from the world, leaving nothing but the default ground texture... you can walk or fly through it but you're in a "phantom zone" as far as the people in the parcel are concerned... and vice versa.

Give us that and nothing else, and I'll be happy.

Yes. This proposal is very much an omnibus. I think this is a good thing because it means it gets more attention than the ideas would if they were strung out amongst lots of different proposals. I also think it is good because we can get all of the best ideas for improving ban-related security in one room, together, get Linden attention on them, and hopefully hash out which are the best.

If I had to rate the ideas in this proposal in order of importance, I'd go :

1) Crucial
* Scripted access (add/del/list) for estate bans, and a getbanlist function for parcel bans. This would enable us to do things like estate and parcel ban sharing in a way that shifts the bulk of the scripting work onto SL Residents instead of LL coders, thus speeding up development time.


2) Very important
* Bans affect a person's known alts. Banning a person should ban their alts. When you ban someone from your land, you generally do not intend to ban just their account, you want to ban that *person* from your land, no matter what account they use. Bans should reflect this.
* Bans by groups. Seriously. There are a few well known groups out there from which the majority of griefers I see hail. Banning them on an estate-level would make a huge difference.
* People with no access to a parcel should not be sent any details of objects or avatars on that parcel. They should not be able to interact with anything on that parcel, see anything on that parcel, or be seen by anything on that parcel. They should float through everything like a phantom object. This is the only way I can think of to both give people privacy and stop people scanning through walls to see them, and also to remove ugly ban and access lines whist increasing security.

3) Important
* Bigger estate ban list (500 or so). We need this because estate ban list lengths are just not long enough right now to handle endless tides of alts.
* Bans should indicate who set them and how old they are. Those who run popular clubs/etc need to know which person set a land ban, and, preferably, why, without having to ask each individual person with security access if they did it.
* Ejecting someone from a group should close IM sessions they started FOR EVERYONE IN THE SESSION and stop them IMing the group again.
* We should be able to stop people joining our groups without making the groups invite only.
* llReturnObject, GetPrimCountForObject, and family

4) Everything else.

Fair enough. The thing is, I'm not sure I like all of the proposals. Which is why I'm not voting on it. Couple comments:
Yeh, like I said before, getting enough scripting ability and WE could implement the rest.
Nod. Everyone sharing the same payment info, anyway. That's an essential part of my sponsorship proposal too.
I think this is a good idea, but LL has previously said that this would be prohibitively expensive to implement.
I'd put this as #1, maybe even before scripting. Really, this should go in as a separate proposal, it's that important.
Yeh, there's a bunch of related problems with bans and ejects not happening imediately.

I'm bringing this back up since there is push for votes.

1. The ban groups would be tricky and could be abused.

2. llReturnObject would be bad during a grey goo attack unless the script could also uncheck "Run scripts" and "Create object" to stop the attack. Without this the asset server could be overloaded with all the returning objects.

Right now with the "Return bug" the attackers can do more than just annoy you, they can delete your entire place. Unfortantly no one has figured out how to replicate the bug and this LL can't find it. Having a script watch the "prims remaining" could be usefull as it could be set to trigger when the land gets close to the prim count and then disable all scripts.

I'd also have it set so that you can't pay an object when the object contains a money() event and that script is disabled due to land settings. This would prevent the problem we saw last week. People did not get there items when they payed vendors since the scripts were disabled.