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

Hello all,

I think a good solution would then be that UAs do a transcoding, or?
(so the spec should recommend doing it)

I understand that the right-menu "copy image" function has the same
problem except if that one does transcoding (and it probably does, to
offer more native flavours).

That would work fine against attacking pictures that would overflow some
older picture processors.
For those graphic freaks which need the exact bytes (e.g. with a
particular profile etc), I think they can expect the web-app to offer a
download for which there's enough dialogs and protection.

Whether an unfiltered picture file should be expected by copy after some
security-dialog-confirmed process, I do not know. Maybe using
octet-stream is the solution?

thanks

Paul

On 11/06/15 08:31, Hallvord Reiar Michaelsen Steen wrote:
> On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng <dcheng@google.com
> <mailto:dcheng@google.com>> wrote:
>
>     Currently, the Clipboard API [1] mandates support for a number of
>     formats. Unfortunately, we do not believe it is possible to safely
>     support writing a number of formats to the clipboard:
>     - image/png
>     - image/jpg, image/jpeg
>     - image/gif
>
> copying images to the clipboard is an important use case. Do you have
> any suggestions for how we could meet this use case in a safer way?
> For example, would it be safe and easy to add a little bit of "magic"
> to make
>
> clipboardData.items.add(canvasElement)
>
> put a PNG on the clipboard? Perhaps copying a rendered imgElement
> should work too?
> -Hallvord