[sldev] Patch to Address Debit Permission Spoofing

[Frans]

Hey Able,

First of all, great work. Features like these are just as worthwhile if not
more then sculpted prims, in my book.

There is one thing i don't understand, in the screenshots, it says:
"Take linden dollars from you
Link and delink from other objects"

If i understand that correctly, you are asking for 2 different permission.
What if I do want to grant link and delink and not grant take linden
dollars. That won't be possible in this change.

Keep up the good work,
Frans

On 5/25/07, Able Whitman <able.whitman at gmail.com> wrote:
>
> 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 .
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>


-- 
RL: Jeroen Frans / SL: Frans Charming
http://www.thevesuviusgroup.com
http://www.fransinnovations.com
http://www.linkedin.com/in/mrfrans
http://secondslog.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070525/8f4cdf7f/attachment-0001.htm