clipboard data types registry?

Hi,
some thoughts regarding the CCnP (Cut, Copy and Paste) events spec and  
custom/arbitrary data types.

Ideally, the computer should do what the user intends. When pasting data,  
we should aim to share the data the user intends to share. Hence, if the  
raw clipboard data contains information the user likely isn't aware of  
being there - such as file system paths, software identifying markers,  
session IDs and tokens from other web sites - we should to some extent aim  
to filter out such information.

My understanding - because of feedback like the quote from Daniel Cheng  
below [1] - is that this can really only be done on a per-data-type basis.  
(For example, while we should try to filter out file system paths from  
many types of data, if I place a file system path on the clipboard as  
plain text and paste it into a web service, the filtering should obviously  
not be applied).

The logical conclusion is that to write a really implementable spec with  
complete information, we need some kind of registry, mapping  
MIME/clipboard types to filtering algorithms..

This "registry" might be as simple as a <TABLE> inside the spec itself, or  
it might be something maintained outside of it. I guess it will be  
considered too application-specific for the common MIME type registry,  
though?

Thoughts and views? Is a registry overkill, or useful? Should it be  
in-spec or a separate entity with individual updates? If separate, does  
the W3C have infrastructure for such stuff or do we put the information  
somewhere else?

[1]
> I changed the Clipboard
> implementation in WebKit to directly mirror the contents of the native
> clipboard. As a result though, pages could access a bunch of random types
> that included full filesystem paths as part of their data when dragging a
> file. I suspect that the list of types that happens to leak filesystem  
> paths will vary based on the window manager in use. Because of this, I'm  
> choosing to restrict the number of native types to a smaller, defined set
> that are visible to webpages. Any paths in this set can be filtered as
> necessary when a file drag is detected.

(Daniel Cheng,  
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0297.html )



-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Tuesday, 22 March 2011 08:51:42 UTC