Security Console

What’s Different To Other Security Orbs?

The console is intended for security on public parcels, and doesn’t do simple allowed-listing. Its main purpose is to maintain a good experience for visitors to your place, keeping away non-targeted audiences or agents with disruptive or just inadequate attachments. 

The Security Console is NOT intended to be used for private (home) security.

I’m using this product on my own sims and it’s continuously developing. All further updates are free of charge.

Latest Features

• Configurable message upon avatar height screening non-pass.

• Revision and modularisation of code to avoid memory issues in LSL.

• Added avatar age verification.

• Removed RLV-based features force_group and auto_detach because some new relays send instant messages to the owner of an attempting device, hence sending an RLV message could result in annoying IM spam from these relays.

• Forbidden attachments can now be defined for a specific gender (see Attachment Screening section below for details).

Technical Terms

• Agent - Technical term for a Second Life avatar.

• Attachment  - Object that is attached to your avatar or your HUD.

• Boot - Removing an agent from your parcel, no matter the method.

• Eject - Teleporting an agent from your parcel, often to a neighbouring parcel.

• Home - The place where an agent has set its base location.

• Group - A Second Life collection of agents.

• Orb - A scripted sphere object.

Screening Levels

The Security Console screens on various optional granularity levels:

• Ban list: Any agent on this list will be ejected immediately. The ban list is a notecard in the Security Console contents.

• Minimum Age: An avatar must have a minimum age to be allowed. It reduces newbie traffic, but it's also to avoid that banned residents just create a new avatar and return to your place.

• Group membership: Agents who are not member of the same group as the Security Console are ejected.

• Gender requirement: Agents who don’t match the required gender are ejected.

• Avatar height: Agents who exceed minimum or maximum height specified in the configuration notecard are ejected.

• Prohibited attachments: Wearing an attachment matching one of the names in the forbidden-attachments notecard.

• Access pass: Agents must wear a badge that responds to the Security Console with a valid access code. 

Since version 2, there's also a way to create an unconditional allowed-list using SL groups (see below).

Administration

The Security Console can have multiple admins besides the owner. Only admins have permission to touch its buttons. However, only the owner is allowed to turn the Security Console on and off.

Power on/off

The console does not auto-start to avoid a lot of action while being placed.

The owner has to touch the power button to launch it. Any change to the notecard-based configurations inside the console causes a shutdown. Changes will take effect after the owner turns the board on again.

Quickstart Guide

The Security Console system consists of 2 parts: The so-called bouncer and the console itself.

1. Console and the bouncer should be rezzed on the same parcel, or, more precisely, must be in the same region on parcels that belong to the same entity.

2. It’s crucial that you first rez the bouncer, change its password in the config notecard and make sure it has the same owner as the land it’s on. If the land is group owned, the bouncer must be deeded to this group. It's not sufficient to just set the group, it must be deeded! If you don’t have the permissions to deed an object to the group, give it to someone who has.

3. Rez the console at an accessible place and edit its config notecard to your needs. Do not deed the console to the group, only the bouncer!

4. Edit the config notecard inside the console. Esp. the bouncer_password must be set to the same value as used in step 2.

5. See if the prohibited-attachments notecard contains the correct keywords, one line each. Remove the items you don’t want to be banned.

6. Touch the power button on the console - the security console is now starting up.

Ban list

Add an agent's SL name (not the display name!) to the banned-agents notecard inside the Security Console contents. Banned agents will not go through the vetting process and are immediately booted.

Bouncer Configuration

The bouncer is a copy/transfer object that does the actual boot. It must be owned by the same entity that owns the parcel. If the parcel is group-owned, the bouncer must be deeded to the group after it has been configured properly.

The bouncer contains a notecard called config. This notecard contains only 3 items (max):

bouncer_channel=<a high negative number>

bouncer_password=<a password>

method=<eject|home>

Configure channel and password to as you please. However, the password should not be easy to guess, and the channel should have at least 6 digits.

Make sure the channel and password lines are also part of the console configuration.

The method specifies what happens to a disproved agent: eject means the agent will be ejected (most likely to an adjacent parcel), home means the agent will be sent home. Sending agents home is highly recommended and also the default setting.

Console Configuration

The console contains a notecard called config. The notecard is well documented. Make sure that if you want to use a setting to remove the '#' character in front of the line. '#' indicates the line to be a comment (and hence ignored).

In general, for configuration items that turn functions on and off, 0 means off and 1 means on.

All configuration items look like

<item>=<value>

Scope

Defines the area of the security console screens, either parcel or region. In addition, you can specify an altitude range. Agents within that scope are screened, all others are ignored.

Examples:

scope=parcel

scope=parcel,500-600

scope=region

You should use the region setting only if it you own the entire region (sim) and want the security to apply to all parcels in the region.

General

Configure your place's name and greeting settings:

location_name=<a name>

welcome_message=<a message>

welcome_sound=<name of a sound file in the console contents>

If you want to turn off the greeter, simply delete the welcome_message.

To define the repeat interval of the scanning process, configure the scan rate. Don't configure less than 15 seconds to avoid lag and latency issues.

scan_rate=<seconds>

You may not want agents to know why they were booted (so they can't "fix" it). To configure non-specific messages, use the following option:

specific_messages=0

Finally, if everything works fine and you want the console to reduce its verbosity to a minimum, you may set

silent=1

Admin configuration

To add an admin, use the following line:

admin=<agent uuid>

Note that the value must be an agent's UUID, not their name. To exclude admins from being booted when not passing the screening process, you may use this configuration option:

exclude_admin=1

If you want admins to receive alerts, configure:

send_admin_messages=1

Group Restriction

If you want the console to check for a specific group, enabled the following configuration:

group_verification=1

You have to set the group on the console object, and the console will check whether an agent is in that group too. The agent has to activate the group tag to be recognised.

Avatar Age Restriction

You may want to limit the minimum SL age of avatars showing up at your place, for example to avoid your place being swamped with noobs, or maybe to avoid stalkers who create new avatars to circumvent around a ban.

To do so, add the following line to your config:

minimum_age=<days>

<days> specifies the the minimum number of days an avatar must be old. Any agent younger than this will be booted.

Avatar Gender Restriction

You can limit the avatar gender that is allowed to enter. Gender is determined by the avatar shape.

Example (only women allowed):

gender_screening=1

gender_allowed=female

Example (only men allowed):

gender_screening=1

gender_allowed=male

To turn gender screen off:

gender_screening=0

Gender screening is off by default. 

If auto_ban is set, non-matching avatars will be automatically added to a ban list, so the delinquent won't just change its avatar shape and return.

Example:

auto_ban=1

Avatar Height restriction

You can limit the height of avatars that are allowed at your place.

Examples:

minimum_height=1.5

maximum_height=2.1

Note that there's an inaccuracy due to mesh bodies. The script can only determine the avatar height given by SL, not the height of an attached mesh body.

You can also configure messages with variables/macros to rejected avatars:

minimum_height_message=This is an adult place. Avatars must have a minimum height of $minimum_height meters, your current height is $avatar_height meters.

maximum_height_message=This place is not a giant convention. Please reduce the height of your avatar to less than $maximum_height meters.

Avatar Attachment Screening

There are many reasons why you’d want to screen for undesired attachments, for example:

• High resource usage or other disruptive behaviour of item

• Face lights and body light may negatively impact the overall appearance of your place 

• Specific gender attachments may not be appreciated at your place

• Specific role play attachments (weapons, fangs) are not to be worn at your place

To turn on attachment screening, uncomment or add the following line:

attachment_screening=1

Add a notecard to the console called forbidden-attachments that contains, line by line, keywords to look for in an avatar's attachments. Note that HUDs cannot be detected. If you want an attachment only be screened for a specific gender, add "|0" for women and "|1" for men after the keyword.

If a forbidden attachment is detected, the agent will be first warned. If the attachment is still there during the next scan the agent will be booted.

Example for forbidden-attachments Notecard

Lines that start with a #-character are ignored (considered comments). These are simple examples.

# Forbid face & body lights

facelight

bodylight

# Forbid male genitals

cock

penis

# Forbid male genitals on women

cock|0

penis|0

# Forbid bling for men

bling|1

Access Control via Access Pass

An access pass is a scripted object an agent has to wear in order to pass the console's screening. It can be anything, a badge, a mask, or a simple prim. Basically the console sends a message to any newly detected agent and waits for the correct reply from the agent's access pass. If it times out, or the reply is wrong, the agent will be booted.

You must have basic scripting knowledge to make an access pass object!

Access pass screening is off by default. To enabled it, configure the following lines:

access_pass_verification=1

access_pass_challenge=<a challenge key>

access_pass_id=<a password>

access_pass_channel=<a high negative number>

access_pass_invalid_message=<message to agent without valid access pass>

The access_pass_challenge is sent to the access pass object, and the access pass object shall only answer if it has the same challenge text. The access_pass_id is the password the access pass object sends back.

access_pass_invalid_message is a text sent to agents when they don't wear a valid access pass.

A full permission example for such a badge is included; however, you can add the full permission script to any item of your choice.

Allowed-Listing using a Group

The console doesn't support an allowed-list, it does however support a way around that. If the console is set to a closed SL group, for example your "staff" group, you may configure the console to exempt group members from the entire screening process with this setting:

group_exempt=1

Group exemption is off by default.

Note: The difference between this option and simple group screening is that group screening still does all the other screenings, while the group exemption allowed-list option is unconditional. People in the group are allowed to enter, no matter what.