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

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

From: Wez <wez@google.com>
Date: Thu, 25 Jun 2015 11:25:03 +0000
Message-ID: <CALekkJfHx96Z896O+z_AEnzDFvM_1axmUJmgw3Nnvt7AiUvbXQ@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>, Daniel Cheng <dcheng@google.com>, public-webapps <public-webapps@w3.org>
Which user agents currently allow content to post OpenEXR to the local
clipboard?

On Wed, 24 Jun 2015 at 19:58 Florian Bösch <pyalot@gmail.com> wrote:

> 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 Thursday, 25 June 2015 11:25:41 UTC

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