✨ Feature Requests

Background With Second Life's transition from traditional data centers to AWS, many content creators and service operators had to disable IP-based filtering for external script communications. AWS's dynamic and ambiguous IP allocation makes it impractical to define a reliable range of Second Life simulator IP addresses. This change has introduced security challenges for external systems interacting with in-world scripts. Some scripts cannot be updated because they were distributed by creators who are no longer active, while others remain unchanged due to user hesitation. Reasons include lack of technical knowledge, extensive modifications, or accidental use of outdated versions. The Problem Without a reliable way to verify that an HTTP request originates from a legitimate Second Life simulator, external services are vulnerable. If an attacker discovers the URLs and payloads used by in-world scripts, they can replicate the requests, potentially tricking external systems into treating them as legitimate in-world interactions. Proposed Solution A simple but effective solution is to add a new HTTP header to llHTTPRequest : X-SecondLife-Region-Hostname - This header would return the value of llGetEnv("simulator_hostname") , providing a hostname in the format: simhost-0dd08effbc13e71c9.agni.secondlife.io Security Benefits External systems can verify the request's authenticity by: Ensuring the hostname ends with .secondlife.io , confirming it originated from a Second Life simulator. Performing a DNS lookup on the hostname (e.g., simhost-0dd08effbc13e71c9.agni.secondlife.io ) to retrieve an IP address. Comparing the resolved IP address with the IP address that initiated the request. If they match, the request is valid. Impact This change would allow external systems to restore security measures for scripts that cannot be modified, ensuring continued protection without requiring manual updates from creators or users. By leveraging an existing environment variable, this solution is lightweight, practical, and easy to implement.

Would be great to auto log in after log out as well as sit on a predetermined furniture. Especially after restarts.

I want to suggest a feature idea to help counter copy-bots and bot-based griefers in private regions. This feature would let region owners optionally enable more security for their regions. The idea is for regions to validate viewers with special keys Related - https://feedback.secondlife.com/feature-requests/p/start-verifying-viewers Proposal Details: Region owners can turn this feature on or off If turned on: * LL and official TPV viewers would connect to regions using a private key for validation * The simulator would check the connection with public keys and decide if the viewer can connect. Validation happens entirely on the simulator side, and viewers would send encrypted requests with private keys if the region has this feature turned on * To handle viewer/simulator updates or key refreshes, the system could support multiple keys (old and new) * The "officialness" through key can be controlled by Linden Lab through key management with each TPV project Benefits: Regions with this option turned on would block viewers that don’t have valid keys. This could stop unauthorized viewers from stealing content or trolling other residents and region owners Residents using official viewers wouldn’t notice any difference. They’d connect to the region just like always through LL and Official TPV viewers Project viewers or new TPVs without keys could still connect to regions that don’t use this feature like right now Residents and region owners would have fewer concerns about trolls and content thefts. Linden Lab will have to deal with less AR cases This does not leave a trace of connections except on the simulator so 3rd party would not know which viewer was used to connect to the region (rejected would not be in the region) Key Management: Linden Lab would issue unique key pairs (private and public), and give the private key for each LL and TPV viewer TPV teams would be responsible for keeping their private keys secure. These keys should be kept secure to prevent leaks or misuse Linden Lab would revoke keys if they are leaked or misused Linden Lab would provide a way for TPV teams to request new keys if they are lost or compromised Why This Matters: I had a chance to meet a region owner who has been dealing with massive griefing and suspected content theft. They have a large community in their region, and visitors are systematically trolled, and their unique content seems to be stolen. This idea came to me as a way to give region owners more control while still keeping things simple for users

The reliability of the world map is really poor. Tiles disappear/appear as you zoom in and out, it takes way too long to display a proper map and often doesn't display anything at all. I spend more time zooming in and out of the world map trying to get stuff to appear than I do actually using the world map. I think this experience is pretty common amongst residents. When I talk in the Second Life discord, viewer developers seem to think that it is simply 'the way it is' - 'The old image must be cached' etc. What I'm saying is that fundamentally it seems like whatever protocol powers the world map does not seem fit for purpose. Failures are too frequent on all viewers, TPV or first party cannot reliably render the world map when opened. I think this should be taken to the drawing board, the fundamentals and failure points assessed, and a better, more fail-safe world map protocol should be designed that will address the reliability issues of the existing design.

Add encryption to all client-to-server communications. For example, by AES encrypting the UDP packets using a data key sent over the TCP login channel. If this isn't feasible in the short term, move any messages that potentially have highly sensitive communications, such as chat and IM messages, to TCP. Failing that, provide a UI warning before users log in using open wifi networks. There is an extremely high risk of real world harm to people who fail to realize the implications of logging in over an open network - consider a scenario where a user logs into SL using an open college wifi network, someone sniffs the network traffic, then passes around private messages about their sexuality or another highly personal topic. I highly recommend that the SL team do an internal risk assessment or threat modelling exercise as a double check. Potentially scary stuff.