Potential for vendor abuse

I'm creating a network vending system that consists of an in-world object that acts as the server and a bunch of associated vendors. The server contains all the items to be sold in one central location. The vendors will usually be owned and operated by someone different from the server owner. The idea is that people could sell items belonging to someone else.

The buyer pays for the item via the usual "Pay" function generating a money event. At that point the vendor owner has the money. The vendor goes into a special state to process the transaction and to prevent any further activity on the vendor. It sends an email to the server asking it to give out the item to the buyer. The server sends back an email to the vendor with one of three messages: the inventory was given, the inventory was missing from the server (because the owner changed something) or the server is offline. All pretty standard stuff.

Here's the glitch. After the vendor receives the email that the item was delivered, it must distribute the money collected to different people, one of whom is the server owner whose item is being sold. I've been able to trap most potentials for abuse (that I'm aware of) except one . Although the email handshaking goes fairly quickly, it still takes a few seconds to complete in most cases. If the vendor owner were to de-rez the vendor before distribution of the money, he would get to keep all the money.

If the vendor were later re-rezzed, even in the same state, it would have gotten a new UUID, so the email sent back by the server will be lost. I can't see a way to prevent this from happening. My current thought is to trap the vendor in that state, so that it becomes useless or perhaps IM'ing the server owner that there was an incomplete transaction. But these are deterrents at best. What's to keep the person from just getting another vendor and doing it again? The vendors will be free and easily obtainable.

Perhaps with a complicated web based database that gives me more room to hold data, I could track this better, but doing so with a totally in-world system is difficult at best.

I'd be interested in hearing in-world suggestions on how to prevent this type of abuse. Is there something I'm missing here?

Couldn't you have it e-mail the server when the money transaction is complete, whereby the server knows who owns this server, and if it never gets a "Money has been split accordingly" or whatever message from the vender, it thereby deactivates that vendor owner from ever using the service again unless they contact the server owner with an explanation? Could then have an interface that allows the server owner to browse this list and remove people if they wish.

... or, maybe, the server doesn't even distribute the purchased item till it gets the "money has been split accordingly" message from the vendor. There'd need to be an extra step in the protocol, because before the vendor actually splits the money, it would want to make sure the inventory can be delivered--otherwise refunding to the customer for something out-of-stock would require that either the vendor's or the server's owner cover the whole amount even though the L$s were already split, until accounts were reconciled manually. And that problem would arise anyway if the server ever became unavailable before it could deliver the goods to the customer.

(Incidentally something like this would seem to require that the protocol not be subject to spoofing; by encryption or some reliable means, the server needs to know that the messages it gets are really from a vendor, and not something scripted to look like a vendor.)

Tiarnalalon: I was thinking of something like that. I would need to find a way to store the UUID's of all the delinquent vendor owners. That raises the whole persistent data storage issue. As long as there aren't too many delinquents, it may be manageable either via a helper script that won't reset or the description field. My main script is pretty maxed out.

Qie: Holding off on distribution won't solve the fundamental problem. The vendor owner failing to distribute the money is the real issue I'm struggling with. And yes, I've got the encryptions, validation and replay attack bases covered as well as several others.

The more I've been thinking about this, the more I think the solution is to not leave the money with the vendor at all. Immediately pay the server owner the whole amount that was collected and let the server distribute the money. There is far less potential for problems and abuse that way. The only problem I can see is if the server was taken out of world or if its sim was down. The sim being down is transient and can be caught up with when it returns on line. The problem of the server being de-rezzed can be minimized by having the vendor check in with the server on a regular basis and having the vendor deactivate itself if the server doesn't reply. Of course. de-rezzing the server in this model totally trashes the system since it loses its UUID and immediately orphans all vendors associated with it. The server owner would not likely be doing that. If a transaction occurred in the brief time since the vendor last checked in, the server owner would have to be contacted for a manual refund.

Any thoughts or comments?

I know exactly how to sort your system out.. Unfortunately Ive signed a disclosure so I cant tell you >.> ..... How ever.... I can hint! Look at another communication method... Something that "can" transmit in less than a fraction of a second!

It will make your system more complex but safer and will cause less latency. Im sorry this is all the help I can give!

xml-rpc is your key.
And an external database.

Right, but the idea was that the vendor owner wouldn't be able to get away with not distributing the money, because if the vendor doesn't distribute the money, the customer doesn't get the goods they paid for, so the customer is gonna complain to the vendor owner--about which the server owner need not concern herself.

But off the top of my head, I don't see anything wrong with making the server responsible for splitting the proceeds. Somehow it's always just seemed more secure to have both wrong-amount refunds and splitting happen right within the money() event, but maybe that's just superstitious, given that everything is staked on the security of the vendor-server protocol anyway.

As for other methods: If it isn't a hard-and-fast requirement to keep the comms in-world only, then indeed, most new networked vendors use XML-RPC and an external host. The basics aren't that complicated--the differentiators are all in what kind of data manipulation (e.g., marketing analysis) is supported on the external host. A recent post may be of interest (but lots more in this forum, too).

Of course, this doesn't even touch on the possibility that the vendor owner has a scripted item which is constantly trying to pay out some fixed small amount of Linden$ to an alt account as fast as it can. llGiveMoney fails silently (to all but the owner) if the owner doesn't have enough. Basically, what happens with this kind of system is it operates just fine as far as everyone is concerned, except that the owner of the vendor keeps the majority of the money paid into his account by the customers, and the network receives very little (if any). He then claims that it was your vendor network that lost the money, since he "doesn't have it".

Yes, I've been down this path a few times in my vendor system designs...

Unfortunately, there is no technical workaround for it, which is why you don't see more of these kinds of vendors. JEVN used to have a vendor system like this, where you could act as a traveling salesman, rezzing vendors at customers' sites, and trying to sell them on products. It saw some limited use, but because it was prone to abuse, it never really caught on. You basically have to have some kind of trust system in-place, or maybe take deposits (or charge some kind of "loss tax" from potential vendor owners to cover losses from the unscrupulous ones.

Yeah I realize that an external DB is the key to an overall better system. I'm just not there yet though. I know nothing of PHP & MySQL or xml-rpc so I have a steep learning curve ahead of me. I'm just trying to prototype the concept at this point. I do plan to move in that direction though.

However it seems to me that even with an external system, if the vendor holds the money, it seems like there would still be a lag where there is potential for abuse with a "take the money and run" scam.

falney: the vendor and the server will likely be in different sims. I don't know of any other type of inter-object communication besides email that is instantaneous and can communicate across sims. Maybe someone can enlighten me.

Qie: If I understand your model correctly, the vendor takes the L$ & checks with the server that it is still on line and still has the item. The server gives the ok to the vendor to distribute the L$. The vendor in turn tells the server to go ahead and distribute the item. If that is the case, there is still the lag in that first step during which time the vendor has the money and the owner could de-rez the vendor. The buyer is just left with the option of filing an abuse report on the unsrupulous thief. Without the first check that the server can deliver, it seems to have the potential of getting messy with the need for many manual refunds by the server owner.

Talarus: It seems that moving the L$ immediately to the server would minimize or almost eliminate what you're talking about. Also with IM notifications to all parties coming from the server, everyone would be able to know if they didn't get what they were expecting.

I also like the idea suggested earlier by Tiarnalalon of a ban list. It would be nice to be able to keep unwanted vendor owners from using the system. Of course, that doesn't prevent someone from creating an army of alts. In my experience though, thieves are basically lazy people and stop if the scheme takes too much work.

You cannot depend on in-game functions to handle this robustly; if you try, it will fail no matter how clever you are.

Indeed, the learning curve is steep, but sometimes a "good-enough" solution isn't, especially when money is involved.

Well, here's the rub:

Let's say that I have a scam object in a relatively empty class V sim running this script:

default {
state_entry() {
llSetTimerEvent(0.01);
}
timer() {
llGiveMoney(altaccountkey,100); // the amount doesn't really matter, as long as it is not greater than the minimum item price in the vendor
}
}

Your vendor would do something like this in its money() event:

money(key pkBuyer, integer piAmount) {
integer liRefund;

liRefund = piAmount - giPrice;
if (liRefund >= 0) { // paid enough
llGiveMoney(networkaccountkey,giPrice); // transfer the money to the network account, pronto!
// complete the rest of the purchase sequence
} else
liRefund = piAmount; // didn't pay enough, refund it all
if (liRefund > 0)
llGiveMoney(pkBuyer,liRefund);
}

Let's say that I put the vendor in a particularly laggy, yet popular sim. The way the purchasing goes, the money event is triggered some time AFTER the money has actually been transferred to the owner's account in the accounting server's database. By the time the vendor script gets to the llGiveMoney() call to the network account in the money() event, at least one or more L$100 deductions from the scam object in the fast sim will have occurred, and the owner's account, being empty outside of the money for the latest purchase, won't have enough to pay and the call will fail, silently. Most people will pay the correct amount, so the underage/overage situation failing won't happen often.

Quite a number of sales could happen before your account auditing catches up with the fraud being committed, and may continue to do so while you investigate until you disable the owner's vendors. Since you can't reconcile payments via scripts (there is no way to llGiveMoney to an object, only an avatar, and the money() event only fires because an avatar paid it), there's just simply no good way to do this kind of system to prevent fraud; at least, on a technical level.

It's not that steep. I switched from e-mail to http/Apache/PHP/MySQL/XML-RPC over a year ago, and learning it all took me maybe a month. And I'm not all that bright =^.^=

Hmm... if I wanted to defraud someone, what's to stop me from making something that looks like a vendor in your system, takes money from customers and then gives them an error message as if the transaction fails as if it was your servers fault? No matter how good your system is, it can still be spoofed.

Personally, I would make the security "pretty good" meaning, that if both the vendor owner and the server owner are acting in good faith to keep the objects rezzed, it works securely and accurately. I would also ensure that there is a way for the server owner to ban vendors owned by fraudulent vendors. After that, it's simply a matter of trust between the parties.

If I understand Talarus correctly, any system whether in-world or web based, is open to this type of attack as long as the vendor owner who first gets the money is different from the owner of the items being sold in the server.

I tend to agree with Keiki though. There are few if any systems, even in RL, that are totally fraud proof. Any vendor, network system or stand alone, can give the appearance of selling something, take your money and fail to deliver. I guess that's what abuse reports are for. Any transaction involves a certain amount of trust. As Talarus points out earlier, the only thing you can do is your best at minimizing risk and expect and insure yourself against the theft and fraud that will occur.

Since the server owner has the most motivation to stay honest, I still think it's best to move the money to him ASAP and let the server do the distribution. A way to ban abusers is necessary. Developing a trusted salesforce that has to sign up to get a vendor and agree to terms may help. A system of transaction notifications that lets all parties know what they should be getting should also help keep everyone honest.

Well, I got to start reading that PHP-MySQL book I just bought. Interesting discussion folks.

Talarus,
Out of curiosity how many scammers have you come across employing the constant withdrawal trick. I just recently created a Web/PHP/SQL based affiliate system (beta testing it now) with a crazy amount of code dedicated to glitch (aka SL) detection and recovery but when I read this thread I too seemed to have missed this potential for abuse, thanks for the heads up. My payment receipt and commission split happens almost immediately but lag can definitely shift the advantage to the scammer.

As far as I can tell sales correlation with SL account transactions (credits) is probably the only way to flag this form of abuse. (I do have the ban button built in)

Im just curious how often this attempt will surface. sounds like you had a few run-ins with it already.


Monica,
De-rezzing a vendor in the middle of the payment transaction is probably a more tedious approach for a scammer to scam with and would probably be rare.

I would definitely go with a web based database vendor system for an affiliate vendor, which it looks like you are, just ready yourself for lots and lots of code. I totally underestimated the magnitude of the project when i began, but its a good learning experience.

Oh... remember... too many RPC calls the SL handler in a short period of time can cause it to ignore future requests. Had a loop get the better of me to find this one out.

-Phid