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

Browsers are very visible applications. Most other applications in
existence tend to work around their foibles in one fashion or another. If
Browsers where to sprout another such foible as to force people to discard
mime-type specification for content because browsers don't let them, it
would give rise to widely confusing and homebrewn workarounds till out of
that broil another mime-type standard emerged that browsers sought to
repress.

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

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