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: Thu, 25 Jun 2015 16:27:35 +0200
Message-ID: <CAOK8ODgVOP0PahjPbjBbvgsFs8i-uKDTQT238mqW3k5XxqBV7A@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>
Surely you realize that if the specification where to state to only
"safely" expose data to the clipboard, this can only be interpreted to deny
any formats but those a UA can interprete and deem well-formed. If such a
thing where to be done, that would leave any user of the clipboard no
recourse but to resort to "application/octett-stream" and ignore any other
metadata as the merry magic header guessing game gets underway. For all
you'd have achieved was to muddle any meaning of the mime-type and forced
applications to work around an unenforceable restriction.

On Thu, Jun 25, 2015 at 3:21 PM, Wez <wez@google.com> wrote:

> And, again, I don't see what that has to do with whether the spec mandates
> that user agents let apps place JPEG, PNG or GIF directly on the local
> system clipboard. The spec doesn't currently mandate OpenEXR be supported,
> so it's currently up to individual user agents to decide whether they can
> support that format safely.
>
> On Thu, 25 Jun 2015 at 14:16 Florian Bösch <pyalot@gmail.com> wrote:
>
>> On Thu, Jun 25, 2015 at 3:13 PM, Wez <wez@google.com> wrote:
>>
>>> I think there's obvious value in support for arbitrary content-specific
>>> formats, but IMO the spec should at least give guidance on how to present
>>> the capability in a safe way.
>>>
>> Which is exactly the core of my question. If you intend to make it say,
>> safe to put OpenEXR into the clipboard (as opposed to letting an app just
>> put any bytes there), the UA has to understand OpenEXR. Since I don't see
>> how the UA can understand every conceivable format in existence both future
>> and past, I don't see how that should work.
>>
>
Received on Thursday, 25 June 2015 14:28:10 UTC

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