Major security flaw with affiliate vendors?

So, I was reading about llGiveMoney and I see there is a throttling that takes place where it basically suspends the ability for a llGiveMoney to work if you have had more then 30 give money requests in 30 seconds.

So, here's a scenario:

I setup an affiliate vendor. It asks me for debit permissions - I say yes.

I then run a script that send a dollar to myself every second. I essentially throttle all llGiveMoneys while the script is running.

Someone buys something from my affiliate vendor. I get the money. The affiliate vendor then attempts an llGiveMoney to pay the main vendor. Since llGiveMoney is throttled, I assume nothing happens and the script has no way of knowing money didn't get paid. The affiliate vendor then continues processing and sends the item to the person who bought it. Net result, I ended up keeping the entire purchase price of the item.

Am I missing something? Do affiliate vendors have some sneaky way of knowing if they ever actually got the money they were supposed to before sending the item?

Hmm. Well, hopefully the throttling simply suspends the script for a short period during the call rather than making the transaction fail altogether, but I really don't know (I wouldn't exactly put it past LL to fail such a call though :-/). It might also be a good idea to check whether the throttling is based on a per user, per object, or per script basis.

http://wiki.secondlife.com/wiki/LlGiveMoney

Use is limited to 30 payments in a 30 second interval for each resident on a region.
Sustained overage will produce a script error and halt payments while the rate remains excessive. Historically, faster payments have failed intermittently.

Affiliate vendor may have other communication channels to check for purchases, who bought what, when, where, and make surplus payments based on that on a time that may not be worth spamming untill, to begin with.

purchase history makes fraud visible.

Well I tested this with two objects. One that spammed a payment to me every second. The other that I can touch to pay me 100 lindens. Once the spammer was running, the second object would be unable to pay me. So, it does cross scripts and objects.

It does strike me as an easy way to end up owning every item in SL that is sold via a commission vendor. They are generally free - just get one, set it up, run a money spammer, then buy all the items from yourself. Then, kill the vendor.

And I am somewhat curious if this would even be against the TOS. Does LL get involved in inter party disputes like this one?

It is an exploit of the system's design, so I'm fairly sure it would be against the TOS.

Most well scripted commission based vendor systems don't allow you to get your own discount. in other words, buying from your own vendor either isn't allowed, or charges you the full price. But as others have stated, it leaves a paper trail and you will get caught and blacklisted by the owner of the vendor.

However, this is one reason I won't do affiliate vendors with my products. They are susceptible to fraud.

Most of the very well scripted affiliate systems will check the transaction history webpage, and email the creator when you try to steal somthing this way. I know my system does this and I know other ones do too.

My vending machines will NOT deliver the product to the customer if the dealer has not passed on the payment to the creater. Instead of delivering a product it will send an IM to the customer telling them that the vending machine they have used is faulty and they need to contact the owner to get a refund. This means that not only the creaters will be filing abuse reports against the bad dealer, the customers will be too!

If you use an exploit like this you will get caught, reported, and banned.

Darling Brody.

The transaction history webpage for the affiliate system involved you mean? i.e. not the transaction history page on Second Life's website?

If so I don't think it would catch it. You'd be using your own object/script to max out the total payments limit for a given avatar on a given sim and the vendor system would be none the wiser. Then the scammer uses an alt to purchase from their vendor and it'll be unable to send funds to the product creator.

Oh, if you mean the creator of the affiliate system itself are getting a cut too (so split three ways) on every purchase then I could see how the creator of the affiliate system could have a custom in-house setup for checking their own Second Life transaction history. They could detect this fraud that way (assuming it's quick enough and no website caching issues!). Or they could have custom client software which is always logged in and logs transactions immediately to their own affiliate system. I don't know what they're doing so just speculating.

I'd be surprised if they're checking the transaction history of the product creator though using Second Life's website, if that's what you meant. Which is what would be needed I think. Just checking the affiliate system's own logs would be useless with this exploit from what I can see. Unless I missed a built in way of doing this, wouldn't it also require the account username/password to be given to the affiliate script for it to log into the secondlife.com website on the product creator's behalf? I could never see that happening.

PS: I'd be surprised if this really is an exploit because it's such an obvious thing. Could the Lindens really be this careless? I suspect there's many ways to prevent it. For example if a sim detects that an avatar have hit their payments cap it just rejects all payments made into any of their objects, and obviously the money event is never raised in the script.

You're joking!

We could really use a transfer ID that comes back and says whether the transaction succeeded. Clients get a transfer success/fail response, why not scripts?

Yeah, it would be really cool if llGiveMoney() would return a request ID key, which would kick a dataserver() event upon success OR failure of the transaction.

The only way I can think of around this is to have the affiliate vendor pay the money to a bot account. When the bot gets the money, it accesses a web site to say that the sale is approved, and the vendor can then check for this to actually dispense the product. It involves hosting problems, though..

There is another way (that does NOT require any kind of hack or custom client). You have the affiliates prepay for the amount of product they want to sell. An affiliate vendor deposits into a credit account (either manually to the main supplier or through the supplier's objects) and then slowly reduces the credit as end customers are shipped product.

For example, if I want to setup vendors for a supplier named John Example, and the payment share that John gets for each Product A is L$40, and the share that John gets for Product B is L$30, I can pay John's credit terminal L$1200, and then the vendors I setup will take off L$40 of credit for each Product A they have shipped to customers, and L$30 for each Product B they have shipped. At any time I can pay more L$ into my credit account with John in order to enable more product purchases.

This reverses the trust issue: each affiliate must trust the supplier--which is required anyway with this type of system. The supplier doesn't need to trust the vendors at all, because--well, (s)he already has their money. But the great thing is that each vendor gets to decide how MUCH they want to trust the supplier, and can manage their risk actively over time as they see how well the supplier does business and how much volume they need.