Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

> I'm just thinking out loud here, but this problem is similar to one
> already faced by email clients, especially those which are web-based...
>
> On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen <
> hsteen@mozilla.com> wrote:
>
>  So PNG, JPG et al go in the "support
>> reading from clipboard" list, and the "support writing" starts out with
>> text/plain, text/html and text/uri-list - although it would be nice if
>> CSV was also considered safe enough.
>>
>
> I'm not sure you should directly read image formats from the clipboard,
> especially if you don't know how they got there.


What are your concerns exactly? As Wez mentioned we may have to add some
transcoding - but if there's a chunk of binary data labelled as JPEG on the
clipboard, and the user wants to paste this into her blog editor, how would
we do that if web content "shouldn't" read image formats from the clipboard?


> You shouldn't write stuff there that can be dangerous, but you really
> shouldn't read it direct. So maybe what happens is that when stuff gets
> written, it goes through a process like painting it onto a canvas, and then
> being scraped back off as coloured pixels and "safe" metadata.
>

Indeed, if that's what it takes.. like the addImageFromCanvas() suggestion
below. Regarding that suggestion you asked:


> Is it more than syntactic sugar?
>
>
If we allow adding image data as blobs, the "normal" way with
clipboardData.items.add() it would be just a convenience method. Since
Daniel Cheng has serious concerns and good arguments against allowing that,
something like addImageFromCanvas() might be a workaround that would let
users put images on the clipboard in a safe way.. If we have neither, I
guess we'll see data:image/jpeg URLs placed on the clipboard as plain text.
-Hallvord R.