[sldev] Patch to Address Debit Permission Spoofing

[Erik Anderson]

A malicious vendor could give objects away for free, but it doesn't exactly
need REFUND permission to do so, it could just spam every avatar that came
within range.

The idea of creating a REFUND permission (or otherwise getting as many
objects away from DEBIT as possible) means that we can create a red blinky
permission box and actually have it have meaning.  Something to stop and
read that is more than just red tape to putting up something that people pay
money to.  Otherwise we'll have a red blinky permission box that people will
be more likely to blindly dismiss, since a dozen of their objects need it
anyhow.

FWIW I created this issue as SVC-232.  And I am still for this modified
viewer box, which I seem to again have kidnapped the thread from.

On 5/25/07, Able Whitman <able.whitman at gmail.com> wrote:
>
> 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/d3e94035/attachment.htm