W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

RE: Safe copy and paste with scripts

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Thu, 9 Mar 2006 10:25:47 -0500
To: "'Web API WG'" <public-webapi@w3.org>
Message-Id: <20060309152551.12D8C1965EF@plunder.dreamhost.com>

Hi, Mihai-

As you say, it is not the place for a Spec to dicate how a UA implements
security for features, though I do think it is appropriate to indicate
possible points of security concerns.

It should be a goal of a Spec to avoid defining features that seem
intractable as concerns security, but I do not think that this is such a
feature. Several possible solutions have already been proposed, and a UA
probably has its own security model that it can extend to this feature as it
is felt necessary.

Note that I do not consider the ability to place or replace data in the
clipboard to be a security issue, merely a possible source of annoyance and
a usability issue.

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.
 

Mihai Sucan wrote:
| 
| 
| Le Thu, 09 Mar 2006 10:25:39 +0200, Paul Libbrecht 
| <paul@activemath.org> a  
| écrit:
| 
| > Mihai Sucan wrote:
| >> Take a look at: http://www.mozilla.org/editor/midasdemo/
| >>
| >> That's a pretty old WYSIWYG editor demo for Gecko. They do 
| allow web  
| >> pages to cut/copy/paste only if the user grants access. 
| They don't  
| >> currently provide an UI for enabling the feature, but the 
| capability is  
| >> in place.
| > Thanks for that... I wasn't aware of it indeed.
| 
| No problem. AFAIK it's not the only example, but this is the 
| smallest and  
| quickest I've found.
| 
| > However, as we know... no-one wants to enable clipboard 
| access for all  
| > sites!
| > So this is a kind of no-go.
| 
| Yes.
| 
| > How would you go with trust-giving ?
| > At least in java, trust can only be given to signed 
| things... and that's  
| > where the painful things start.
| 
| Just pitching here ...
| 
| We already have in place HTTPS, with secured certificates, 
| blah blah.  
| There are strict policies that apply to such sites.
| 
| Clipboard access could be given only to sites over secured 
| connections. It  
| doesn't make much sense if you think of it, but this way 
| you'd weed out a  
| huge number of n00bs trying to screw-up the clipboard of the 
| visitor just  
| for fun.
| 
| I'll take Opera as an example: if the secured certificate is 
| "dodgy",  
| Opera asks you if you accept it or not. This is a good thing. 
| Also, IE has  
| the policy level of "trusted site" for secured sites, etc.
| 
| There's no need for a new complex way of making clipboard 
| access secured.
| 
| Yes, this would be painful for authors, but not for 
| implementors. They  
| already have this in place and they can easily enable 
| clipboard access to  
| secured sites.
| 
| The "painful for authors" problem shouldn't of too much 
| concern, at least  
| in regards to clipboard access. If it's easy, too many will feel the  
| "urge" to have "fun" with somebodys clipboard.
| 
| There's a risk in doing so, the entire usefulness would be 
| simply rendered  
| useless by having it constrained to secured sites only.
| 
| Maybe after reading this somebody can come up with a better idea.
| 
| I'm still for "user confirmation" (no matter how) when a site wants  
| clipboard access. It's easy, it's not complex, etc.
| 
| As far as I've learned, a spec does not have to define UI stuff and  
| related. Then, simply define the clipboard access and ... 
| provide a big  
| fat informative warning for implementors along these lines: 
| "it's up to  
| you to make it secure, maybe provide a way for the user to 
| confirm access  
| to the clipboard data".
| 
| What would you suggest?
| 
| 
| 
| P.S. Off-topic: email address changed.
| 
| 
| 
| -- 
| http://www.robodesign.ro
| ROBO Design - We bring you the future
Received on Thursday, 9 March 2006 15:26:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT