Questionable MP item ..

[Qie Niangao]

1 minute ago, Coffee Pancake said:

I don't care where it stores the data to be honest .. it does .. and even if they didn't use experiences as the store, they could seamlessly do it on a website.

This thing is Redzone all over again.

I hadn't paid attention before. The demo parcel sends the browser to an in-world http server, (current ephemeral URL http://simhost-0d36f49adc219bd8d.agni.secondlife.io:12046/cap/597de7e6-ccca-9318-3ddc-5ab6410602ac/?55148282-b771-4586-ae0c-97c95539b99c ). I'd guess that's in the local device itself, but I suppose it's possible that there's just one of these in-world http servers for all the devices, and the local script uses the Experience to fetch the server's current URL, rather than any external "registrar".

Incidentally, I was wrong: Experience KVP gets 128MB, not 16. Still, it could be a scalability problem to have all instances on the grid share that one finite data store.

[Coffee Pancake]

I just checked, that page is hosted by the local prim

 

[Innula Zenovka]

14 hours ago, Coffee Pancake said:

I don't care where it stores the data to be honest .. it does .. and even if they didn't use experiences as the store, they could seamlessly do it on a website.

This thing is Redzone all over again.

I'm sorry, but in the interests of historical accuracy, I have to disagree.

Redzone was clearly against the ToS in that it purported to reveal the identities of people's alts to all users of the RedZone system.    It may also have revealed other identifying data, but at the very least it would tell all RedZone owners that "Ann Alias has the same ISP details as Anne Avatar," and I think it identified all their other suspected alts, too.   

Neither did RedZone give you any warning that your data was being scraped in this way and saved to a permanent searchable database -- you simply arrived on the region and it read your details without bothering to  ask you to open a web page.   

Those seem to me two very significant differences.   

I don't like this device but I don't think it's anything like as bad as RedZone.

Edited June 8, 2021 by Innula Zenovka

[Coffee Pancake]

It is a device designed to breach privacy, why would you assume the stated privacy platitudes are accurate.

It could easily be storing any data it liked.

It could easily be allowing the creator to see who's who.

When functioning as advertised it does inform everyone nearby  - it bans all accounts with the same IP at the same moment - people are ejected and added to the ban list in pairs.

Edited June 7, 2021 by Coffee Pancake

[Maitimo]

3 hours ago, Kimmi Zehetbauer said:

Who's to say the special webpage don't load viruses and stuff into your machine?

That's my thought too. That or a keylogger, to harvest passwords (not just SL password but anything).

[Scylla Rhiadra]

1 hour ago, Innula Zenovka said:

I'm sorry, but in the interests of historical accuracy, I have to disagree.

Redzone was clearly against the ToS in that it purported to reveal the identities of people's alts to all users of the RedZone system.    It may have revealed other identifying data too, but at the very least it would tell all RedZone owners that "Ann Alias has the same ISP details as Anne Avatar," and I think it identified all their other suspected alts, too.   

Neither did RedZone give you any warning that your data was being scraped in this way and saved to a permanent searchable database -- you simply arrived on the region and it read your details without bothering to  ask you to open a web page.   

Those seem to me two very significant differences.   

I don't like this device but I don't think it's anything like as bad as RedZone.

I'm going to agree that this is NOT as bad as Red Zone, which didn't even bother to hide its central intent, and which leveraged paranoia to an unprecedented degree to advance sales.

And I'm willing to accept that the way this has been setup (I'm intrigued by the issue of the use of Experiences) may have entirely innocent intent.

But we can't know that. And right now, it's a loaded weapon that is certainly capable of being abused.

LL can shrug this off, of course, for the reasons you suggest -- it's stated purpose is, I suppose, at worst marginally against the ToS. But waiting to see if this is abused -- and who knows how evident such abuse might be? -- is too much like LL's attitude towards Red Zone.

If you see a vulnerability, you should deal with it . . . not wait until it blows up in your face.

Edited June 7, 2021 by Scylla Rhiadra

[SpiritSparrow Skydancer]

1 hour ago, Finite said:

I don't understand the issue. Like why would this be necessary? I log on alts all the time. Sometimes at clubs I'll dance with an alt so some rando doesn't approach me. I've even RP'd before with alts in the same scene. I could see if it's a full sim or something but what's wrong with having alts on at same time?

 alts could be used in contests to stack odds.

[Finite]

3 minutes ago, Tarina Sewell said:

 alts could be used in contests to stack odds.

ah okay that makes sense.

[SpiritSparrow Skydancer]

All of the merchants items are 0L. They state they have only a short time to live and have made all their items 0L. There are so many scripts they are releasing into the wild here.  I reckon we all need to be watchful.

[SpiritSparrow Skydancer]

[Mollymews]

2 hours ago, Finite said:

I don't understand the issue. Like why would this be necessary? I log on alts all the time. Sometimes at clubs I'll dance with an alt so some rando doesn't approach me. I've even RP'd before with alts in the same scene. I could see if it's a full sim or something but what's wrong with having alts on at same time?

the main use case for these kinds of fightback systems is free entry inworld activities that award L$ giveaway prizes.  Bot runners have pretty much destroyed this kind of activity. Money trees, popular vote contests, trivia, etc

i don't know anything about this particular system being discussed,

but if it is not tied to a L$ giveaway system (meaning that the venue owner only authenticates giveaway participants, ignoring all other accounts present) then such a system will exact more damage on the venue visitor numbers than not having the system.

damage to venue patrons like yourself, for no apparent to you good reason, ends up in you not coming back. Same for people with real life partners, flatmates, etc who get caught up in all this for no apparent good reason to them

[Qie Niangao]

1 hour ago, Tarina Sewell said:

March 31, 2021, "… since a very popular sploder with an IP address check was taken off of MP."

But it's there now. Right? Do we know this story?? (Are these somehow parts of the same story?)

[Qie Niangao]

Experience KVP could act as buffer for writes to an external database, especially if you didn't want every one of these things hitting that external database directly. Could be storing lots of stuff.

Or… hmmm.

This could be a great opportunity for somebody with good browser-logging skills, or even WireShark. What does this thing send us?  Anything besides the tidy text congratulation on agreeing to be alt-tracked?

[Alma Palmira]

Rather than an alt detector, that "outs" resident's secret lives, I would love to see an alt neglector that limits your alts by censoring their vices and proclivities. It could be in the form of a HUD that contains a "WARNING: DON'T BE STUPID!" message which pops up  right before you are about to do something regrettable. 

[Innula Zenovka]

36 minutes ago, Qie Niangao said:

Experience KVP could act as buffer for writes to an external database, especially if you didn't want every one of these things hitting that external database directly. Could be storing lots of stuff.

Or… hmmm.

This could be a great opportunity for somebody with good browser-logging skills, or even WireShark. What does this thing send us?  Anything besides the tidy text congratulation on agreeing to be alt-tracked?

I've not tried it, but shouldn't it be possible to drop a script into the object that reads and echoes incoming data in the dataserver, http_request and http_response events?    I think those events fire so long as they're in the same link as the script that triggers them, don't they?   (Well, I know the dataserver event does, which is why you have always to check that the incoming key matches the outgoing request so I suspect the other two do, too).

 

[Darya Vortex]

I have some doubts about an Alt tester;  not all alts are malicious.

If I recall correctly, there is a push in the Eurozone about the “right to be forgotten” as part of their awesome focus on privacy, so services like this might draw ire for thwarting that?

[Paul Hexem]

It's not SL without drama.

That said, if that other club/sploder related networked security system is still allowed in SL, this one probably is too.

[Phil Deakins]

On 6/7/2021 at 5:56 AM, Tarina Sewell said:

The following if from ad.

"This will protect your place in Second Life from alts (a user with multiple avatars). For various reasons many parcel owners and event hosts prefer not to invite alts to their parties.

That's from the very first post in the thread, and it wasn't brought up again until a few posts before this one. With all the talk about what the device might be storing, and why, that obvious reason seemed to have been overlooked until Tarina brought it up again.

If that's the purpose of the device, and if it doesn't do anything other than detect and deal with alts on the fly, then it seems like a very useful device to my way of thinking, because it would largely protect against alts loading competitions in venues. I have no doubt that many, most, or all venue owners would have wanted, and still want, something like it when they held/hold some types of competitions.

Whether or not it is within the LL rules to do it, I don't know, but it does seem like a very good idea, and it does appear to be a VERY long way from being another Red Zone.

[Qie Niangao]

8 hours ago, Innula Zenovka said:

I've not tried it, but shouldn't it be possible to drop a script into the object that reads and echoes incoming data in the dataserver, http_request and http_response events?    I think those events fire so long as they're in the same link as the script that triggers them, don't they?   (Well, I know the dataserver event does, which is why you have always to check that the incoming key matches the outgoing request so I suspect the other two do, too).

Good idea. I tried that (even though I'd been most concerned with data flowing in the other direction, where Experience KVP could gradually supply more of that than a single script could hold on its own) and didn't see any surprises in those events (nor anything coming down the wire the other direction*), but I was surprised to discover my alt, not previously known to this alt-detector system, was immediately identified as an alt and banned from my test parcel when he accepted the URL, and of course he shares an IP address with the other alt I sent into the demo area yesterday. That could be a bug, I suppose, but I think it's actually using KVP to store (hashes on?) the IP addresses of everybody who accepts that URL anywhere. If so, then I was wrong about the intent of the product: it doesn't merely prevent alts appearing on the same parcel as other avatars sharing that IP, but rather any alts it's detected anywhere else.

But that would appeal to no venue-owner I've ever known, if they actually understood what it's apparently doing.

[ETA: On further thought, who knows what it's even trying to do? When it detects an alt, it says "Your alts have been detected and they will now be temporarily blocked from this area.  Please visit again later (one avatar at a time)" where that one-at-a-time rule would suggest it's not trying to ban alts detected elsewhere, even though it does. But it also kicks an avatar explicitly listed as an admin in the Settings notecard, so either it's a buggy mess trying to do something relatively innocent, or that's all just a half-assed attempt to cover for something less innocent.]

[ETA2: I should have mentioned that it does appear to llGetKeyValue(), generating a dataserver event of the form "1,9999999999~UUID" where the 999s could plausibly be a hash on IP address, and the UUID is that of the alt who first accepted the URL.]

__________________
* I can't readily perform this test with any certainty, so I didn't try very hard. To do a valid test I'd need to change my IP address to something other than one the alt-detector system has seen before, and I can't be bothered.

Edited June 8, 2021 by Qie Niangao

[Innula Zenovka]

49 minutes ago, Qie Niangao said:

[ETA2: I should have mentioned that it does appear to llGetKeyValue(), generating a dataserver event of the form "1,9999999999~UUID" where the 999s could plausibly be a hash on IP address, and the UUID is that of the alt who first accepted the URL.]

Thanks for doing all the testing!   That's certainly how I'd envisaged the KVP working, though I'd have keyed it to the parcel, which this system certainly doesn't seem to, since it recognised your alt from an IP address collected at a different location.    

I'm a bit unclear on how the IP address gets into the KVP records, since I don't know what the web page does when you open it, though I can think of several possibilities.   However, I'm a bit surprised there was nothing incoming to detect, since where else could the hashed IP address come from to compare with the KVP value?   

1 hour ago, Qie Niangao said:

But it also kicks an avatar explicitly listed as an admin in the Settings notecard, so either it's a buggy mess trying to do something relatively innocent, or that's all just a half-assed attempt to cover for something less innocent.]

I suspect Hanlon's Razor probably applies here.   It generally does, in my experience, and particularly in SL.

[Qie Niangao]

1 hour ago, Innula Zenovka said:

I'm a bit unclear on how the IP address gets into the KVP records, since I don't know what the web page does when you open it, though I can think of several possibilities.   However, I'm a bit surprised there was nothing incoming to detect, since where else could the hashed IP address come from to compare with the KVP value?   

Oh, yeah, http_request must be raised when the llLoadURL page loads, but I think I missed that (possibly because I was already booted when it was reported?*).

Probably already clear, the detector's llLoadURL appends the avatar key to the base URL of the prim's http server, so then it can simply associate that with the IP address in the request pulled by the browser, hash the address and if it's new, write the pair to KVP.

To find the IP address can use llGetHTTPHeader() something like:

key reqURL;
string myURL;

default
{
    state_entry()
    {
        reqURL = llRequestURL();
    }
    touch_start(integer total_number)
    {
        if ("" == myURL) return;
        key toucher = llDetectedKey(0);
        llLoadURL(toucher, "Choose your fate:", myURL+"/?"+(string)toucher);
    }
    http_request(key reqID, string method, string body)
    {
        if (reqURL == reqID)
            myURL=body;
        else
            llWhisper(0,method+" "+body
            +"\n for avatar UUID: "+llGetHTTPHeader(reqID, "x-query-string")
            +"\n at IP address: "+llGetHTTPHeader(reqID, "x-remote-ip"));
    }
}

[* Edit: Hmm. Are we sure http_request event is raised except in the one script that made the corresponding llRequestURL call? When suggested it seemed right that it would behave like dataserver, but now I doubt it, which would explain why I didn't see it reported by my prim "event-snooping" script.]

Edited June 8, 2021 by Qie Niangao

[Innula Zenovka]

1 hour ago, Qie Niangao said:

Oh, yeah, http_request must be raised when the llLoadURL page loads, but I think I missed that (possibly because I was already booted when it was reported?).

I'm not sure that llLoadURL raises any sort of event -- I can't detect anything, either, other than the results of a successful llReadKeyValue call after I (or one of my intrepid testing alts, rather) opens the web page, where it seems to return the alt's uuid, keyed to the IP address.

So I'm not sure how the script gets the hashed IP address in order to read the UUID, since it doesn't seem to be in an http request or http response event.    I'd be interested to know how that's done, but I'm not going to spend long wondering about it.

ETA  I was mistaken -- I tested your script and it looks as if, unlike the dataserver event, the http request event fires only in the script calling llLoadURL.   So presumably it reads the IP address using http request, as in your example.

That makes sense, though I think if I were making such a device (and I would take a lot of persuading) I'd construct the key as a compound of the parcel key and the hashed IP address, since all I really need to know is whether the visitor is the alt of someone who has previously visited this parcel rather than the answer to  the more general question of whether the IP address is used by more than one account, none of whom have necessarily ever visited the parcel before.

Edited June 8, 2021 by Innula Zenovka

[Maryanne Solo]

Strolls in..... (popcorn burp)
oooeee! ^^ 🥴 
This is for the forums.... right?

😂😆😂😂😋🤭

[Innula Zenovka]

1 hour ago, Maryanne Solo said:

Strolls in..... (popcorn burp)
oooeee! ^^ 🥴 
This is for the forums.... right?

😂😆😂😂😋🤭

This is what inevitably happens when you put several scripters together

Edited June 8, 2021 by Innula Zenovka

[Silent Mistwalker]

Fine. Keep on scripting things that punish innocent people.

The more venues/parcels use scripts to keep people out for no other reason than they share an internet connection, the less people want to be in SL.

All I ever wanted was a couple of good friends but I keep getting this 💩 instead.