W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

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

From: Florian Bösch <pyalot@gmail.com>
Date: Wed, 24 Jun 2015 20:58:56 +0200
Message-ID: <CAOK8ODj=4Ld-LZAWsrmk5yEgXhhNEJW-Ou9C-94WxRAsJkQjuw@mail.gmail.com>
To: Wez <wez@google.com>
Cc: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>, Daniel Cheng <dcheng@google.com>, public-webapps <public-webapps@w3.org>
No, but the specification doesn't require you to exclude it. So how're
applications going to swap OpenEXR if you only let em stick in jpegs, pngs
and gifs?

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

> I don't think OpenEXR is one of the formats required by the Clipboard
> Events spec, is it..?
> On Wed, Jun 24, 2015, 18:49 Florian Bösch <pyalot@gmail.com> wrote:
>> 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 18:59:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC