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

It's very simple. Applications need to know what's in the clipboard to know
what to do with it. There is also a vast variety of things that could find
itself in the clipboard in terms of formats, both formal and informal. Mime
types are one of these things that applications would use to do that.

If a UA where to restict what mime type you can put into the clipboard,
that forces the clipboard user to use application/octet-stream. And in
consequence, that forces any such-willing application to forgoe the
mime-type information from the OS'es clipboard API and figure out what's in
it from the content. In turn this would give rise to another way to markup
mime-types in-line with the content. And once you've forced such ad-hoc
solutions to emerge for meddling with what people can put in the clipboard,
you'll have no standing to put that geenie back in the bottle, again,
relevant XKCD quote omitted.

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

> You've mentioned "resorting to application/octet-stream" several times in
> the context of this discussion, where AFAICT the spec actually only
> describes using it as a fall-back for cases of file references on the
> clipboard for which the user agent is unable to determine the file type.
>
> So IIUC you're suggesting that user agents should implement
> "application/octet-stream" (as is also mandated by the spec, albeit without
> a clear indication of what it means in this context) by putting the content
> on the clipboard as an un-typed file?
>
> Again, I'm unclear as to what the alternative is that you're proposing?
>
> On Thu, 25 Jun 2015 at 15:27 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.
>>>>
>>>
>>