Re: [clipboard] Semi-Trusted Events Alternative

On Jul 26, 2014, at 9:09 AM, Jeffrey Walton <noloader@gmail.com> wrote:

> On Sat, Jul 26, 2014 at 9:34 AM, Perry Smith <pedzsan@gmail.com> wrote:
>> 
>> On Jul 26, 2014, at 8:26 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>> 
>>> On Sat, Jul 26, 2014 at 9:19 AM, Perry Smith <pedzsan@gmail.com> wrote:
>>>> Sorry if this is a lame question but I never understood the dangers of Copy and Paste that the web is trying to avoid.  Can someone explain that to me?
>>>> 
>>> Its a point of data egress. You don't want sensitive information from
>>> one program scraped and egressed by another.
>>> 
>>> The first program could be a browser and the second program could be
>>> malware. In this case, the malware looks for data placed on the
>>> clipboard by the browser (and hopes to get a username, password,
>>> sensitive document, etc).
>>> 
>>> Or, it could be another program with the browser scraping the data and
>>> hauling it off to a site.
>> 
>> I thought about that.  So it is not so much the Copy and Paste operations as much as being able to get the content of the clipboard. ?
>> 
> Yes, I believe so. The clipboard is a shared resource with little to
> no restrictions.
> 
> One of the check boxes on a security evaluation is how a program
> handles the clipboard and copy/paste (or at least the ones I used when
> doing security architecture work). Its one of those dataflows that
> could be part of a higher then expected data sensitivity, like a
> single sign-on password.
> 
> Also, "data egress" may have been a bad choice. In this case, I think
> its more about "data collection". Its hard to stop a web browser from
> opening a socket ;)
> 
> Two addition clipboard features that would be nice are: (1) a "one
> shot" copy/paste: delete the password from the clipboard after
> retrieving it from he password manager and pasting it into a password
> box; and (2) "timed" copy/paste: expire the data after 10 seconds or
> so. Both should allow the legitimate use cases, and narrow the window
> for the abuse cases.

If this is really the case, it seems that separating Copy from Paste would be proper.

As a web application implementor, I am much more worried about Copy than Paste.  I want to allow the user to quickly move something into the clipboard.  In the times I have been frustrated, it has never been about Paste.  If Copy is not the problem, it would help me if it was split out.

Off topic slightly: my current technique is to have a UI element that selects the content and then the user has to do the Copy from the OS menu (two steps instead of one).  This is not horribly bad since there is usually a mouse / menu way to do this as well as a keyboard short cut method.  The "ick" factor is mostly due to existing expectations.  But it is relatively close to what most applications do.  Rarely is it the case that an application provides a UI element that moves some piece of unselected text into the clipboard.  Perhaps what we have is what we want.

Jeff's two suggestions seem like a good idea in any case.  We always have Flash lurking in the shadows that no one is really going to ever fix.  The problem I see with it is the clipboard is not owned by the browser.  Its a system resource.  In that sense, it would seem like features the OS would want to implement.

Last… if we are only concerned about Paste, then perhaps we should focus on a trusted receiver rather than a trusted and semi trusted events -- although I think that is going to be just as weak.

Perry