Privacy, Permissions & Safety

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

1. Keep owner tokens private.
2. Do not claim land powers the object does not have.
3. Do not describe scanner data as perfect proof.
4. Do not describe Chat Relay as private IM logging.
5. Rate-limit notifications and repeated alerts.
6. Keep audit logs for sensitive actions.
7. Use small LSL payloads and bounded queues.
8. Show stale data clearly.
9. Make subscription locks and add-on requirements clear.
10. 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:

Data retention

Current plan history draft:

Extended History adds longer retention according to final policy. The docs should define which data categories are extended. Billing records, support records, abuse-prevention logs, and audit trails may need different retention rules than normal live dashboard history.

Recommended wording:

WatchTower keeps operational records for the history period included with your plan. Some account, billing, support, or security audit records may be retained longer when needed for service operation, dispute review, abuse prevention, or account safety.

What to avoid saying

Avoid these claims:

• “Guaranteed ban/eject.”
• “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