[sldev] Patch to Address Debit Permission Spoofing

[Able Whitman]

The problem is that once an object has taken your money, it's too late.
There is very likely no remedy to be had after-the-fact. LL has stated (not
unreasonably) that their refunding of L$ taken fraudulently is contingent on
their ability: a) to  have evidence to suggest that it was in fact taken
fraudulently and who took it, and b) to recover the money from whoever took
it.

Of course, as others have pointed out, malicious scripts are rare. But the
need to grant an object the debit permission is also rare, or at least it is
uncommon. And once granted it is difficult to both revoke the permission and
to seek remedy for fraudulent debits.

Having SLURLs on the transaction history would be extrememly helpful. So
would having something a refund permission. All I'm trying to do with this
patch is raise the visibility of prompts for the debit permission, so users
have a little more information about the implications of granting it.

--Able

On 5/30/07, Chance Unknown <chance at kalacia.com> wrote:
>
> At what point can we get a SURL on the accounting transaction web page
> (including those that fail)? That way we can go delete items that are
> persistent that make debits -- which have been lost to the world -- for
> whatever reason? Then the rest of this conversation basically becomes
> academic. I am capable to empty my account to L$0 and monitor for failed
> transactions.
>
> This is outside the scope of viewer related issues to color code or
> clarify UI on what is ABOUT to happen. I would like remedy for something
> that has ALREADY occured... Focus on the ability and tools to available to
> customers to remedy issues that come about, and document that.
>
> ---
>
>
> On 5/30/07, Tateru Nino <tateru.nino at gmail.com> wrote:
> >
> >
> >
> > Alissa Sabre wrote:
> > > As a non-fluent English speaker, I'd like to say something here.
> > >
> > >
> > >> An object wants to be allowed to take money (L$) from your account.
> > >>
> > >
> > > Hmm.  This "wants to be allowed to take" looks complecated and not
> > > easy to understand...  I'm also afraid that translators of this text
> > > (to publish French, German, Spanish, Japanese, Korean, ... versions of
> > > the viewer messages) may be confused.
> > >
> > > Why can't we say more straight?  For example,
> > >
> > >    An object is taking money (L$) from your accout.
> > >
> > Because it isn't. It's actually asking permission to take money from you
> > at some future point in time, or at any future point in time that it
> > wants to. It's not taking money from your account at the time that the
> > question is asked.
> > > And from a translation point of view,
> > >
> > >
> > >> [Grant permission to debit] [Deny permission to debit]
> > >>
> > >
> > > Long button label is always a headache of translators.  Depending on
> > > the target language and vocabulary, the translated text could be far
> > > longer, and simply didn't fit in a button.
> > >
> > > My suggestion here is to use short (and somewhat ambiguous) button
> > > text with clear explanation near the button.  For example:
> > >
> > >     yada yada
> > >     -------------------
> > >       Grant: To grant permission to debit the money indicated above.
> > >     [Grant] [No]
> >
> > How about:
> > This object wants access to your L$ account
> >
> > [FOREVER][NO!]
> >
> > --
> > Tateru Nino
> > http://dwellonit.blogspot.com/
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> >
>
>
> _______________________________________________
> 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/20070530/5cedbc57/attachment.htm