✨ Feature Requests

Some ISP:s in the world offer high bandwidth connections directly to consumers, while not having the infrastructure to forward all that traffic at the offered speeds. This can lead to a situation where the viewer's bandwidth setting is set quite high, while in reality the connection can't handle that throughput all of the time, or with very shifting actual capacity. I would like to propose that the viewer upon failing to log in, or failing in teleporting, if it can detect the signs of packet loss or connection issues causing this, that it recommends the user to reduce the bandwidth setting. Perhaps proposing to the user to start very low, and if it works, to increase it at future attempts.

This has been going on for a while, and lately really aggressive, so it is time to talk about the increased sensitivity of account security features which is not useful at all. There are two key problems getting very annoying lately in this regard: 1: SL websites "forgetting" login and forcing login when you open the websites from your other device (PC and phone for example) despite "remember me" has been enabled at last login. 2: MFA challenges being required too often, for logins to non-critical websites from the devices we use every day. The way certain external services, mainly Support cannot remember a login, never made sense, but apparently the last few months this got worse because "security features" interfere with it. Simply put, I always open the Support website on my PC, never on my phone. I almost always open my Dashboard from my phone, very rarely on PC. If I open Support on the PC, I will have to log in. Regardless of "remember me" enabled, it happens that I have to log in several times over a few hours, because the website just "forgets" my login. Makes no sense. However the more annoying part is that after this, if I open my Dashboard on my phone (where I had been logged in), I need to log in again. So it seems the two devices (PC and phone) cannot stay logged in simultaneously. Why? I can stay logged in from several devices on my Google account for example, it saves them as trusted devices. It can't be too difficult to implement that for SL as well. The other problem is MFA tokens being required too often and for non-critical logins or actions. For example twice within 24 hours at Support, from the same PC. Then just before starting to write this, got a MFA challenge when I had to log in again on the phone to look at my Dashboard. 3 token challenges within 24 hours for non-critical logins from the two devices I've been using (exclusively) to log in to any SL service for several years. I understand you are trying to increase security to reduce risks of account theft, but... Who is going to try and steal my account using the PC and cell phone only I use? If someone tries to log in to your account from an unknown device and IP address, yes, BY ALL MEANS require a MFA token immediately each time it happens, that is what it is for. Logging users out of their accounts on one of their daily-use devices because they want to use the other daily-use device to access the same account is nonsense. And MFA challenges for non-critical actions on these daily-use devices is pointless as well. (At the same time still a lot of people get their accounts stolen because they still don't use MFA and they still enter their username and password on fake marketplace websites.) Please sort this out and if you can't recognize trusted devices automatically, add an option to add several devices on the Dashboard. Then these devices should stay logged in simultaneously if "remember me" was enabled at the last login, and except for critical actions (account detail or status change, membership, land, money) these devices shouldn't receive MFA challenges.

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.

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

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.

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