Mandatory Marketplace disclosure about the use of off-world servers under the merchant's control in a product
closed
Peter Stindberg
The problem
Complex projects and products have always resorted to external servers under the control of the specific designer/creator who made that product. This always carried a risk in the case of the designer going out of business, or the external server being compromised or data being leaked. This would result at least in a disruption of service, or ultimately in a paid-for product not working anymore,
In the past, using a setup like this required skill and experience, leading to the educated assumption that the off-world servers would be professionally maintained and secured. A prominent example would be CasperVend.
Fast-forward to 2026, where LLM's give laypeople the tools to set up complex client server solutions, connecting LLM generated LSL scripts with LLM generated off-world server scripts. It's a sad truth, that those projects often lack basic cybersecurity and scalability, redundancy, graceful degradation, can leak data, or can incur sudden - often dramatic - cost spikes on their creators. The result is, that as fast as those products land on the Marketplace, as fast they become inoperable and a customer is left with the SL-side of such a product, and a non-functioning off-world server, rendering their legitimate purchase useless.
The scenario
- Imagine you buy an item like a new body, high-priced, 5k range. Something you'd never think it would require an external server.
- Imagine the body-creator however uses external servers for statistics, access control, marketing or assets for a HUD.
- Imagine the server of the creator goes down, or the creator goes out of business.
- The result: Your purchase is not usable anymore, you have a 5k L$ pile of trash.
The solution
I suggest a mandatory field for (new / updated) Marketplace listings, where the creator has to declare whether they use off-world components for their products or not.
That way, a potential customer can decide for themselves if they trust the creator's expertise enough to believe their product will still work in a year or 5 years, or if they rather not take the risk.
Customers in SL expect to buy-to-own, and not to hidden-subscribe to products.
Risk / benefit analysis
I am aware that this is hard to police, and that it WILL be abused (i.e. false assurance will be given). In case of conflict, it would be easy for the Lab to check any given product for off-world http-connections, and if a creator has given a false assurance, this can be dealt with.
Any creator serious about cybersecurity, privacy, scalability and reliability can state so in their product description and/or the "Profile" part of their Marketplace store.
Ultimately, the customers win and get enabled to make their own decisions.
Log In
J
Juniper Linden
updated the status to
closed
Hello, and thank you for your feature request.
Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: Feature Requests
This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.
We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.
Thank you for your continued commitment to Second Life.