WatchTower should be documented as an owner operations tool with clear limits. This protects customers, visitors, staff, and FlaroCity support. The safest documentation is honest about what the system can collect, what it cannot collect, and what depends on Second Life permissions.
Core safety principles
- Keep owner tokens private.
- Do not claim land powers the object does not have.
- Do not describe scanner data as perfect proof.
- Do not describe Chat Relay as private IM logging.
- Rate-limit notifications and repeated alerts.
- Keep audit logs for sensitive actions.
- Use small LSL payloads and bounded queues.
- Show stale data clearly.
- Make subscription locks and add-on requirements clear.
- Give owners enough troubleshooting information to fix permissions safely.
Token privacy
The token connects an in-world object to the dashboard. Treat it like a password for that object. A token may appear in the object description as WTTOKEN:.... Owners should not paste it into public chat, share screenshots showing it, or copy it into unrelated objects.
If a token is exposed, reset it. The dashboard should allow admins or owners to invalidate old tokens when necessary.
Visitor data
WatchTower can record avatar presence as seen by a terminal scan. This may include avatar UUID, avatar name, display name, position, distance, parcel/region presence, and timestamp. The docs should describe this as operational land data used by the owner.
Recommended wording:
WatchTower records avatar presence seen by the in-world terminal so owners can understand land activity, staff coverage, security events, and support issues. Scanner data is limited by Second Life scripting and should be treated as last-seen operational data, not perfect proof of all activity.
Chat Relay privacy
The safe Chat Relay is public local chat channel 0 only. It should be opt-in by the owner and documented clearly. It does not read private IMs.
Recommended wording:
Chat Relay can relay public local chat from the monitored area when enabled. It does not read private instant messages. Owners are responsible for using chat logs according to their land rules, community expectations, and applicable platform policies.
Security action audit logs
Security actions should create audit logs. At minimum, logs should include:
- Requested action
- Target avatar UUID/name
- Location
- Requesting user/staff member
- Time requested
- Time attempted
- Security Worker result
- Failure message if any
Audit logs protect both the owner and staff. They help answer what happened without relying on memory.
Permission limits
Second Life permissions can affect every action:
| Feature | Permission dependency |
|---|---|
| Warn | The terminal must be online and able to send the private message. |
| Kick | The object/owner/group must have the land authority needed to eject at that location. |
| WatchTower Block List | The website stores the rule; each enforcement still uses permission-dependent eject at a fresh protected-land detection. |
| Access Gate | The terminal must report account age and have eject authority after the warning window. |
| Scanner | Scripts must run; the scanner only sees what LSL can report. |
| Chat Relay | The listener must be active and the owner’s allowlist/filter rules apply. |
| HTTP | Region and LSL HTTP must be functioning. |
Data retention
Retention is category-specific. Lag and land telemetry is bounded to 30 days, raw event intake is bounded to 90 days, detailed presence snapshots are compacted, and daily/weekly/monthly server rollups support longer trend views. Billing, support, security audit, and abuse-prevention records may be kept under different operational policies.
WatchTower shows operational history in Second Life Pacific time while database timestamps remain in UTC. No plan promises permanent unlimited raw data.
What to avoid saying
Avoid these claims:
- “Guaranteed enforcement.”
- “Sees everything on your land.”
- “Tracks all chat.”
- “Verifies real-life age.”
- “Works even without permissions.”
- “Never misses anyone.”
- “Permanent unlimited history.”
Better words:
- Seen
- Last seen
- Attempted
- Reported
- Permission-dependent
- Owner-enabled
- Public local chat
- Operational history
- Dashboard review