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

Florian, you keep referring to using application/octet-stream - that's not
a format that all user agents support (although the spec says they should
;), nor is there any mention in the spec of what it means to place content
on the clipboard in that format (given that platform native clipboards each
have their own content-type annotations).

So it sounds like you're saying we should also remove
application/octet-stream as a mandatory format?

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

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