- From: Wez <wez@google.com>
- Date: Thu, 11 Jun 2015 10:51:05 -0700
- To: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>
- Cc: Daniel Cheng <dcheng@google.com>, public-webapps <public-webapps@w3.org>
Received on Thursday, 11 June 2015 17:51:33 UTC
Hallvord, The proposal isn't to remove support for copying/pasting images, but to restrict web content from placing compressed image data in one of these formats on the clipboard directly - there's no issue with content pasting raw pixels from a canvas, for example, since scope for abusing that to compromise the recipient is extremely limited by comparison to JPEG, PNG or GIF. The UA is still at liberty to synthesize these formats itself, based on the raw imagery provided by the content, to populate the clipboard with formats that other applications want. HTH, Wez On 10 June 2015 at 23:31, Hallvord Reiar Michaelsen Steen < hsteen@mozilla.com> wrote: > On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng <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 >> > > Hi Daniel, > 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 >
Received on Thursday, 11 June 2015 17:51:33 UTC