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

No UA supports it today. No UA is likely to support it anytime soon.

Daniel

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

> Yet you restrict mime-types AND you support application/octet-stream?
>
> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng <dcheng@google.com> wrote:
>
>> For reasons I've already mentioned, this isn't going to happen because
>> there is no so-called "dumping ground".
>>
>> No one is going to risk their paste turning into thousands of lines of
>> gibberish because they tried to stuff binary data in text/plain.
>>
>> Daniel
>>
>>
>> On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch <pyalot@gmail.com> wrote:
>>
>>> No, what I'm saying is that if you restrict mime types (or don't
>>> explicitly prohibit such restriction), but require
>>> application/octet-stream, that application/octet-stream becomes the
>>> "undesirable mime-type" dumping ground. And that would be bad because that
>>> makes it much harder for applications to deal with content. But if that's
>>> the only way UAs are going to act, then applications will work around that
>>> by using elaborate guessing code based on magic bytes, and perhaps some
>>> application developers will use their own mime-type annotation pretended to
>>> the octet-stream.
>>>
>>> If you inconvenience people, but don't make it impossible to work around
>>> the inconvenience, then people will work around the inconvenience. It can't
>>> be the intention to encourage them work around it. So you've got to either
>>> not inconvenience them, or make working around impossible.
>>>
>>> On Thu, Jun 25, 2015 at 5:07 PM, Wez <wez@google.com> wrote:
>>>
>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>