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

On Thu, Jun 11, 2015 at 12:53 AM Florian Bösch <pyalot@gmail.com> wrote:

> Wait, why are you talking about removing an ostensibly useful feature
> (declaring a mimetype in a paste for certain mime types) because the end
> result could land up in the users paste, where it could be pasted into
> applications that're not equipped to handle random assemblages of bytes,
> even though they are specifically written to handle random assemblages of
> bytes...
>

There is empirical evidence that this is not true for many image decoders.

On Thu, Jun 11, 2015 at 1:00 AM Florian Bösch <pyalot@gmail.com> wrote:

> On a further note. If UAs (which are among the more prevalent applications
> out there being used) intentionally disable declaring mime-types for some
> classes of content, so that it can't be pasted into applications that might
> not be equipped to handle those mimetypes, application programmers (such as
> adobe, gimp etc.) will do something else:
>
>
>    - The first 4 bytes of a PNG: \89PNG
>    - Bytes 9 trough 13 of a JPEG: JFIF
>    - etc.
>
> Every notable non text format in common use today contains "magic" headers
> that make it easy to identify what a file is without having the mimetype or
> file extension.
>
> Omission of metadata information is
>
>    - not going to address your "security concern" since applications do
>    routinely read in random bytes and figure out what they are
>    - it's not going to make applications behave any more securely (or
>    reliably) as it'll promote even more of them to resort to guessing because
>    information is omitted
>
> The clipboard is a key-value store of flavors of data (in this case, MIME
types) to their corresponding data. We're not omitting metadata; we'd block
image/png written by web content from being mapped to its native clipboard
flavor (ATOMs on Windows, UTI on OS X, MIME types on Linux).

Apps don't read text data from the clipboard and then try to interpret it
as a PNG, because no one ever tries writing a PNG into the text clipboard
flavor: pasting in an app that wasn't expecting this (i.e. all of them)
would result in a bunch of gibberish.

On Thu, Jun 11, 2015 at 5:33 AM James M. Greene <james.m.greene@gmail.com>
wrote:

> I can make a plugins for legitimate text/image editors that would override
> default behavior for paste operations to instead execute arbitrary
> processes (e.g. recursively delete the entire working directory) unless the
> parent application is well sandboxed.
>
> Unless the vendors that establish a lightning fast sanity check for a
> subset of binary data types, I really don't believe this is a positive
> change.
>
> While we're on it, how about the good ole harbinger of the unknown:
> "application/octet-stream"? Where do we reasonably draw the line? Will that
> MIME type be blocked? Doesn't seem like there would be any reasonable way
> to scrub it.
>
> Sincerely,
>    James M. Greene
>
Well... sure, if you have a plugin, you can do anything. People (should)
expect plugins to be able to run arbitrary code... because that's what they
are. The point is we don't want pasting an image to be able to do anything
to your system. People would be unpleasantly surprised if pasting an image
results in arbitrary code execution.

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

> What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
> BPG, psd, xcf, etc.?
>

I'm not sure what you're trying to say here.