[sldev] Patch to Address Debit Permission Spoofing

[Able Whitman]

Thank you for your feedback; I've replied inline to your comments. Please
let me know if you have any more questions or concerns!

--Able

On 5/25/07, Jason Giglio <gigstaggart at gmail.com> wrote:
>
> Good work!  This one was on my list too actually.  Some feedback inline.
>
> Able Whitman wrote:
> > * Automatic Denial of Debit Permission Requests
>
> I'm not sure this is such a good idea.  Users will likely turn this off,
> then complain when their objects don't work right, even if it does tell
> them that the permission was requested.
>
It also gives the permission a stigma, when it is commonly needed in
> everything that might ever need to give a refund!


I made the auto-deny option default to False for this very reason. It does
treat the debit permission as a stigma, which, in a sense, is the whole
point of this patch. The debit permission is peculiar, in that once you've
granted it to an object, you have no ability either to revoke the permission
or (more importantly) to cancel/undo the actions the object performs on your
behalf with the debit permission.

It's the latter that makes the debit permission a stigma, actually. No other
permission grants an object the ability to do something that is
irreversible--animations can be stopped, attactments detatched, control keys
reclaimed, even (in principle) linkset changes undone.

But once the debit permission allows an object to take your money, there is
no way to undo that debits from your account that the object performs on
your behalf. This is particularly nefarious in that it is the only
permission that has the ability to financially impact a user.

All of this is just justification for treating the debit permission as
special, as a stigma. My reasoning for including the auto-deny feature is
this:

1. The frequency with which users will need to legitimately grant an object
debit permission is relatively quite rare. Users who are setting up vendors
will need to grant this permission rarely, perhaps only once. Users do not
need to grant this permission to Pay an object or to Pay other users, so it
will not interefere with normal consumer transactions.

2. In the event that a user has auto-deny enabled and needs to legitimately
grant an object debit permission, they can simply turn auto-deny off, grant
permission, and re-enable it. Forgetting to turn it off is, I believe, only
a small hassle. For example, someone setting up a vendor who has auto-deny
enabled will most likely find that, if they accidentally auto-deny the
vendor permission to debit, either the vendor will have a mechanism to
re-prompt them. Failing that, they can always reset the vendor object to
force it to re-request the permission. (I am assuming that vendor objects
always must either be owned by the person using them, or that the person who
should appropriately be granting debit permission must at least have object
permissions sufficient to reset the scripts in the object.)

3. It is almost never the right thing to grant debit permission to an object
that you do not own. As before, Paying objects or people doesn't require the
debit permission, and vendors need to be owned by the people they are going
to debit from in order to issue refunds, so that user can configure the
vendor to sell his items in the first place. If you really do need to grant
debit permission to an object you don't own, and you accidentally auto-deny
that permission, either you personally know the owner, or at least should be
able to contact the owner of the object to reset it for you.

4. On balance, I believe the value of the auto-deny feature is outweighed by
the possible hassles around an accidental auto-denial. The effects of
wrongly denying the debit permission are always reversible. The effects of
wrongly *granting* the debit permission are never reversible. This
fundamental asymmertry makes it worth treating the debit permission with a
stigma. (In any event, auto-deny is disabled by default.)

> The preference to enable automatic denial will appear in the "Popups"
> > * Opt-out of Caution Permissions Prompts
>
> I'm also opposed to "preference creep".  It seems that a lot of the
> patches we are seeing are coming with preferences to enable or disable
> them.
>
> Either it's a good idea to do this or it isn't.  We don't need to add a
> preference for every little feature.  If the client had always been
> developed like this, we'd have 50 pages of preferences and be able to
> revert to the 1.0 feature set. :)


I completely understand your point here; I wrestled for some time about
whether to and how to bubble up the auto-deny feature into the UI. Given the
justifications and rationale for the feature I've included above, I still
feel strongly that wiring up the auto-denial to a Preferences setting is the
right thing to do. (I'd also like to have it enabled by default, but I don't
think that strikes the right balance between protecting the user against
malicious scripts while imposing as little hassle to the user as is
reasonable.)

Of course, I could certainly be persuaded otherwise, but given the value of
the feature, I think it is important to make the auto-deny setting at least
more accessible than relegating it to the dustbin of "Debug Settings". :)
Perhaps a compromise would to expose it as a setting on the Client debug
menu, or something similar.


-Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070525/eb3ed0a6/attachment.htm