[BUG-11462] There is a SL 'RP game' Called eternal conflict its similar to Bloodlines and users are griefing avatars with it

[sl-service-account]

How would you like the feature to work?

I would like LL to enable land owners / renters to be able to block the hud for this game, we own a Gothic club thats 8 years old in second life and we get many IM's saying that our patrons are being griefed by this game hud the url to their website is:- http://eternal-conflict.com/ at the moment i do not have a copy of the hud but i will use an alt if possible to acquire one and add the comments here later

Why is this feature important to you? How would it benefit the community?

its a griefing hud that should only be used in regions or parcels that want to have it used i.e. rp sims or parcels,

I am going to add it to my covenant on my region that it can't be used but we need some way to block it or detect its use, many other people have spoken to me that own shops and clubs about this issue

If LL would like to send me the channels and urls it uses we can make a detector^^

this is what my scripter friend said:-

Well simply put we should be able to see scripts (by name and UUID) that are running on a region. As well as what domain or domains it may be speaking with if it uses llHTTPRequest or llHTTPResponse, or has an http_response event. We should be able to block scripts from running by name, UUID, or Creator UUID at the parcel and region levels.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-11462 | | Summary | There is a SL 'RP game' Called eternal conflict its similar to Bloodlines and users are griefing avatars with it | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Reporter | Phoebe Avro (phoebe.avro) | | Created at | 2016-02-25T22:56:06Z | | Updated at | 2016-03-02T19:39:21Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2016-02-25T18:08:05.057-0600', 'How would you like the feature to work?': "I would like LL to enable land owners / renters to be able to block the hud for this game, we own a Gothic club thats 8 years old in second life and we get many IM's saying that our patrons are being griefed by this game hud the url to their website is:- http://eternal-conflict.com/\r\nat the moment i do not have a copy of the hud but i will use an alt if possible to acquire one and add the comments here later", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "its a griefing hud that should only be used in regions or parcels that want to have it used i.e. rp sims or parcels,\r\n\r\nI am going to add it to my covenant on my region that it can't be used but we need some way to block it or detect its use, many other people have spoken to me that own shops and clubs about this issue\r\n\r\nIf LL would like to send me the channels and urls it uses we can make a detector^^\r\n\r\nthis is what my scripter friend said:-\r\n\r\n Well simply put we should be able to see scripts (by name and UUID) that are running on a region. As well as what domain or domains it may be speaking with if it uses llHTTPRequest or llHTTPResponse, or has an http_response event. We should be able to block scripts from running by name, UUID, or Creator UUID at the parcel and region levels.\r\n\r\n", } ```

[sl-service-account]

Phoebe Avro commented at 2016-02-25T23:13:17Z

as far as I know so far the hud is called NoE - Main HUD v2.25a
but that is from a 3rd party that told me that I will get a copy under an alt to check out its name I think they have more than one hud.

[sl-service-account]

Phoebe Avro commented at 2016-02-25T23:15:54Z

from the website it states:- Demon HUD v1.0.6:

[sl-service-account]

Phoebe Avro commented at 2016-02-25T23:22:31Z

ok it seems there are two different systems (games) at the moment we are interested in the Demon HUD v1.0.6: from eternal conflict, but we have also had reports about the other one.

[sl-service-account]

Certified Lunasea commented at 2016-02-26T00:08:05Z

After looking at the system rules on the game website (which I have pasted below) I see issue particularly with rule #3, especially since "mortal" persons appear to be those that have not opted-in to this game. I can say that personally I would like to see this kind of data collection scheme masked as a game become a violation of the Linden Lab and Second Life Terms Of Service and Community Standards documents.

---Begin Pasted Content--- SYSTEM RULES Even though the system offers endless possibilities, there are couple of things that you should not do for your own good.

1. No fighting/combat of any kind in the High Heavens and Hell nor anywhere on the EC Sim. This means no attacking of any kind with the A&D HUD or any other HUD games or systems while on the EC Sim. The EC sim is a COMPLETE safe-zone.

2. There can be no rules, punishment, and/or official complaint for an attack that comes from the opposite species, or from an arranged event by Sators or those within an officially declared conflict by Leaders (Chieftains/Cardinals).

3. Do not reveal to a mortal that you or anyone else is/was feeding from them, unless you are in the process to descend/transcend them.

4. You are allowed to sell your backpack items ONLY on the Marketplace. You are free to give away those items but if you are selling them they must go on the Marketplace. Also you can sell our other products such as blood tanks and etc but you must rez them and place them for sale so that the buyer can directly buy the product we do not want to hear any complaints like "I bought a blood tank and the person never gave it to me." ---End Pasted Content---

Whether or not these types of data collection schemes masked as games are added as a violation of the Terms Of Service and Community Standards documents, I would agree that being able to block scripts from running in a manner like what is asked for here (if possible) would be very beneficial to land owners and would potentially provide patrons of stores, clubs, and other venues in Second Life a feeling of a safer environment free of potential harassment without their active or passive knowledge and consent.

These games are a bit of a problem in Second Life, and There really isn't a good reason I can see that these games like this or Bloodlines NEED to collect the UUIDs of users who are not active participants or who have not agreed by interaction to have their UUIDs collected. For me the issue is with collection of names or UUIDs that is done without a justifiable and real NEED to do so. This essentially allows all users of Second Life to become unwitting/unwilling pawns in such data mining games.

With these games the storage of non-player user information(IE those that have not somehow opted-in to these games) is not necessary as the scripted HUD itself could just as easily store X number of UUIDs that have been "fed on" locally and provide a few "points" for each one of these. That list could drop old entries as new ones cycle in. This would prevent the same users from being targeted (as game designers would want) as well as allowing the same kind of "feeding" these games use without sending UUIDs and/or names to an outside server/service.

So the big question I have is why haven't these game designers done this instead? It would have saved any controversy over business practices, ethics, and data collection issues. It also would still allow them to attract new players (without potential financial penalties for allowing them to join whichever side they please). All by using a much more ethical opt-in system. The way these things are with these games now it is more like unsolicited spam or telemarketing and when someone does finally decide to play there may be costs to playing that weren't initially known.

That being said, I am not saying that all collection of UUIDs on an outside system without prior consent of the holder of said UUID are without merit or need. For example buy as gift vendors are an appropriate use of such collections, and retention of that data is appropriate in such vendor systems that allow for re-delivery of gifted products to the person that is receiving it. Uses such as these are necessary for these kinds of vendors and allow for improved user experiences.

As it stands even with the channel information for these scripts we would not be able to make a reliably effective detector. The developer could employ a few different methods to disable such detectors and with that in mind I must agree that we do need better ways of blocking known bad players at the parcel and/or region level (preferably both). I know that even if such blocks were to be implemented at the parcel level that they may be easily circumvented by simply standing on a different parcel to run the blocked script. With this kind of option at least parcel owners would have some say about what could and could not run on their land without having to disable scripts for all visitors/patrons, which could negatively impact the experience and perception of said venue.

[sl-service-account]

Camden McAndrews commented at 2016-02-26T00:42:21Z

I would recommend that Linden Lab take proactive action to identify script systems like this that should require the land owner take special action to enable those scripts to run, instead of a system requiring land owners to opt OUT of the griefer gadget.

Griefers have nearly destroyed Second Life. It's long past time for Linden Lab to stop coddling them, for the sake of saving their own business and regaining user trust. Without that trust, any new projects that Linden Lab might attempt are doomed to fail before they even open.

[sl-service-account]

Phoebe Avro commented at 2016-02-26T01:41:17Z

demonHUD v.5.0 Progeny: vampire HUD 0.3.5.3

2 more

[sl-service-account]

Phoebe Avro commented at 2016-02-26T01:42:32Z

Noe-MainHUD v2.25a

another

[sl-service-account]

Chaser Zaks commented at 2016-02-26T09:29:44Z

Although I do know the struggles of people using RP huds that can annoy other patrons, the best thing to do is warn the user(and eject/ban if they persist). By adding a function that displays the communicating domains for llHTTPRequest and http_request, this may cause some security issues with some scripts, especially object to object communication. You can see if a script currently has URL(s) registered by going to parcel > running scripts and looking for a avatar's username. It will have a URLs field that shows how many are registered.

As for blocking scripts, that's quite hard. LL can ban a specific script from compiling(even if it's been modified) but it's easy to bypass(I will not disclose how), and scripts get new UUIDs each time you compile them, just like notecards(I THINK, don't quote me on this I could be wrong). Even then, if you copy a object, all the scripts get new UUIDs to save their states. For names, those can easily be changed as well. And for blocking creators, this would just create a group of upset users saying SL is censored or something, and it would highly upset content creators and potentially make some leave.

You can find out the channels the huds communicate on their own, or contact the creator and ask if you can have a detector(or even have your sim blocked, some in SL games do this!). But LL will not disclose user's script details as it would create trust issues between LL and the userbase.

[sl-service-account]

Lucia Nightfire commented at 2016-02-27T04:45:07Z

I have, on several occasions, requested in the OH meetings to have llGetAttachedList() updated to return HUD keys with same owner scripts, land owner scripts and experience compiled scripts over same experience allowed land.

They've mentioned interest, but stated its not a high enough priority concern atm.

Without this update, land owners cannot regulate the wearing or usage of unauthorized HUDs over their lands.

Also see https://jira.secondlife.com/browse/BUG-10475

[sl-service-account]

Certified Lunasea commented at 2016-02-28T12:44:02Z

In regards to displaying domains that are used by llHTTPRequest being a script security issue: I don't see this as an issue at all. The domain is not a specified page or location at all (that is what a Universal Resource Locator, or URL, is). If such a list were implemented then a script attempting to communicate with this jira page would show a domain of secondlife.com, not a the full URL (unless the script is communicating with the home page of the domain).

Remember all Domains are URLs, but not all URLs are domains. A domain is a generic piece of information compared to the specificity of a URL for the pages a script may be communicating with. I don't think anyone needs to see the individual pages or query strings that may be contained in the URL. With that in mind there isn't any legitimate security risk that I see with providing the domain, especially if the proposed feature were to restrict the access to the domains to the land owner.

The concerns and difficulties with the different methods for added script controls that I see are as follows:

1. Large hosting farms and cloud based hosting services could make Domain based blocking effect more than the intended scripts in some cases. That being said, I think that being able to block certain domains from being contacted would actually be a step in the right direction for data mining scripts. I can see some ways this might cause issues for other products, however.
2. Blocking scripts by UUID is, due to technical limitations, a massive pain. I also have to agree that this could easily be circumvented.
3. Blocking a script by name would be similarly difficult due to the ability for a script to be re-named.
4. Blocking creators would be easier than by UUID or name, but I would concede that you are correct that it would upset some customers and creators. That being said if the creator was blocked for creating something that was designed for malicious use (like some of the attack HUDs and such that make using public sandboxes miserable at times) then I don't think I would lose a wink of sleep over their being blocked. That all being said it isn't hard to transfer a script to an alt and start distribution all over again so this too would be fairly easy to circumvent.

I am don't think there is an elegant solution to this issue at all. But I would have to say that there needs to be some added ways for land owners to be able to block certain scripts from running without needing to shut down the run-scripts permission for every visitor.

Controls like Lucia has suggested would be a great start to a solution. Such scripted calls would simplify building detectors in cases of problematically scripted HUD attachments whose creators are unwilling or unable to provide a detector (even if at a cost) or assistance in the form of region blocks or information to aid in detector creation. In the case of parcel owners they aren't even able to request for a region block unless they are the person that owns the region in question. In such cases where a detector is not available from the creator and region blocking is not an option, then it falls to third parties to make a detector, but any third party detector that is created or available will only useful if someone has not obfuscated the object, which is also very easily done even on commercially available products.

No matter which way we try to solve this type of issue there is not going to be an iron-clad fix, that is just the nature of SL.

Having said that, I would definitely support the addition of domain (not URL) information being displayed to land owners, as well as addition of domain (or even URL) blocking controls for land owners. I believe that these would be most effective at the parcel level. It might even allow rental agencies to enforce parts of their own covenants in a much easier way. If Lucia's suggestion for llGetAttachedList() were also implemented then it would help anyone willing to script a detector for a HUD-worn object, and I know some hunt coordinators and participating merchants that would love to be able to detect those object finding HUDs.

[sl-service-account]

Camden McAndrews commented at 2016-03-01T04:53:20Z

This might be relevant: An avatar running on the text-only SL client, Metabolt, is able to report what attachments an avatar is wearing. So obviously this information is delivered to an SL client. I just now tested it and confirmed that my model running on Metabolt can see what I have attached. It reports the name of the object, it's UUID, and where the object is attached. It doesn't report HUD objects so I assume they're not available.

Metabolt is scriptable via its API, but its future is uncertain since the original developer had to leave it and no reliable programmer has picked up the wand. (I can't; it's way outside my experience with programming. We really need a knight in shining armor to come to its rescue.)

That said, at least that much information is obviously available, so the additional work required would be to add an LSL function to make the datums available to an LSL script, eliminating the need to run a bot and rely on unsupported third-party software to accomplish the task.

[sl-service-account]

Whirly Fizzle commented at 2016-03-01T05:16:19Z

@Camden Other TPVs have this feature too. I'm unsure which others have it but Firestorm does. Firestorm "Area Search" will allow you to list all objects and attachments on the region (& neighbouring regions if you choose that option). You can choose to filter results to just avatar attachments. Firestorm will not list HUD attachments worn by other avatars, only your own HUDs. It is quite possible for the viewer to list HUDs worn by other avatars though. The first test builds of Firestorm for the area search feature showed other avatars HUD attachments. However it was decided to remove the ability to display other avatars HUDs because it was considered an invasion of privacy. Other avatars non-HUD attachments can easily be found by other means, however HUD attachments cannot, which I think is for the best.

[sl-service-account]

ObviousAltIsObvious commented at 2016-03-01T05:33:05Z

There is a script function to get non-HUD attachment information, http://wiki.secondlife.com/wiki/LlGetAttachedList - combine with llGetObjectDetails etc. and much information about external attachments is already available.

[sl-service-account]

Kyle Linden commented at 2016-03-02T19:39:22Z

Hi Phoebe,

Thank you for your suggestion. The team has reviewed your request and determined that it is not something we can tackle at this time.

Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team.

This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests

Thanks again for your interest in improving Second Life.