[sldev] Re: Patch to Address Debit Permission Spoofing

[Able Whitman]

You're correct, it was my mistaken understanding that a non-owner could
grant an object debit permission. This is definitely not the case.

However, there still remains a security concern around the debit permission.
Yes, you must explicitly click "Yes" on a permissions prompt to grant this
permission, but:

* There have been malicious object that masquerade as relatively innocuous
objects (like a dance animation overrider, for example). These objects ask
for animation permission AND debit permission, and users who are accustomed
to clicking "yes" for animation overriders can and will do so in the case of
a malicious script which then steals money from them.

* There have been malicious scripts that make many single permission
requests very quickly in a row, often in an attempt to "hide" a request for
the debit permission amidst a series of requests for harmless permissions.
This results in a pile of stacked permissions prompts, which makes it more
likely that a user will quickly click though and accept all of them, without
examining each prompt th see what permissions it requests.

Simply swapping the position of the buttons on a prompt for debit permission
doesn't solve the problem. In fact, it makes it worse: If a user is
skeptical enough of an object to rather reflexively click through "no" on
all the permission prompts, swapping the buttons for debit prompts means
that it becomes likely that the user will accidental *grant* this
permission, when in fact their intent was precisely the opposite.

The fundamental problem is that, while the effects of the debit permission
unique in that they are potentially much more serious (financially) and are
irrevokable, the current permission dialog gives the debit permission no
more weight than the other permissions it can grant.

The changes I've made to the permissions prompt here are similar in
philosophy to, for example, IE7's behavior of preventing you from
automatically opening a https url when the server has an invalid
certificate. You can proceed, but not before going through a kind of
"roadblock" that clearly and unambiguously alerts the user that something
out of the ordinary is happening. Google takes a similar approach when they
block users from automatically following result links to sites that have
been identified as spreading malware. (These are only two well-known
examples, I am certainly not implying that my patch addresses an issue of
equal importance.)

Without better information about the choices they are given, users generally
make poor trust decisions. In the event of wrongly granting an object debit
permissions, the ramifications of a poor decision can be fairly devastating,
since the resulting loss of L$ (and the corresponding cost of those L$) is
not recoverable. Most users simply don't understand that when an object asks
for permission to "take linden dollars from you", this means "take linden
dollars from you without you being ever asked again in the future, and
without you being able to take away this permission in the future."

Helping communicate the real impact of the debit permission to users and
helping them make better decisions about the permission is what I am
attempting to do with this patch.

--Able


On 5/25/07, Chance Unknown <chance at kalacia.com> wrote:
>
> They can only take money from you once you authorize a prim to do it. Now
> it might be interesting to have a universal revoke feature implemented at
> the sims, but this wouldnt be a client side feature. And far as I can tell,
> only scripts which are under your ownership can successfuly request debit
> permission.
>
> The flilpping around the aurhorization buttons to make it harder to slip
> one in under the flurry of dialog boxes and trick someone to select OK on an
> item that they accept from you, to fool them to take their money is probably
> ok. But there is not a huge security concern like this thread implys. You
> must authorize a prim that you own to dip into your pocket and send money
> someplace.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070525/6819d492/attachment.htm