HTTP Questions

[Gregory McLeod]

I have a script which currently communicates with an external website. Each time an avatar interacts with the prim containing the script a message is sent via llHTTPRequest using the POST method and then waits for the response with the http_response event.

My understanding of this is that the sim generates the communications with the external website using an IP address that it has and this will be contained in the message header which allows the website to generate a response to that IP address.

My question/s

1. Will the IP address be the same for all communications from the prim (unless region restarted)?

2. If an avatar is wearing a HUD (essentially an attached prim) and that prim sends a similar message to the website will the IP address used be the same for all avatars in the sim or region?

3. If the answer to the last is yes do I need to make a request for a URL (llRequestURL) and will the same sort of POST message use the URL?

[Freya Mokusei]

The IP address is determined by the simulator/region the script is on. It does not vary unless the sim/region moves (such as via a restart), or the script moves (if it's attached to an avatar that TPs). All IP addresses will be the same within the same region (it's not user/object/connection dependant). There is no way to obtain data about the user of the LSL scripts by analysing the HTTP connection.

I don't understand your last question. Can you rephrase? llRequestURL works in the same way, the request is made by the simulator. Maybe you mean llLoadURL?

[Gregory McLeod]

Thanks for your reply.

I probably, through ignorance, phrased the question badly, sorry.

What I meant was if it was required to distinguish between multiple avatars all wearing a HUD it has been suggested that knowing their IP address would work. I need to understand the mechanism of the use of IP address within SL.

For example if an avatar interacts with the HUD to "activate" it, the HUD script could request a URL as if it were going to be able to respond to an http_request. An outgoing message would give the requested URL. If the HUD only releases the URL when it is detached (thus releasing the URL) the avatar can be uniquely addressed by the given URL.

Or have I misunderstood the whole thing?

[Freya Mokusei]

I would avoid IP address, it is not a reasonable measure. Again I don't really understand what you're expecting to achieve, but IP address does not seem like a mechanism that will help you.

Two SL users can share the same IP address if they are connecting through the same DSL link or otherwise sharing a connection. Further, as IP addresses are changeable and transient, you will have no ability to conclusively prove that a user  is a returning user, should their IP address change.

All HTTP traffic except that which loads in a browser window (or MoaP) is sent from the region, no information that will identify a user - including their IP or agent header - is sent. MoaP and most other HTTP methods in SL are user-optional/non-automatic, and can't be reliably used for agent IP collection. This makes it difficult to capture (even assuming the users of the HUD want you to have this information, and aren't taking security precautions to prevent it).

What you probably want is covered by llGetOwner/llGetOwnerKey? Each user in SL has a unique UUID, like a fingerprint. You can pass this in your llHTTPRequest using a Querystring (after obtaining it via llGetOwner() or llGetOwnerKey(id), depending on vector), and avoid the IP addressing system altogether.

--

The llHTTPRequest / llRequestURL data looks like this when it is received by a server (copied from server logs and obfuscated):

0.0.0.0 GET /file.php?qs=value 80 - 1.1.1.1 HTTP/1.0 Second+Life+LSL/13.03.22.272563+(http://secondlife.com) - - 200

 

Where 0.0.0.0 is the destination server and 1.1.1.1 is the simulator where the script is located. As you can tell, it does not contain any users IP address.

[Cerise Sorbet]

llHTTPRequest sends some useful extra headers to the server. X-Secondlife-Owner-Key and X-Secondlife-Owner-Name should be helpful in your case, since for HUDs the owner and user will be the same.

It's still good to examine the incoming address, not so much to try to identify the user, but to make sure the request is coming from inside SL.

Incoming URLs can be a pain to use with attachments, because they expire when the avatar moves to another region. You might find it easier to start transactions from the SL side.

[Gregory McLeod]

Thanks again for the reply.

The problem is caused by some avatars using alts! If an avatar has an alternative user name they will also have an alternative OwnerKey. So we cannot distinguish between two avatars both being driven by one person.

The object of my trying to understand the HTTP process (apart from learning about it) is to verify whether the suggested use of IP address would enable two avatars to be distinguished.

Now two avatars (one an alt) would not be distinguishable from one another using IP addresses as discussed above, but an interaction with a website should be able to do it. I am getting a little of topic here but the problem is trying to be completely sure that if the IP method does not do it, the method I propose is competely secure.

[Freya Mokusei]

---

Gregory McLeod wrote:

The problem is caused by some avatars using alts! If an avatar has an alternative user name they will also have an alternative OwnerKey. So we cannot distinguish between two avatars both being driven by one person.

---

I had a feeling you'd say something like this.

There is no way in SL to prevent abuse by alts. Using IP address will only discriminate against genuine humans, as anyone operating alts for nefarious purposes will typically know how to circumvent any detection method you can employ.

This is by design according to both Second Life and HTTP as a communications protocol.

It is trivial to change your IP address for an alt, making it appear different (when actually it's not). It is not a good indicator of unique human, and never will be. Further, alternate accounts have a semi-protected status in SL; there are rules for just how you can communicate that you believe an account is an alt.

Good luck, unfortunately with this concept I feel you are playing a negative-sum game.

[Darkie Minotaur]

It seems you've missed the upheaval RedZone and other tools like it have caused - you're on thin ice here (search the archive ans you'll know what I mean).

Freya has alredy summed up the chances of detecting alts reliably based on IP addresses - although I don't think that someone has ever seriously tried that - it requires a lot more than just IP addresses, and then it would still be no proof of alts.

[Cerise Sorbet]

You could do game registration outside SL, using your own web site. Use whatever means you like there to decide that each account belongs to a unique person. On your web site, you can generate a single use passkey of some kind. Ask the user to login to SL, and then using the HUD or perhaps some scripted inworld terminal, and paste that code into chat or an llTextBox. The scripted inworld object can relay this to your web server and if the code matches, you can mark that avatar association as successful.

This takes SL out of the loop for identifying unique people, and the process also helps ensure that the end user knows what you and they are doing.

[Qie Niangao]

I'm reading this completely differently.

---

The object of my trying to understand the HTTP process (apart from learning about it) is to verify whether the suggested use of IP address would enable two avatars to be distinguished.

Now two avatars (one an alt) would not be distinguishable from one another using IP addresses as discussed above, but an interaction with a website should be able to do it. I am getting a little of topic here but the problem is trying to be completely sure that if the IP method does not do it, the method I propose is competely secure.

---

As I understand it, the OP wants to treat alts as separate accounts and has no interest in discovering which accounts are alts of each other. The prospect of IP address collision is perceived as a problem, not a benefit.

There's a false premise underlying this, however: the IP address collisions wouldn't be from alt accounts, but rather from multiple avatars on the same sim, because the originating IP address will be that of the sim, not the viewer where some user happens to be connected to the sim at the moment.

In short, the IP address is completely irrelevant as an identifier for what's being attempted here. Instead, Cerise's earlier suggestion is exactly right: use the built-in headers that accompany traffic generated by llHTTPRequest(), and perhaps check the IP address only to confirm that the message (most likely) originates from within address ranges of the agni.lindenlab.com domain.

Of course, nothing is completely secure, especially using a server accessed through the Internet. It's at least theoretically possible to spoof both the IP address and the message format. (This is a lot harder--likely impossible, in fact--within the lindenlab network, so it may be more secure to use an in-world server in those limited cases for which that's viable.)

[Gregory McLeod]

Thanks to all who replied.

I will be a little more specific:-

The script that I am working on is part of a multi-player game which cannot cross sim boundaries.

The problem is that using an alt the original owner and their alt may collude to cheat the system.

The HUD MUST be worn to play the game and certain atrtributes must be adhered to or the HUD will detach itself.

The players must preregister with the website to be eligible to play the game wherever it is being played..

The game proper (not practice) requires the player to join a team Red or Blue.

Currently the joining is done through a prim just outside the field of play and it communicates with the website. This however causes a bottleneck in that all the players trying to use the Team joining script overloads the website and delays the starting of the game. I want to provide a means whereby the action of wearing the HUD will cause a registration event at the website and for the duration of the game will check the player's compliance by using somethiing that is unique to that player (a token perhaps).

It could go somethng like

1. Avatar wears HUD
2. HUD goes to website and checks the registration status
3. If registered it displays an offer to view a webpage.
4. The avatar accepts the offer and has a key value displayed which must be entered into the HUD prompting for it. 
5. Each different avatar gets a different key value and failure to enter it causes the HUD to detach.

Can anyone see any problems with that?

 

 

[Darkie Minotaur]

Maybe I'm just a little slow - but how would a player actually cheat using an alt?

[Curious Hazelnut]

---

Gregory McLeod wrote:

Thanks to all who replied.

I will be a little more specific:-

The script that I am working on is part of a multi-player game which cannot cross sim boundaries.

The problem is that using an alt the original owner and their alt may collude to cheat the system.

The HUD MUST be worn to play the game and certain atrtributes must be adhered to or the HUD will detach itself.

The players must preregister with the website to be eligible to play the game wherever it is being played..

The game proper (not practice) requires the player to join a team Red or Blue.

Currently the joining is done through a prim just outside the field of play and it communicates with the website. This however causes a bottleneck in that all the players trying to use the Team joining script overloads the website and delays the starting of the game. I want to provide a means whereby the action of wearing the HUD will cause a registration event at the website and for the duration of the game will check the player's compliance by using somethiing that is unique to that player (a token perhaps).

It could go somethng like

1. Avatar wears HUD
2. HUD goes to website and checks the registration status
3. If registered it displays an offer to view a webpage.
4. The avatar accepts the offer and has a key value displayed which must be entered into the HUD prompting for it. 
5. Each different avatar gets a different key value and failure to enter it causes the HUD to detach.

Can anyone see any problems with that?

 

 

---

I don't see how  your 5 steps prevents someone from having two avatars in the game at the same time. Each avatar would have to register separately but that is easier than getting two avatars in-world at the same time.

[Miranda Umino]

Requests inside objects from llHTTPRequest will fill the IP of of the sim where is the the prim .

Not the IP of the avatar who wears it .   In this case , your object is a client

 

If your object hosts an URL via llRequestURL , this URL is unique .( I mean :  two avatars wearing one object : the URLs of the objects will have two different URLS )

 In this case , your object is a server

 

By the way , i don t understand where is the "cheat"  and you do a so complicated process .

In fact , you even don t need to have a webserver. 

And you don t need to make your object servers with llRequestURLs , because your objects are already unique. 

And why this pre-registration on your website ? What is the goal of this pre-registration ? A player won t like a complicated process just to be able to play some minutes

And even if you wanted to register some scores in a website , the key of the object is enough , no ? ( llGetKey ) 

Can your object be modified by the users ?

Can your objects be transfered to alts ?

If it can , why not use llGenerateKey to create an unique UUID ?Or why not to use llAttactToAvatarTemp  ?

You didn t tell how an alt in normal situation can cheat your game 

 

 

[Gregory McLeod]

#Darkie

I am not exactly clear myself how it can be done, but then I would never try to cheat so don't think the way some people do.

I just take instructions from the Game owner to implement the scripts.

I give you an example:-  if I and my Alt were playing a game which relied on passing a ball. I could know which way my alt was going to go and so be able to pass in their direction.

============

#Curious

I don't understand your point about being easier to get two avatars in world at the same time I do it frequently.

============

#Miranda

I refer you to the example above in answer to one of your points.

I understand the need to release the URL when the game is finished.

The Games last for many minutes sometimes 2 hours.

The scores are captured by another prim near the field, in fact it detects the events that are scored.

None of the objects used in the game including the HUD are modifiable, copyiable or transferable by the player, all the scripts are secured and cannot be viewed.

===============

Thanks to you all for responding.

 

[Darkie Minotaur]

Thanks for the example.

This situation would indeed be a case where you need alt detection. Alt detection can - as far as I see - technically omly be approached by detecting if two avas are on the same machine (physically or virtually). The IP address is one important indicator for that - though not the only one. The IP address alone is, however, not a death proof instrument.

To prevent confusuion: I'm talking about the client IP address - not the sim IP address that you get by looking at the HTTP headers sent by LSL HTTP communication. The client IP address is the IP address of the client the user is using. There is no way to detect the client IP address from inside SL. There are ways of trying to get these IP adresses by using IP connections that come from the client machine directly - usually using prim or parcel media or parcel music. I guess that's similar to what you had in mind when you where talking about using a website to give out a token.

But this would also rule out persons that are located behind the same IAD (at least in most cases), since all of the clients run e.g. behind the same router have the same public IP address. You would have to use other mechanisms - there are some out there - that collects and evaluates further infoirmation about the client.

Depending on what exactly you plan to do, there may be other glitches as well.

[Freya Mokusei]

---

Gregory McLeod wrote:

It could go somethng like

1. Avatar wears HUD
2. HUD goes to website and checks the registration status
3. If registered it displays an offer to view a webpage.
4. The avatar accepts the offer and has a key value displayed which must be entered into the HUD prompting for it. 
5. Each different avatar gets a different key value and failure to enter it causes the HUD to detach.

Can anyone see any problems with that?

 

---

As Darkie says, this design will still be limiting against genuine humans. Steps 4 and 5 also seem unnecessary, since you could have the server signal to the HUD that the user was now ready to play (and this would enable the HUD), rather than forcing the user to carry out a manual command (which would create another bottleneck).

It is still very easy for an alt to have a different IP address to the main account; it is a method so simple that anyone looking to cheat would likely be able to accomplish it quickly. One system for alt detection used cookies distributed by visiting the webpage; however these come under conditions of their own, and can be defeated in a similar way. Using both cookies and IP adddress would help avoid discriminating against two humans sharing a DSL/cable line, since the cookie is stored on each PC (if the cookie isn't what you're expecting, you can be sure that you're dealing with a different PC or cookie-handler, which typically implies a different human (but will not guarantee it).

Another strategy would be to handle alt detection yourself. You could create and test mechanisms that require precise timing, or quick keystrokes, or memorised strings. They could be tested in parallel with other players (say, they have 10 seconds to both key in different keystrokes), so that a single human couldn't possibly complete both tasks in time or with the required precision. This has the advantage of not running near any rules laid down by LL.

You're probably going to have to get very good at cheating if you want to test your system accurately; virtuousness does not accomplish security. It is doubtful you will accomplish something completely secure (such is the nature of limited authority, online development), but you can 'raise the bar' to make it harder to cheat.

[Qie Niangao]

---

I am not exactly clear myself how it can be done, but then I would never try to cheat so don't think the way some people do.

I just take instructions from the Game owner to implement the scripts.

I give you an example:-  if I and my Alt were playing a game which relied on passing a ball. I could know which way my alt was going to go and so be able to pass in their direction.

---

This alt-detection thing would be a Very Bad Idea even if it were possible, and even if it actually mattered to game play.

• It's a bad idea because the more, uh, "dramatic" of SL users are forever guessing each other's alts, sometimes guessing right, then much hilarity ensues as the victim tries to figure out how they were outted. If there's even a hint that this game can detect alts, it will become a grid-wide pariah, suspected of leaking that information a la RedZone in its infamous prime.
• It's not possible for all the reasons given, and more. Even if you got the end-user's session IP address (there are ways, but not through LSL's http-in / -out), it's ridiculously easy to get different IP addresses for multiple sessions (much easier than matching the IP address of somebody else's connection). And anything you measure--even biometrics--can be easily masked, and will be if the stakes are high enough and if it's known what's being measured.
• Such collusion seems unlikely to matter much anyway. Can alts really collude more effectively than team members with an out-of-band Skype connection? Maybe so, if the game is so real time that alt clients controlled by a single program had an advantage through synchronization at the millisecond level, but such a game would be horrid in SL lag, with or without collusion.

I'd also reiterate Miranda's observation: There's nothing here to recommend using an external server for game play. If there must be an external server for some other reason, it would be wise to keep it as far removed from the "main loop" of game operation as possible. It will be subject to sporadic communication delays and failures, and become the most vulnerable and least scalable part of the system. If it's not absolutely necessary to interpose an external server in game initiation, giving it that role will hurt availability. If a game session spanned sims, an external server might be worth all the risks, but as that's not the case, I'd relegate it to optional bookkeeping tasks and maybe one-time game setup registration.