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

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