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

I'm pretty sure it can't be in the interest of this specification to force
application authors to bifurcate the mime-type into one that can't be used
reliably, and another informal one that's prepended to the octet-stream.
Relevant XKCD quote omitted.

On Thu, Jun 25, 2015 at 4:27 PM, Florian Bösch <pyalot@gmail.com> wrote:

> 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.
>>>
>>
>