Difference between revisions of "LlRequestPermissions(llGetOwner(), PERMISSION REFUND);"

From Second Life Wiki
Jump to navigation Jump to search
m
m
 
Line 7: Line 7:
For an illustration of the problems we currently have with DEBIT_PERMISSION, here are possible fraud scenarios:
For an illustration of the problems we currently have with DEBIT_PERMISSION, here are possible fraud scenarios:


Disguised-request-debit
Disguised-request-debit fraud


* Create an object for which it makes sense that it needs DEBIT permission, a slots machine, sploderball or vendor machine will do
* Create an object for which it makes sense that it needs DEBIT permission, a slots machine, sploderball or vendor machine will do

Latest revision as of 10:36, 12 June 2007

Currently, any script that processes payment TO an avatar needs DEBIT permission to be able to refund the paying avatar if the amount payed was incorrect or something else went wrong. Apart from the problem that PERMISSION_DEBIT is currently limitless, meaning a vendor processing L$ 10 payments needs permission to llGiveMoney(to_some_avatar, unlimited_amount), there is also conceptually a big difference between REFUNDING money or GIVING money. I don't think a function llRefundMoney is needed, but it would be very good if the difference could be expressed in permissions. You could consider changing the color of the dialog box for request DEBIT permission from blue to red (after all, it's abuse sensitive.. blue can be a bit misleading). You could then have a yellow box for request REFUND permission. You would then restrict llGiveMoney, when called under REFUND permission, to a) Only be called from within a money event context b) Limit the amount given to the amount received in the money event.

Furthermore I suggest you add a 'budget' parameter to DEBIT permission, so any scripts that need to give money at will to operate can be restricted in their money-giving abilities.

For an illustration of the problems we currently have with DEBIT_PERMISSION, here are possible fraud scenarios:

Disguised-request-debit fraud

  • Create an object for which it makes sense that it needs DEBIT permission, a slots machine, sploderball or vendor machine will do
  • Create an algorithm to steal as much money as possible and let it run periodically

Users will give the DEBIT permission because it is expected that the object will ask for it. We need to have a budget parameter here so the dialog can say: .. wants to: Take a maximum of L$ 25 from you. Is this ok?

Request-debit-on-payment fraud

  • Create a nice looking object that says: "Freebie: L$ 0"
  • Do not set it 'For Sale', but instead llSetPayPrice(0, [DEFAULT,HIDDEN,HIDDEN,HIDDEN]);
  • Create a money event and llSetPayText("Buy");
  • Inside the money event, do a llRequestPermissions(id, [PERMISSION_DEBIT]);

The user will see:

  • An object marked "Freebie: L$ 0"
  • Upon rightclick, a pie menu item marked "Buy"
  • Upon selection of the menu item, a dialog that says "Pay L$ to object "Freebie" owned by OddesE Oh?" with button "L$ 0"
  • Upon payment, another dialog that says "Object "Freebie" owned by OddesE Oh wants to: Take L$ from you. Is this ok?" with buttons "Yes" and "No".

How many users do you trust with your money and this series of events?