[sldev] Patch to Address Debit Permission Spoofing

[Able Whitman]

I very much like the idea of a refund mechanism, especially if:
* it only works within the money() event, and
* it can, at most, perform transactions that deduct money from a user's
account such that their ending balance is unchanged from their beginning
balance

I think that this kind of bounded transactional permission would cover 80%
of the existing cases where the PERMISSION_DEBIT is currently being used.

This would go a long way to making vendors more trustworthy. I do think that
along with the refund mechanism, there should be an associated
PERMISSION_REFUND that requires the same kind of explicit acknowledgement
that PERMISSION_DEBIT requires. It is important that a user be explicitly
informed when a script or object has the ability to affect their L$ balance,
regardless of whether the extent to which they can debit money is bounded.
After all, if SL requires explicit permission for an object to animate an
avatar, refunding money should require at least the same.

A PERMISSION_REFUND still doesn't solve the problem that this patch is
intended to help mitigate. Malicious scripts that use PERMISSION_DEBIT would
still be able to steal money from a user's account. And in fact, a
PERMISSION_REFUND would still enable a maliciously-written vendor script to
give away items for free.

I very much like the idea of a refund permission to help mitigate L$ loss to
malicious (or just poorly-written) scripts. If such a permission were
implemented, though, I still think that a refund permission should receive
the same additional visual emphasis as the existing debit permission.

--Able

On 5/25/07, Kelly Washington <kelly at lindenlab.com> wrote:
>
> Erik Anderson wrote:
> > Is there any way we can ask LL to provide two permission tiers here?
> > Considering that a significant chunk of L$-authorized objects are
> > probably vendor scripts of which you are not the owner, having those
> > objects use a lesser "refund-only" permission could help seperate out
> > the potentially dangerous scripts from the ones that can only give up
> > to the amount of money that they have themselves been given...
> >
> > And yes, I probably should have looked at Jira before posting this...
> >
> Unfortunately there are currently no transaction mechanisms in LSL.
> Vendors work in an asynchronous manner - they collect money and then
> they give items.  Or they collect money and do something else.  This
> makes a refund permission a little more difficult, although I suppose a
> new function llRefund() that only worked inside the money() event could
> make sense.  It is possible this may not help some of the more
> complicated systems, but is probably the best middle ground.
>
> Should a permission even be required for llRefund()?  No permission is
> required for money() events, and the only "trick" would be to ensure
> that refund() can't be called multiple times or is a noop when called
> after the first time.
>
> I actually do like this idea.
>
> - Kelly
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070525/463bd67d/attachment.htm