[sldev] Patch to Address Debit Permission Spoofing

[Able Whitman]

My apologies, I had intended the patch file to be an attachment, but
apparently it didn't come out that way. This was the original body of my
patch email:


Howdy,

I've just recently started learning about the SL client source. As a sort of
introductory project to help me learn my way around, I thought I would pick
a small feature request from  JIRA and set about implementing it.

The feature request I chose deals with the fact that it's relatively easy
for someone who isn't attentive to permissions prompts to unintentionally
grant debit permissions to an object.

I've produced a patch based on the 1.16.0.5 client source, which I've
attached, along with a few screen caps to illustrate the UI changes that the
patch makes. I've included a short spec for the feature below, since the
JIRA bugs didn't have much in the way of functional details.

This is my first such contribution to a project like this, so please let me
know if you have any questions or feedback (good or bad).

Thanks,
--Able

...
Second Life Viewer Patch to Address Debit Permission Spoofing

Purpose
---------
The purpose of this patch is to alter the client's handling of script
permission requests so as to make requests for the debit permission more
readily apparent to the user.

Background
--------------
A script can ask an agent to grant it certain permissions, such as the
ability to animate the avatar, or to attach itself to the avatar. Almost all
of these permissions grant a script the ability to perform actions that are
revocable--animations can be stopped, and controls can be regained,
attachments can be detached.

The one exception to this is the debit permission, where a script asks for
an agent's permission to "Take Linden Dollars (L$) from you". Worse, not
only are the actions performed with this permission not revocable, once an
object is granted such permission, that permission itself is irrevocable
until the object itself is reset.

When the user is prompted to grant an object various permissions, the prompt
is the visually the same regardless of what permissions are requested.
Maliciously-scripted objects have taken advantage of this fact to trick
users into granting seemingly-innocuous objects permission to take their
money, an action for which they have no recourse. See, for example:

    Animator that steals your cash?

http://www.secondlifeinsider.com/2007/05/15/animator-that-steals-your-cash/

    Can objects really steal your $L?
    http://forums.secondlife.com/showthread.php?t=184519

Rationale
------------
It is good that the client requires scripts to ask for explicit permission
to perform these various actions. The fact that the debit permission is
given essentially the same visual "weight" as other permissions, however,
can lead to users to make inappropriate trust decisions. Where a user might
trust a random object from a stranger to animate his avatar, it's unlikely
that he will trust the same object to debit money from his account.

Bugs Addressed
--------------------
This patch nominally addresses the following JIRA issue:

    VWR-650: making permission debit red
    https://jira.secondlife.com/browse/VWR-650

Other related issues include VWR-767, MISC-228, and MISC-109.

Functional Specification
--------------------------------
This patch modifies the client's behavior when it handles script permission
requests.

* Permissions Requests Other than Debit
When the client receives a script permissions request, it examines all of
the permissions being requested. If the debit permission is not requested,
the permissions request proceeds normally. The user will see a prompt
similar to that in " debit-perm-normal-prompt.PNG", as they expect.

* Permissions Requests for Debit
If the debit permission is requested (regardless of what other permissions
are also requested), the client alters the appearance of the permissions
request prompt. The background of the prompt box is changed to red, and the
buttons are shaded to be reddish-purple. The user will see a caution prompt
similar to that in " debit-perm-caution-prompt.PNG".

This provides a strong visual cue to the user that he is being asked to
grant permissions that are out of the ordinary.

In addition, regardless of whether the user grants or denies the request, a
chat message is echoed to his chat window giving both the object's and the
object owner's names, and whether or not the debit permission was granted or
denied. The chat messaged that is logged will be similar to the one in "
debit-perm-deny-chat.PNG".

This step provides an additional visual cue to the user that something out
of the ordinary has happened, and, if the client has chat logging enabled
this provides a searchable record of objects and owners to which he has
granted or denied debit permission.

* Automatic Denial of Debit Permission Requests
The UI cues alone should help users to make more informed trust decisions
about the permissions they grant to objects.

In addition to these cues, this patch introduces a new Preferences setting
called "PermissionsCautionAutoDecline". This option is disabled by default.
When it is enabled, any permissions requests that include a request for the
debit permission will automatically be denied. This denial will apply to all
of the requested permissions, not just the debit permission.

When an automatic denial occurs, the user will see a prompt explaining which
object was requesting the permission, and a list of permissions it
requested. There will also be a message logged to the user's chat window
indicating the object name and the name of its owner, just as when automatic
denial is disabled. This informational prompt will look similar to the one
in " debit-perm-deny-prompt.PNG".

The preference to enable automatic denial will appear in the "Popups"
Preferences dialog page, and will look similar to the preference in "
debit-perm-debit-autodeny-pref.PNG ".

* Opt-out of Caution Permissions Prompts
If the user wishes to disable special visual style applied to permissions
prompts that include the debit permission, he can use the Debug Settings
menu to change the " PermissionsCautionPrompt" setting to False.

Note that disabling the caution permissions prompts does not affect the
behavior of the automatic denial setting, nor does it change the behavior of
chat messages being logged for objects that request the debit permission.
This setting affects the visual cues only.

Technical Discussion
---------------------------
The diff patch provided is derived from a copy of the 1.16.0.5 client source
that was modified to build under Microsoft Visual Studio 2005. The patch
itself is fairly straightforward, but there are a few details worth
mentioning specifically.

* Marking Which Permissions and Templates Cause a Caution Prompt
In the processing of "notify.xml", notifications are examined for an
optional Boolean property called Caution on each Notify element. If this
property is not present, or is set to False, the template specified by that
Notify element is treated normally.

If the Caution property is set to True, then any permissions request that
include a permission whose Notify element is flagged, or the use of any
notification template that is flagged will trigger a caution prompt. In the
case of script permissions with the Caution property set, an automatic
denial will be triggered if enabled.

* Changes to the Mechanism for Processing Script Requests
In "llviewermessage.cpp", the "process_script_question()" method has been
modified to include logic to allow it to evaluate whether the requested
permissions should trigger an automatic denial or not. In the event of an
automatic denial, a new callback named "script_question_decline_cb" is used
which always denies permissions requests.

In addition, the "LLScriptQuestionCBData" class was modified to include the
name of the object requesting permissions, and the name of its owner, so
that this information can be used in both callbacks to log a chat message,
if appropriate.

Known Bugs
-----------------
* Caution Prompt Rendering Bug
In the event that multiple prompts are on top of one another in the client's
display, in some circumstances, the buttons on a caution prompt will become
highlighted in orange rather than in reddish-purple. The repro for this
appears to require the user to dismiss a dialog immediately on top of the
caution dialog in such a manner as to place the mouse cursor on top of one
of the caution dialog buttons.

I have not been able to track down the cause of this bug, but it is cosmetic
only and does not impact the functionality of the patch.

* Localization Issue
I have only provided English (en-us) entries for the changes made to the
notifications, chat messages, and preference settings that were added for
this patch.

Localized translations of these resources will be necessary in order for the
patch to function properly in non-English clients.

Improvements
------------------
It is certainly possible that the wording or terminology I have used could
be improved upon.

It would also be a simple matter to change the wording of the caution
permissions prompt in addition to its color, in order to make the warning
even more apparent to the user.

Questions
-------------
If you have any questions, comments, or concerns about this patch, please IM
me in-world or email me at able.whitman at gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070525/663b0bea/attachment.htm