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

And how exactly do you intend to support for instance OpenEXR?

On Wed, Jun 24, 2015 at 5:44 PM, Wez <wez@google.com> wrote:

> Hallvord,
>
> Yes, content would be limited to providing text, image etc data to the
> user agent to place on the clipboard, and letting the user agent synthesize
> whatever formats (JPEG, PNG etc) other apps require. That has the advantage
> of preventing malicious content using esoteric flags or features to
> compromise recipients, but conversely means that legitimate content cannot
> use format-specific features, e.g. content would not be able to write a
> JPEG containing a comment block, geo tags or timestamp information.
>
>
>
> Wez
>
>
> On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
> hsteen@mozilla.com> wrote:
>
>> On Thu, Jun 11, 2015 at 7:51 PM, Wez <wez@google.com> wrote:
>>
>>> 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.
>>>
>>
>> Well, but as far as I can tell we don't currently *have* a way JS can
>> place pixels from a canvas on the clipboard (except by putting a piece of
>> data labelled as image/png or similar there). So if you're pushing back
>> against the idea that JS can place random data on the clipboard and label
>> it image/png, how exactly would you propose JS-triggered copy of image data
>> to work? Say, from a CANVAS-based image editor?
>> -Hallvord
>>
>>

Received on Wednesday, 24 June 2015 17:49:53 UTC