[sldev] RE: Re: Re: Patch to Address Debit Permission Spoofing

Kele Kravelin grazel.cosmo at gmail.com
Sat May 26 15:17:33 PDT 2007


Also debit permissions are used for raffle balls and sploders, not just
vendors. Sploders especially CANNOT work without debit permissions (and a
refund() event wouldn't help without tricky coding). I think the focus on
debit permission should be in how it's accepted/presented in the UI.

A combination of the following should be used:
- Color the box differently
- Place the box in a different location than the default popup (also wish
you could manually move the dialog boxes, hard to access some HUD items due
to them)
- Have a timer on enabling the dialog buttons for debit permissions (and
perhaps ALL dialog buttons to deal with the rapid popup overlay of dialogs)
- Have new dialog boxes appear underneath the existing boxes rather than on
top of them
- Even when requesting multiple permissions at once make them a seperate
dialog to accept each one (or at least debit permissions)
- The ability to revoke debit permission of an object (this would need a way
to track all in-world objects with debit permission) or all objects
- The ability to make debitg permissions an 'every time' permission so that
each time the script goes to give your L$ to someone you have to accept (and
auto-denies if you're offline) for those that want more fine control or are
paranoid (obviously not useful for sploder owners, but vendors could find
this useful).

Also keep in mind that with the changes to the quick pay button features the
need for vendors to have debit permissions has decreased since you can force
the user to only pay the correct amount (so unless you have some mechanism
to have a sale possibly fail there would be no need for an automated
refund). Vendors that split the money between the owner and another would
need debit permission so that the non-owner can get paid their share but
with a newer/well written vendor system this is really the only time debit
permissions should be needed for a vendor system.


On 5/26/07, Chance Unknown <chance at kalacia.com> wrote:
>
> you will never get people to RTFM. so your options on customer support are
> to : 1. provide it, or 2. not provide it. pretty simple really.
>
>
>
> On 5/25/07, Kamilion <kamilion at gmail.com> wrote:
> >
> > Hm. I run a single-database networked vendor that carries many
> > products from many people.
> > Already, 50% of the people that get my vendor IM me to ask 'why is
> > this asking for debit permissions' when it's clearly stated in:
> >
> > A: The documentation notecard that comes with it, at the very top, in
> > all caps, and repeated 3 times
> > B: When the vendor starts up, greets the new vendor owner, explains
> > itself, and asks for permissions
> >
> > And after all that, AND handing out the script module that actually
> > handles the money mod/copy/transfer, most of them tell me directly
> > that they don't trust my vendor with debit permissions.
> >
> > Plus, my vendor also emails my logs email account on my domain on
> > initial start up, which also records if the user accepted permissions
> > or not -- a full 75% of the new users of the vendor system do not
> > accept permissions... So in order to alter that, I had to adjust the
> > vendor to act as a catalog-only system when permissions haven't been
> > granted, and now I'm in the middle of writing a gift-certificate
> > system so the vendor is still a viable sales tool.
> > In order to attract anyone even using the system, I had to allow 10%
> > of every sale to stay with the vendor's owner (which means 90% of the
> > item cost is sent to the item's creator) just to stay afloat.
> >
> >
> > I support the red-colored dialog patch, but the autodeny kind of
> > scares me a little bit.
> > Still, I think it's a good idea, and has it's merits.
> >
> > The main problem would be the classic "user = eye dee ten tee" (user =
> > 1d10t) problem.
> > I'd estimate that close to 70% of the SL userbase either arn't
> > informed enough, or just don't care (more likely) enough to bother
> > with learning how/why/when to use these features/protections.
> >
> > All this might do is slow down the problem, but that can be more than
> > enough in itself, much like LL's new age verification system. It can't
> > stop the problem, but it can mitigate it, and every little bit is
> > something.
> >
> > At the very least, changing the debit permissions dialog to red would
> > have a very good impact, except for the people like my friends who
> > just rapidly click yes on every dialog because they can't be arsed to
> > read it.
> >
> > -- Kamilion Schnook
> > _______________________________________________
> > 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/20070526/b6e2bfe6/attachment.htm


More information about the SLDev mailing list