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

[Hallvord Reiar Michaelsen Steen]

Relevant to this thread - I've just reported an issue on making the
DataTransfer API safer:
https://github.com/whatwg/html/issues/1244

Input there would be great. I'm planning to look at how to add this to
the spec, but I'm not sure what exactly it should say.

I would still like comments from implementors on this question:

> Implementors? Can we rescue clipboardData.items.add(binaryImageData,
> 'image/jpeg') by mandating transcoding? :)
> Is the current Safari Mac behaviour a problem or is it safe enough to spec?

-Hallvord R

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

[Hallvord Reiar Michaelsen Steen]

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem

I'm trying to handle this question on another E-mail thread so please
follow up there :)

>> JSON: nope, there's no such thing as "external inclusion" in JSON, and
>> there never will be.

> You can certainly exchange a Bookmark-list over json (e.g.
> http://kb.mozillazine.org/Bookmarks)... that would be a simple example of
> some JSON whose URLs you should not "GET" without some concerns (e.g.
> localhost servers).

But JSON as such has no concept of "URL" or a "URL" data type. To a
JSON implementation it's just a string, and I don't see any step of a
clipboard roundtrip doing anything magic to figure out what strings
are URLs or trying to process them :).

> Similarly XInclude-enabled XMLs or even other remote-including-XMLs (e.g.
> through DTD) should ask the users, deny, or inline.

Do you think we should not mandate support for writing XML to the
clipboard from JS, then?
Is this also a problem for MathML?

> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).

To make sure we understand each other: what you're saying here is that
if I do this in a JavaScript:

document.oncopy = function(e){
  e.clipboardData.setData('text/html', 'https://mozilla.org/images/logo.gif";>');
  e.preventDefault();
}

the data that actually ends up being written to the clipboard will be



I think that would be rather surprising behaviour, and would create
some attack scenarios if the attacker can predict the URLs of images
with private data inside them. On pasting they would then be data:
URLs without a concept of origin, the UA would no longer be able to
rely on mechanisms like CORS and/or session data to determine if it's
OK to show the image. If that image would be painted on a CANVAS after
pasting, the image data would now be accessible to JS without
tainting..

Is this really what you propose? :)

> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
>
> Please share the test, this is exactly the kind of things we need around to
> see how crooked one could touch upon.

I was playing around with the code the reporter of
https://bugzilla.mozilla.org/show_bug.cgi?id=860857 submitted - here's
an online version modified to also put image/tiff on the clipboard:
https://jsfiddle.net/gk3vm5L8/1/ (apparently this test was derived
from some Google Docs code).

>> So, the question (for recap) is: would it be OK to let JS write binary
>> data labelled as an image type if the browser was required to
>> transcode it to TIFF or DIB and only update the clipboard if such
>> transcoding succeeded?

> My answer is definitely yes as we should*assume that image transcoders
> should remove the dangers of flawed parsers as they could happen otherwise
> in other situations (e.g. in doing screenshots).

Implementors? Can we rescue clipboardData.items.add(binaryImageData,
'image/jpeg') by mandating transcoding? :)
Is the current Safari Mac behaviour a problem or is it safe enough to spec?
-Hallvord

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

[Paul Libbrecht]

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

cool!
>> But copying a fragment of HTML in the wild without reformulating it will
>> lead to privacy breach: it would copy references to external content. I
>> believe all browsers have an "inlining" method to solve that problem when
>> pasting from a web-page (I believe "save as web page complete" also does a
>> part of that).
>
> I think the proposed solution may be worse for privacy than the
> original problem: images you would "inline" might have sensitive data
> in them.. AFAIK it's not common to do any image inlining or URL
> mangling when pasting HTML copied from another site, is it?

It's the way it currently works on FF apparently (tested MacOSX 10.11
and Windows 7) and on Safari: all images are converted to data-urls.
I don't really see why it would be worse.
Would sensitive data be something such as the metadata? That could
certainly be stripped by transcoding.
>>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>>> most parsers would be safe.
>> I think the danger lies beyond parsers.
>> In XML, you would have XInclude which can be used in many tools to include
>> content from outside.
>> I believe I have seen JSON syntaxes that had external references as part of
>> their specs but I can't remember which now.
>> As long these formats are copied as is and parsed blindly the risk of
>> external inclusion remains.
>
> XML: good point.
> JSON: nope, there's no such thing as "external inclusion" in JSON, and
> there never will be.
You can certainly exchange a Bookmark-list over json (e.g.
http://kb.mozillazine.org/Bookmarks)... that would be a simple example
of some JSON whose URLs you should not "GET" without some concerns (e.g.
localhost servers).
Similarly XInclude-enabled XMLs or even other remote-including-XMLs
(e.g. through DTD) should ask the users, deny, or inline.
>>> For the unsafe formats, the warning could say that the UA-implementors
>>> should only support the flavour if they have a method to make this content
>>> safe so that local applications (which do not expect untrusted content)
>>> receive content they can trust when pasting. Methods to make the content
>>> safe include the following: transcoding a picture, inlining all external
>>> entities for html, xml, mathml, or rtf).
>> On Windows I believe images are transcoded to and from DIB - device
>> independent bitmap format anyway. Is there any equivalent graphics
>> interchange format on other platforms? Does mandating such transcoding help
>> guarantee against payloads that might trigger vulnerabilities in target
>> software?
>>
>> All platforms I know of have some sort of transcoding of pictures (in Macs
>> it is PDF as the central format).
>> I think this is a very safe mechanism to rely on.
>
> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
Please share the test, this is exactly the kind of things we need around
to see how crooked one could touch upon.
E.g. MS Office documents nowadays display a "kind" of mistrust so the
user can bless if macros should be run. This kind of mistrust is
probably the future.
However, going as far as refusing any picture you
right-click-copy-picture from a web-browser because it is unsafe is far
from being what the users expect nowadays.
>> I expect it adds a significant hurdle against exploits, but I'd like input
>> from Daniel Cheng and perhaps from people who have worked on image
>> decoders..
>
> I'd still like Daniel Cheng to chime in again if he has time :)
> So, the question (for recap) is: would it be OK to let JS write binary
> data labelled as an image type if the browser was required to
> transcode it to TIFF or DIB and only update the clipboard if such
> transcoding succeeded?
My answer is definitely yes as we should*assume that image transcoders
should remove the dangers of flawed parsers as they could happen
otherwise in other situations (e.g. in doing screenshots).
> (Obviously we also need the reverse mechanism - on paste, if there's
> TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
yes

Paul

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

[Hallvord Reiar Michaelsen Steen]

On Mon, Feb 8, 2016 at 7:45 PM, Wez  wrote:
> Hallvord,
>
> IIUC the issue is that while transcoding complex formats via formats that
> can be easily sanity-checked by the browser takes care of letting content
> set complex formats like JPEG, GIF while protecting local content, but it
> loses the ability for content to pass that content to other local
> applications losslessly.  e.g. transcoding to BMP would remove JPEG
> location, time/date, etc annotations.

There is an issue here. Would it be possible to add another clipboard
entry for metadata or something?

> The bug you refer to looks like it's talking about intra-Browser, i.e.
> content->content, copy/paste operations for arbitrary MIME-types?
>> https://bugzilla.mozilla.org/show_bug.cgi?id=860857


It's basically about being able to place content labelled as an
arbitrary MIME type on the clipboard (i.e.
clipboardData.setData('application/x-foo', 'my custom data')) but -
correct me if I'm wrong - I don't think the browser has any real,
cross-platform way to distinguish a MIME type the JS just invented and
a MIME type that is known to and used by some other application on the
system. Hence I think the discussions of writing "data in formats
native apps use" and "data in formats custom to the script creating
them" are not two separate discussions.

It may be possible to distinguish an "already registered" and a "not
known to system" type on Windows, but even that isn't really a
guarantee that some format description isn't used by other software -
and on Mac/nix it's harder because they have a different model than
Windows's "registered types" model.

If it is possible to draw such distinctions on all/some platforms
please enlighten me, and we can perhaps untangle this into two
separate topics again :)
-Hallvord

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

[Wez]

Hallvord,

IIUC the issue is that while transcoding complex formats via formats that
can be easily sanity-checked by the browser takes care of letting content
set complex formats like JPEG, GIF while protecting local content, but it
loses the ability for content to pass that content to other local
applications losslessly.  e.g. transcoding to BMP would remove JPEG
location, time/date, etc annotations.

The bug you refer to looks like it's talking about intra-Browser, i.e.
content->content, copy/paste operations for arbitrary MIME-types?

Cheers,

Wez @ Google


On 6 February 2016 at 05:01, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> BTW, we have a slightly related and interesting discussion regarding
> custom data types going on here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=860857
>
> I should try to sum up some of the arguments and proposals and present
> them on this list but if anyone wants to chime in, I'd appreciate more
> ideas in that bug too. I'll do my best to present them objectively and
> fairly on the list :)
> -Hallvord R
>
>

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

[Hallvord Reiar Michaelsen Steen]

BTW, we have a slightly related and interesting discussion regarding
custom data types going on here:
https://bugzilla.mozilla.org/show_bug.cgi?id=860857

I should try to sum up some of the arguments and proposals and present
them on this list but if anyone wants to chime in, I'd appreciate more
ideas in that bug too. I'll do my best to present them objectively and
fairly on the list :)
-Hallvord R

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

[Hallvord Reiar Michaelsen Steen]

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht  wrote:

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem when
> pasting from a web-page (I believe "save as web page complete" also does a
> part of that).

I think the proposed solution may be worse for privacy than the
original problem: images you would "inline" might have sensitive data
in them.. AFAIK it's not common to do any image inlining or URL
mangling when pasting HTML copied from another site, is it?

>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>> most parsers would be safe.
>
> I think the danger lies beyond parsers.
> In XML, you would have XInclude which can be used in many tools to include
> content from outside.
> I believe I have seen JSON syntaxes that had external references as part of
> their specs but I can't remember which now.
> As long these formats are copied as is and parsed blindly the risk of
> external inclusion remains.

XML: good point.
JSON: nope, there's no such thing as "external inclusion" in JSON, and
there never will be.

>> For the unsafe formats, the warning could say that the UA-implementors
>> should only support the flavour if they have a method to make this content
>> safe so that local applications (which do not expect untrusted content)
>> receive content they can trust when pasting. Methods to make the content
>> safe include the following: transcoding a picture, inlining all external
>> entities for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding help
> guarantee against payloads that might trigger vulnerabilities in target
> software?
>
> All platforms I know of have some sort of transcoding of pictures (in Macs
> it is PDF as the central format).
> I think this is a very safe mechanism to rely on.

I've just done a small test in Safari on Mac. It allows writing a
random string to the clipboard and labelling it image/tiff (and
helpfully adds a "public.tiff" clipboard entry with the same random
data). There's no transcoding or similar.

> I expect it adds a significant hurdle against exploits, but I'd like input
> from Daniel Cheng and perhaps from people who have worked on image
> decoders..

I'd still like Daniel Cheng to chime in again if he has time :)
So, the question (for recap) is: would it be OK to let JS write binary
data labelled as an image type if the browser was required to
transcode it to TIFF or DIB and only update the clipboard if such
transcoding succeeded?

(Obviously we also need the reverse mechanism - on paste, if there's
TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
-Hallvord

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

[Paul Libbrecht]

Hello Hallvord,

> Hallvord Reiar Michaelsen Steen 
> 27 août 2015 18:32
> On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht  > wrote:
>
> do you not want to split the writable types list in safe and
> non-safe ones and let browsers how they deal with unsafe ones? 
>
>
> No, absolutely not. If we leave such things up to the browser we end
> up with implementations that do wildly different things and web
> developers suffering new levels of incompatibility pain.
I mean, let them decide if they support it or not.
>
> Here's an idea:
>
> html, xml, and picture formats should be in the unsafe ones. 
>
>
> If we can help it, HTML should not be unsafe. It's the web's primary
> format, and if we class it as unsafe we basically prohibit scripts
> from being able to export formatted text to the clipboard.
>
> I do however know it takes a bit of a leap of faith to believe that
> it's safe enough, given that HTML parsing was a bit of a dark art for
> many years. Today we can at least hope a lot of software that consumes
> HTML has been updated to use HTML5 algorithms.
HTML5 has changed the parsing algorithm indeed.
But copying a fragment of HTML in the wild without reformulating it will
lead to privacy breach: it would copy references to external content. I
believe all browsers have an "inlining" method to solve that problem
when pasting from a web-page (I believe "save as web page complete" also
does a part of that).

>  
>
> I guess json too (but both XML and JSON are too generic to my taste).
>
>
> Why should JSON be unsafe? Parsing JSON should be pretty easy, so
> hopefully most parsers would be safe.
I think the danger lies beyond parsers.
In XML, you would have XInclude which can be used in many tools to
include content from outside.
I believe I have seen JSON syntaxes that had external references as part
of their specs but I can't remember which now.
As long these formats are copied as is and parsed blindly the risk of
external inclusion remains.

However, it is true that I do not know of applications that receive
application/xml or text/json without being web-aware or even developer
aware... I am not sure what to suggest here.
(sniffing xml or json in the plain text is commonly done in many apps is
actually much worse in terms o security).
>  
>
> For the unsafe formats, the warning could say that the
> UA-implementors should only support the flavour if they have a
> method to make this content safe so that local applications (which
> do not expect untrusted content) receive content they can trust
> when pasting. Methods to make the content safe include the
> following: transcoding a picture, inlining all external entities
> for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding
> help guarantee against payloads that might trigger vulnerabilities in
> target software?
All platforms I know of have some sort of transcoding of pictures (in
Macs it is PDF as the central format).
I think this is a very safe mechanism to rely on.
> I expect it adds a significant hurdle against exploits, but I'd like
> input from Daniel Cheng and perhaps from people who have worked on
> image decoders..
> -Hallvord
Yes, comments would be helpful.

paul

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

[Hallvord Reiar Michaelsen Steen]

On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht  wrote:

> Hallvord,
>
> do you not want to split the writable types list in safe and non-safe ones
> and let browsers how they deal with unsafe ones?
>

No, absolutely not. If we leave such things up to the browser we end up
with implementations that do wildly different things and web developers
suffering new levels of incompatibility pain.


> Here's an idea:
>
> html, xml, and picture formats should be in the unsafe ones.
>

If we can help it, HTML should not be unsafe. It's the web's primary
format, and if we class it as unsafe we basically prohibit scripts from
being able to export formatted text to the clipboard.

I do however know it takes a bit of a leap of faith to believe that it's
safe enough, given that HTML parsing was a bit of a dark art for many
years. Today we can at least hope a lot of software that consumes HTML has
been updated to use HTML5 algorithms.


> I guess json too (but both XML and JSON are too generic to my taste).
>

Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
most parsers would be safe.


> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).
>

On Windows I believe images are transcoded to and from DIB - device
independent bitmap format anyway. Is there any equivalent graphics
interchange format on other platforms? Does mandating such transcoding help
guarantee against payloads that might trigger vulnerabilities in target
software? I expect it adds a significant hurdle against exploits, but I'd
like input from Daniel Cheng and perhaps from people who have worked on
image decoders..
-Hallvord

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

[Paul Libbrecht]

Hallvord,

do you not want to split the writable types list in safe and non-safe
ones and let browsers how they deal with unsafe ones? Here's an idea:

html, xml, and picture formats should be in the unsafe ones. I guess
json too (but both XML and JSON are too generic to my taste).
Similarly, I'd like to add things such as MathML ones
(application/mathml-presentation+xml, application/mathml-content+xml,
application/mathml+xml) and rtf.

For the unsafe formats, the warning could say that the UA-implementors
should only support the flavour if they have a method to make this
content safe so that local applications (which do not expect untrusted
content) receive content they can trust when pasting. Methods to make
the content safe include the following: transcoding a picture, inlining
all external entities for html, xml, mathml, or rtf).

What do you think?

Paul

Hallvord Reiar Michaelsen Steen wrote:
> How does that sound?
>
> To those of you who want support for reading and writing many more
> formats (both common like RTF and esoteric ones): we're discussing
> what scripts from the world wild web should be allowed to do,
> basically without any permissions being granted (just something being
> clicked/touched in a page - a pretty low bar..). I understand that
> you're impatiently looking forward to all the great stuff you could do
> with full access to read and write whatever, but please have some
> patience while we work out just how scary (or not) various data types
> are..

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:

> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gif
>
> If these types are supported, malicious web content can trivially write a
> malformed GIF/JPG/PNG to the clipboard and trigger code execution when
> pasting in a program with a vulnerable image decoder. This provides a
> trivial way to bypass the sandbox that web content is usually in.
>

Hi Daniel,
I've split the data type list (as suggested earlier) into one for reading
and one for writing. Please review and tell me what you think:
https://w3c.github.io/clipboard-apis/#mandatory-data-types-1

To support the "copy images to clipboard" use case, I'd like to extend the
DataTransferItemList.add() method.
https://html.spec.whatwg.org/multipage/interaction.html#dom-datatransferitemlist-add

Two suggestions, one slightly less verbose but with slightly more "magic":
let add() take an element, prepare writing an image to the clipboard if the
element is IMG or CANVAS:

event.clipboardData.items.add(myHTMLCanvasElement);
event.clipboardData.items.add(myHTMLImgElement);

A more verbose way (but perhaps easier to understand) is to make add()
accept dataTransferItem objects and add a .toDataTransferItem() method to
IMG and CANVAS:

event.clipboardData.items.add(myHTMLCanvasElement.toDataTransferItem());
event.clipboardData.items.add(myHTMLImgElement.toDataTransferItem());

In either case, running the above two lines of code should end up with two
new items added to the DataTransfer item list, with kind set to file, type
string set to image/png or image/jpeg depending on what the source was
and/or what the UA transcoded the data to, and with data set to the image
data.

How does that sound?

To those of you who want support for reading and writing many more formats
(both common like RTF and esoteric ones): we're discussing what scripts
from the world wild web should be allowed to do, basically without any
permissions being granted (just something being clicked/touched in a page -
a pretty low bar..). I understand that you're impatiently looking forward
to all the great stuff you could do with full access to read and write
whatever, but please have some patience while we work out just how scary
(or not) various data types are..

-Hallvord

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

[Chaals McCathie Nevile]

On Tue, 28 Jul 2015 08:24:17 -0400, Hallvord Reiar Michaelsen Steen  
 wrote:



On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:


I'm just thinking out loud here, but this problem is similar to one
already faced by email clients, especially those which are web-based...

On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

 So PNG, JPG et al go in the "support

reading from clipboard" list, and the "support writing" starts out with
text/plain, text/html and text/uri-list - although it would be nice if
CSV was also considered safe enough.



I'm not sure you should directly read image formats from the clipboard,
especially if you don't know how they got there.


What are your concerns exactly? As Wez mentioned we may have to add some
transcoding - but if there's a chunk of binary data labelled as JPEG on  
the clipboard, and the user wants to paste this into her blog editor,

how would we do that if web content "shouldn't" read image formats from
the clipboard?


Essentially only certain things would be delivered from the clipboard - a  
picture in the desired format, and hopefully a certain amount of metadata.  
But we would be pretty explicit that unexpected stuff may well be dropped  
- and probably *should* in various cases like images


(I think we might actually agree in practice, and be looking for words)

cheers


You shouldn't write stuff there that can be dangerous, but you really
shouldn't read it direct. So maybe what happens is that when stuff gets
written, it goes through a process like painting it onto a canvas, and  
then being scraped back off as coloured pixels and "safe" metadata.


Indeed, if that's what it takes.. like the addImageFromCanvas()  
suggestion below. Regarding that suggestion you asked:




Is it more than syntactic sugar?



If we allow adding image data as blobs, the "normal" way with
clipboardData.items.add() it would be just a convenience method. Since
Daniel Cheng has serious concerns and good arguments against allowing  
that, something like addImageFromCanvas() might be a workaround that

would let users put images on the clipboard in a safe way.. If we have
neither, I guess we'll see data:image/jpeg URLs placed on the clipboard
as plain text.
-Hallvord R.



--
Using Opera's mail client: http://www.opera.com/mail/

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:

> I'm just thinking out loud here, but this problem is similar to one
> already faced by email clients, especially those which are web-based...
>
> On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen <
> hst...@mozilla.com> wrote:
>
>  So PNG, JPG et al go in the "support
>> reading from clipboard" list, and the "support writing" starts out with
>> text/plain, text/html and text/uri-list - although it would be nice if
>> CSV was also considered safe enough.
>>
>
> I'm not sure you should directly read image formats from the clipboard,
> especially if you don't know how they got there.


What are your concerns exactly? As Wez mentioned we may have to add some
transcoding - but if there's a chunk of binary data labelled as JPEG on the
clipboard, and the user wants to paste this into her blog editor, how would
we do that if web content "shouldn't" read image formats from the clipboard?


> You shouldn't write stuff there that can be dangerous, but you really
> shouldn't read it direct. So maybe what happens is that when stuff gets
> written, it goes through a process like painting it onto a canvas, and then
> being scraped back off as coloured pixels and "safe" metadata.
>

Indeed, if that's what it takes.. like the addImageFromCanvas() suggestion
below. Regarding that suggestion you asked:


> Is it more than syntactic sugar?
>
>
If we allow adding image data as blobs, the "normal" way with
clipboardData.items.add() it would be just a convenience method. Since
Daniel Cheng has serious concerns and good arguments against allowing that,
something like addImageFromCanvas() might be a workaround that would let
users put images on the clipboard in a safe way.. If we have neither, I
guess we'll see data:image/jpeg URLs placed on the clipboard as plain text.
-Hallvord R.

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

[Chaals McCathie Nevile]

I'm just thinking out loud here, but this problem is similar to one  
already faced by email clients, especially those which are web-based...


On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen  
 wrote:



On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:

Currently, the Clipboard API [1] mandates support for a number of  
formats.
Unfortunately, we do not believe it is possible to safely support  
writing a

number of formats to the clipboard:
- image/png
- image/jpg, image/jpeg
- image/gif



Hi Daniel,
I've been pondering this a bit and I think a first step is to split the
list of "mandatory data types" into two: one list for types you must
support reading from the clipboard, and one (smaller) for types you must
support writing to the clipboard. So PNG, JPG et al go in the "support
reading from clipboard" list, and the "support writing" starts out with
text/plain, text/html and text/uri-list - although it would be nice if  
CSV was also considered safe enough.


I'm not sure you should directly read image formats from the clipboard,  
especially if you don't know how they got there. You shouldn't write stuff  
there that can be dangerous, but you really shouldn't read it direct. So  
maybe what happens is that when stuff gets written, it goes through a  
process like painting it onto a canvas, and then being scraped back off as  
coloured pixels and "safe" metadata.


A use case for the latter is the fabled "embedded accessibility" that  
could have made longdesc obsolete in 1997 - although the more likely use  
case for most people is getting the right geospying in their photo stream,  
and proving to the world that their camera clock flashes like a video  
player from 1987.


So essentially we don't restrict what is in the clipboard, but we do put  
restrictions on what we will take out, and if you want to be well-behaved  
you would follow those restrictions before you put anything there. Can we  
safely implement a clean/dirty flag similar to canvas, to help avoid  
double-sanitizing? Is that worth worrying about?



It would also be good if we could come up with an API for safely writing
images to the clipboard. Just playing:
event.clipboardData.addImageFromCanvas(canvasElm, 'image/png')

Hot or not?


Safely DrawMeA(sheep) is certainly worth pondering. Is it more than  
syntactic sugar?


cheers

--
Using Opera's mail client: http://www.opera.com/mail/

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

[Wez]

My 2c inline below:

On 27 July 2015 at 12:03, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:
>
>> Currently, the Clipboard API [1] mandates support for a number of
>> formats. Unfortunately, we do not believe it is possible to safely support
>> writing a number of formats to the clipboard:
>> - image/png
>> - image/jpg, image/jpeg
>> - image/gif
>>
>
> Hi Daniel,
> I've been pondering this a bit and I think a first step is to split the
> list of "mandatory data types" into two: one list for types you must
> support reading from the clipboard, and one (smaller) for types you must
> support writing to the clipboard. So PNG, JPG et al go in the "support
> reading from clipboard" list, and the "support writing" starts out with
> text/plain, text/html and text/uri-list - although it would be nice if CSV
> was also considered safe enough.
>

Do we want to make the distinction between the formats the UA must allow
content to pass-through directly to/from the local clipboard, versus the
ones that it must support setting/getting, but may transcode from/to some
preferred format for? e.g. a UA might support content setting BMP, JPEG,
GIF, etc but only actually place an HBITMAP on the Windows clipboard, and
rely on the OS and/or peer applications to do any necessary conversions
from that?


> It would also be good if we could come up with an API for safely writing
> images to the clipboard. Just playing:
> event.clipboardData.addImageFromCanvas(canvasElm, 'image/png')
>

This seems like a good idea to me, though we then get into the fun game of
what the mandatory formats for this API are, too. :D  And what about a
getImageToCanvas() API?

Hot or not?
>
> -Hallvord R.
>
>

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:

> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gif
>

Hi Daniel,
I've been pondering this a bit and I think a first step is to split the
list of "mandatory data types" into two: one list for types you must
support reading from the clipboard, and one (smaller) for types you must
support writing to the clipboard. So PNG, JPG et al go in the "support
reading from clipboard" list, and the "support writing" starts out with
text/plain, text/html and text/uri-list - although it would be nice if CSV
was also considered safe enough.

It would also be good if we could come up with an API for safely writing
images to the clipboard. Just playing:
event.clipboardData.addImageFromCanvas(canvasElm, 'image/png')

Hot or not?

-Hallvord R.

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

[Wez]

Florian, as I pointed out earlier, this proposal is to remove the
requirement that user agents allow content to set the local system
clipboard directly with certain pre-existing clipboard formats, because
doing so safely is not possible in general. Removing the requirement from
the spec will simply mean that the spec more accurately reflects what is
actually implemented in existing user agents.

Defining how user agents can/should support setting of arbitrary formats is
a separate discussion; user agents don't generally support that - including
not supporting application/octet-stream, which the spec doesn't actually
define the behaviour of! - so it would in effect be a new feature of the
API the behaviour of which would need to be properly specified. Please feel
free to fork this thread if that's something you'd like to propose ideas
for. :)

Thanks!

On Thu, 25 Jun 2015 at 19:13 Florian Bösch  wrote:

> I think you underestimate the integrative need that web-apps will acquire
> and the lengths they will go to faced with a business need to make it work
> once "clipboard API" becomes common developer knowledge.
>

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

[Florian Bösch]

I think you underestimate the integrative need that web-apps will acquire
and the lengths they will go to faced with a business need to make it work
once "clipboard API" becomes common developer knowledge.

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

[Florian Bösch]

My point is that if you leave no other way out, that is what will happen.

On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng  wrote:

> That's the case today already, and I haven't seen this happening.
>
> Daniel
>
> On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch  wrote:
>
>> I'm sure you're aware that you can encode any binary blob as UTF-8
>> text/plain. If you don't support application/octet-stream, then that just
>> becomes the "dumping ground".
>>
>> On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng  wrote:
>>
>>> 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  wrote:
>>>
 Yet you restrict mime-types AND you support application/octet-stream?

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng 
 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 
> 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  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  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  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 
> wrote:
>
>> Surely you realize that if the specification where to state to
>> only "safely" expose data to the c

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

[Daniel Cheng]

I think you're missing the point: there is already no other way out, and
that has not happened.

Daniel

On Thu, Jun 25, 2015 at 11:08 AM Florian Bösch  wrote:

> My point is that if you leave no other way out, that is what will happen.
>
> On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng  wrote:
>
>> That's the case today already, and I haven't seen this happening.
>>
>> Daniel
>>
>> On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch  wrote:
>>
>>> I'm sure you're aware that you can encode any binary blob as UTF-8
>>> text/plain. If you don't support application/octet-stream, then that just
>>> becomes the "dumping ground".
>>>
>>> On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng  wrote:
>>>
 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 
 wrote:

> Yet you restrict mime-types AND you support application/octet-stream?
>
> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng 
> 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 
>> 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  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 
 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  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
>>

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

[Daniel Cheng]

That's the case today already, and I haven't seen this happening.

Daniel

On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch  wrote:

> I'm sure you're aware that you can encode any binary blob as UTF-8
> text/plain. If you don't support application/octet-stream, then that just
> becomes the "dumping ground".
>
> On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng  wrote:
>
>> 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  wrote:
>>
>>> Yet you restrict mime-types AND you support application/octet-stream?
>>>
>>> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng  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  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  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  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  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 
 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 "applica

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

[Florian Bösch]

I'm sure you're aware that you can encode any binary blob as UTF-8
text/plain. If you don't support application/octet-stream, then that just
becomes the "dumping ground".

On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng  wrote:

> 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  wrote:
>
>> Yet you restrict mime-types AND you support application/octet-stream?
>>
>> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng  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  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  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  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  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  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 unenforceab

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

[Daniel Cheng]

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  wrote:

> Yet you restrict mime-types AND you support application/octet-stream?
>
> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng  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  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  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  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  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  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  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 

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

[Florian Bösch]

Yet you restrict mime-types AND you support application/octet-stream?

On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng  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  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  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  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  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  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  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  wrote:
>>>
 On Thu, Jun 25, 2015 at 3:13 PM, Wez  wrote:

> I think there's obvious v

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

[Daniel Cheng]

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  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  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  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  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  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  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  wrote:
>>
>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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 mak

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

[Wez]

It still sounds like you're advocating removing the requirement that UAs
support application/octet-stream (which makes sense, since its behaviour
doesn't seem to be specified anyway).

If you're suggesting something else, please elaborate on what that
something else is. :)

On Thu, 25 Jun 2015 at 16:23 Florian Bösch  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  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  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  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  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  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  wrote:
>>
>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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 yo

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

[Florian Bösch]

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  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  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  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  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  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  wrote:
>
>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>>
>

>>

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

[Wez]

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  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  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  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  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  wrote:

> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>

>>>
>

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

[Florian Bösch]

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  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  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  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  wrote:
>>>
 On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.

>>>
>>

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

[Wez]

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  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  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  wrote:
>>
>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>>>
>>
>

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

[Florian Bösch]

Browsers are very visible applications. Most other applications in
existence tend to work around their foibles in one fashion or another. If
Browsers where to sprout another such foible as to force people to discard
mime-type specification for content because browsers don't let them, it
would give rise to widely confusing and homebrewn workarounds till out of
that broil another mime-type standard emerged that browsers sought to
repress.

On Thu, Jun 25, 2015 at 4:30 PM, Florian Bösch  wrote:

> I'm pretty sure it can't be in the interest of this specification to force
> application authors to bifurcate the mime-type into one that can't be used
> reliably, and another informal one that's prepended to the octet-stream.
> Relevant XKCD quote omitted.
>
> On Thu, Jun 25, 2015 at 4:27 PM, Florian Bösch  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  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  wrote:
>>>
 On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.

>>>
>>
>

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

[Florian Bösch]

I'm pretty sure it can't be in the interest of this specification to force
application authors to bifurcate the mime-type into one that can't be used
reliably, and another informal one that's prepended to the octet-stream.
Relevant XKCD quote omitted.

On Thu, Jun 25, 2015 at 4:27 PM, Florian Bösch  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  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  wrote:
>>
>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>>>
>>
>

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

[Florian Bösch]

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  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  wrote:
>
>> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>>
>

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

[Wez]

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  wrote:

> On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.
>

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

[Florian Bösch]

On Thu, Jun 25, 2015 at 3:13 PM, Wez  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.

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

[Wez]

I don't believe I've said any such thing re jpeg, png and gif... quite the
opposite, in fact.

The point of this thread is that the spec currently *requires* user agents
allow content to supply JPEG, PNG or GIF data directly *to the local
clipboard*, which is risky. We're therefore proposing to remove that
requirement - content can still supply images to the clipboard and the user
agent can still synthesize whatever formats it chooses to.

Whether or not user agents support web content setting other arbitrary
content types (such as OpenEXR) to the local system clipboard is a separate
question - there's nothing in the spec mandating that user agents support
it, nor mandating that they don't - at present each user agent can choose
whether or not to support arbitrary formats.

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.

HTH,

Wez


On Thu, 25 Jun 2015 at 13:56 Florian Bösch  wrote:

> Well let's say some webapp generates an OpenEXR and wants to put it into
> the clipboard as "image/x-exr" which would make sense cause any eventual
> program that'd support OpenEXR would probably look for that mime type.
> You've said you're going to restrict image types to jpeg, png and gif, and
> so my question is, how exactly do you intend to support OpenEXR?
>
> On Thu, Jun 25, 2015 at 2:51 PM, Wez  wrote:
>
>> Sorry Florian, but I don't see what that has to do with whether or not
>> the Clipboard Events spec mandates that web content can generate their own
>> JPEG or PNG and place it directly on the local system clipboard.
>>
>> What is it that you're actually proposing?
>>
>> On Thu, 25 Jun 2015 at 13:31 Florian Bösch  wrote:
>>
>>> No idea. Also doesn't matter jack. There could be some now or in the
>>> future. There's a variety of programs that support HDRi (photoshop,
>>> lightroom, hdri-studio, etc.). It's fairly logical that at some point some
>>> or another variant of HDR format will make its way into clipboards. The
>>> same applies to pretty much any other data format be that a file or
>>> something else.
>>>
>>
>

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

[Florian Bösch]

On Thu, Jun 25, 2015 at 2:58 PM, Florian Bösch  wrote:

> the magic bytes of an OpenEXR?
>

Which is 0x762f3101 btw.

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

[Florian Bösch]

Or should we just place that into "application/octet-stream" and hope
whoever listens for the clipboard scans the magic bytes of an OpenEXR?

On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch  wrote:

> Well let's say some webapp generates an OpenEXR and wants to put it into
> the clipboard as "image/x-exr" which would make sense cause any eventual
> program that'd support OpenEXR would probably look for that mime type.
> You've said you're going to restrict image types to jpeg, png and gif, and
> so my question is, how exactly do you intend to support OpenEXR?
>
> On Thu, Jun 25, 2015 at 2:51 PM, Wez  wrote:
>
>> Sorry Florian, but I don't see what that has to do with whether or not
>> the Clipboard Events spec mandates that web content can generate their own
>> JPEG or PNG and place it directly on the local system clipboard.
>>
>> What is it that you're actually proposing?
>>
>> On Thu, 25 Jun 2015 at 13:31 Florian Bösch  wrote:
>>
>>> No idea. Also doesn't matter jack. There could be some now or in the
>>> future. There's a variety of programs that support HDRi (photoshop,
>>> lightroom, hdri-studio, etc.). It's fairly logical that at some point some
>>> or another variant of HDR format will make its way into clipboards. The
>>> same applies to pretty much any other data format be that a file or
>>> something else.
>>>
>>
>

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

[Florian Bösch]

Well let's say some webapp generates an OpenEXR and wants to put it into
the clipboard as "image/x-exr" which would make sense cause any eventual
program that'd support OpenEXR would probably look for that mime type.
You've said you're going to restrict image types to jpeg, png and gif, and
so my question is, how exactly do you intend to support OpenEXR?

On Thu, Jun 25, 2015 at 2:51 PM, Wez  wrote:

> Sorry Florian, but I don't see what that has to do with whether or not the
> Clipboard Events spec mandates that web content can generate their own JPEG
> or PNG and place it directly on the local system clipboard.
>
> What is it that you're actually proposing?
>
> On Thu, 25 Jun 2015 at 13:31 Florian Bösch  wrote:
>
>> No idea. Also doesn't matter jack. There could be some now or in the
>> future. There's a variety of programs that support HDRi (photoshop,
>> lightroom, hdri-studio, etc.). It's fairly logical that at some point some
>> or another variant of HDR format will make its way into clipboards. The
>> same applies to pretty much any other data format be that a file or
>> something else.
>>
>

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

[Wez]

Sorry Florian, but I don't see what that has to do with whether or not the
Clipboard Events spec mandates that web content can generate their own JPEG
or PNG and place it directly on the local system clipboard.

What is it that you're actually proposing?

On Thu, 25 Jun 2015 at 13:31 Florian Bösch  wrote:

> No idea. Also doesn't matter jack. There could be some now or in the
> future. There's a variety of programs that support HDRi (photoshop,
> lightroom, hdri-studio, etc.). It's fairly logical that at some point some
> or another variant of HDR format will make its way into clipboards. The
> same applies to pretty much any other data format be that a file or
> something else.
>

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

[Florian Bösch]

No idea. Also doesn't matter jack. There could be some now or in the
future. There's a variety of programs that support HDRi (photoshop,
lightroom, hdri-studio, etc.). It's fairly logical that at some point some
or another variant of HDR format will make its way into clipboards. The
same applies to pretty much any other data format be that a file or
something else.

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

[Wez]

Which user agents currently allow content to post OpenEXR to the local
clipboard?

On Wed, 24 Jun 2015 at 19:58 Florian Bösch  wrote:

> No, but the specification doesn't require you to exclude it. So how're
> applications going to swap OpenEXR if you only let em stick in jpegs, pngs
> and gifs?
>
> On Wed, Jun 24, 2015 at 8:46 PM, Wez  wrote:
>
>> I don't think OpenEXR is one of the formats required by the Clipboard
>> Events spec, is it..?
>>
>> On Wed, Jun 24, 2015, 18:49 Florian Bösch  wrote:
>>
>>> And how exactly do you intend to support for instance OpenEXR?
>>>
>>> On Wed, Jun 24, 2015 at 5:44 PM, Wez  wrote:
>>>
 Hallvord,

 Yes, content would be limited to providing text, image etc data to the
 user agent to place on the clipboard, and letting the user agent synthesize
 whatever formats (JPEG, PNG etc) other apps require. That has the advantage
 of preventing malicious content using esoteric flags or features to
 compromise recipients, but conversely means that legitimate content cannot
 use format-specific features, e.g. content would not be able to write a
 JPEG containing a comment block, geo tags or timestamp information.



 Wez


 On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
 hst...@mozilla.com> wrote:

> On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:
>
>> Hallvord,
>>
>> The proposal isn't to remove support for copying/pasting images, but
>> to restrict web content from placing compressed image data in one of 
>> these
>> formats on the clipboard directly - there's no issue with content pasting
>> raw pixels from a canvas, for example, since scope for abusing that to
>> compromise the recipient is extremely limited by comparison to JPEG, PNG 
>> or
>> GIF.
>>
>
> Well, but as far as I can tell we don't currently *have* a way JS can
> place pixels from a canvas on the clipboard (except by putting a piece of
> data labelled as image/png or similar there). So if you're pushing back
> against the idea that JS can place random data on the clipboard and label
> it image/png, how exactly would you propose JS-triggered copy of image 
> data
> to work? Say, from a CANVAS-based image editor?
> -Hallvord
>
>
>>>
>

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

[Florian Bösch]

No, but the specification doesn't require you to exclude it. So how're
applications going to swap OpenEXR if you only let em stick in jpegs, pngs
and gifs?

On Wed, Jun 24, 2015 at 8:46 PM, Wez  wrote:

> I don't think OpenEXR is one of the formats required by the Clipboard
> Events spec, is it..?
>
> On Wed, Jun 24, 2015, 18:49 Florian Bösch  wrote:
>
>> And how exactly do you intend to support for instance OpenEXR?
>>
>> On Wed, Jun 24, 2015 at 5:44 PM, Wez  wrote:
>>
>>> Hallvord,
>>>
>>> Yes, content would be limited to providing text, image etc data to the
>>> user agent to place on the clipboard, and letting the user agent synthesize
>>> whatever formats (JPEG, PNG etc) other apps require. That has the advantage
>>> of preventing malicious content using esoteric flags or features to
>>> compromise recipients, but conversely means that legitimate content cannot
>>> use format-specific features, e.g. content would not be able to write a
>>> JPEG containing a comment block, geo tags or timestamp information.
>>>
>>>
>>>
>>> Wez
>>>
>>>
>>> On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
>>> hst...@mozilla.com> wrote:
>>>
 On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:

> Hallvord,
>
> The proposal isn't to remove support for copying/pasting images, but
> to restrict web content from placing compressed image data in one of these
> formats on the clipboard directly - there's no issue with content pasting
> raw pixels from a canvas, for example, since scope for abusing that to
> compromise the recipient is extremely limited by comparison to JPEG, PNG 
> or
> GIF.
>

 Well, but as far as I can tell we don't currently *have* a way JS can
 place pixels from a canvas on the clipboard (except by putting a piece of
 data labelled as image/png or similar there). So if you're pushing back
 against the idea that JS can place random data on the clipboard and label
 it image/png, how exactly would you propose JS-triggered copy of image data
 to work? Say, from a CANVAS-based image editor?
 -Hallvord


>>

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

[Wez]

I don't think OpenEXR is one of the formats required by the Clipboard
Events spec, is it..?

On Wed, Jun 24, 2015, 18:49 Florian Bösch  wrote:

> And how exactly do you intend to support for instance OpenEXR?
>
> On Wed, Jun 24, 2015 at 5:44 PM, Wez  wrote:
>
>> Hallvord,
>>
>> Yes, content would be limited to providing text, image etc data to the
>> user agent to place on the clipboard, and letting the user agent synthesize
>> whatever formats (JPEG, PNG etc) other apps require. That has the advantage
>> of preventing malicious content using esoteric flags or features to
>> compromise recipients, but conversely means that legitimate content cannot
>> use format-specific features, e.g. content would not be able to write a
>> JPEG containing a comment block, geo tags or timestamp information.
>>
>>
>>
>> Wez
>>
>>
>> On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
>> hst...@mozilla.com> wrote:
>>
>>> On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:
>>>
 Hallvord,

 The proposal isn't to remove support for copying/pasting images, but to
 restrict web content from placing compressed image data in one of these
 formats on the clipboard directly - there's no issue with content pasting
 raw pixels from a canvas, for example, since scope for abusing that to
 compromise the recipient is extremely limited by comparison to JPEG, PNG or
 GIF.

>>>
>>> Well, but as far as I can tell we don't currently *have* a way JS can
>>> place pixels from a canvas on the clipboard (except by putting a piece of
>>> data labelled as image/png or similar there). So if you're pushing back
>>> against the idea that JS can place random data on the clipboard and label
>>> it image/png, how exactly would you propose JS-triggered copy of image data
>>> to work? Say, from a CANVAS-based image editor?
>>> -Hallvord
>>>
>>>
>

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

[Florian Bösch]

And how exactly do you intend to support for instance OpenEXR?

On Wed, Jun 24, 2015 at 5:44 PM, Wez  wrote:

> Hallvord,
>
> Yes, content would be limited to providing text, image etc data to the
> user agent to place on the clipboard, and letting the user agent synthesize
> whatever formats (JPEG, PNG etc) other apps require. That has the advantage
> of preventing malicious content using esoteric flags or features to
> compromise recipients, but conversely means that legitimate content cannot
> use format-specific features, e.g. content would not be able to write a
> JPEG containing a comment block, geo tags or timestamp information.
>
>
>
> Wez
>
>
> On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
> hst...@mozilla.com> wrote:
>
>> On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:
>>
>>> Hallvord,
>>>
>>> The proposal isn't to remove support for copying/pasting images, but to
>>> restrict web content from placing compressed image data in one of these
>>> formats on the clipboard directly - there's no issue with content pasting
>>> raw pixels from a canvas, for example, since scope for abusing that to
>>> compromise the recipient is extremely limited by comparison to JPEG, PNG or
>>> GIF.
>>>
>>
>> Well, but as far as I can tell we don't currently *have* a way JS can
>> place pixels from a canvas on the clipboard (except by putting a piece of
>> data labelled as image/png or similar there). So if you're pushing back
>> against the idea that JS can place random data on the clipboard and label
>> it image/png, how exactly would you propose JS-triggered copy of image data
>> to work? Say, from a CANVAS-based image editor?
>> -Hallvord
>>
>>

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

[Wez]

Hallvord,

Yes, content would be limited to providing text, image etc data to the user
agent to place on the clipboard, and letting the user agent synthesize
whatever formats (JPEG, PNG etc) other apps require. That has the advantage
of preventing malicious content using esoteric flags or features to
compromise recipients, but conversely means that legitimate content cannot
use format-specific features, e.g. content would not be able to write a
JPEG containing a comment block, geo tags or timestamp information.



Wez


On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:
>
>> Hallvord,
>>
>> The proposal isn't to remove support for copying/pasting images, but to
>> restrict web content from placing compressed image data in one of these
>> formats on the clipboard directly - there's no issue with content pasting
>> raw pixels from a canvas, for example, since scope for abusing that to
>> compromise the recipient is extremely limited by comparison to JPEG, PNG or
>> GIF.
>>
>
> Well, but as far as I can tell we don't currently *have* a way JS can
> place pixels from a canvas on the clipboard (except by putting a piece of
> data labelled as image/png or similar there). So if you're pushing back
> against the idea that JS can place random data on the clipboard and label
> it image/png, how exactly would you propose JS-triggered copy of image data
> to work? Say, from a CANVAS-based image editor?
> -Hallvord
>
>

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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 7:51 PM, Wez  wrote:

> Hallvord,
>
> The proposal isn't to remove support for copying/pasting images, but to
> restrict web content from placing compressed image data in one of these
> formats on the clipboard directly - there's no issue with content pasting
> raw pixels from a canvas, for example, since scope for abusing that to
> compromise the recipient is extremely limited by comparison to JPEG, PNG or
> GIF.
>

Well, but as far as I can tell we don't currently *have* a way JS can place
pixels from a canvas on the clipboard (except by putting a piece of data
labelled as image/png or similar there). So if you're pushing back against
the idea that JS can place random data on the clipboard and label it
image/png, how exactly would you propose JS-triggered copy of image data to
work? Say, from a CANVAS-based image editor?
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn 
wrote:

> I don't think the clipboard should forbid inserting image data, there's so
> many ways to compromise desktop software. ex. pasting text/html into
> Mail.app might even do it. This API shouldn't be trying to prevent that.
>

Well, the only *really* foolproof way to avoid software vulnerabilities is
not using a computer ;).
I'd still like to see concrete suggestions (like suggested algorithms or
clipboardData methods) that we might consider for a safer solution - if we
can come up with any.
-Hallvord

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

[Paul Libbrecht]

Hello all,

I think a good solution would then be that UAs do a transcoding, or?
(so the spec should recommend doing it)

I understand that the right-menu "copy image" function has the same
problem except if that one does transcoding (and it probably does, to
offer more native flavours).

That would work fine against attacking pictures that would overflow some
older picture processors.
For those graphic freaks which need the exact bytes (e.g. with a
particular profile etc), I think they can expect the web-app to offer a
download for which there's enough dialogs and protection.

Whether an unfiltered picture file should be expected by copy after some
security-dialog-confirmed process, I do not know. Maybe using
octet-stream is the solution?

thanks

Paul

On 11/06/15 08:31, Hallvord Reiar Michaelsen Steen wrote:
> On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  > wrote:
>
> Currently, the Clipboard API [1] mandates support for a number of
> formats. Unfortunately, we do not believe it is possible to safely
> support writing a number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gif
>
> copying images to the clipboard is an important use case. Do you have
> any suggestions for how we could meet this use case in a safer way?
> For example, would it be safe and easy to add a little bit of "magic"
> to make
>
> clipboardData.items.add(canvasElement)
>
> put a PNG on the clipboard? Perhaps copying a rendered imgElement
> should work too?
> -Hallvord



signature.asc
Description: OpenPGP digital signature

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

[Jonathan Kingston]

Is it worth making the user agent prompt the user to confirm the copy if it
detects anything that isn't text?

That is not as bad as disabling a feature when certain input is used
however it would contribute to more error blindness.

Perhaps there should be a note under security considerations that the user
agent should let the underlying OS / antivirus check the copied text.

On Sat, Jun 13, 2015 at 2:56 AM James M. Greene 
wrote:

> On Jun 11, 2015 2:02 PM, "Elliott Sprehn"  wrote:
> >
> > I don't think the clipboard should forbid inserting image data, there's
> so many ways to compromise desktop software. ex. pasting text/html into
> Mail.app might even do it. This API shouldn't be trying to prevent that.
>
> +1, thank you!
>
> ~~James
>

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

[James M. Greene]

On Jun 11, 2015 2:02 PM, "Elliott Sprehn"  wrote:
>
> I don't think the clipboard should forbid inserting image data, there's
so many ways to compromise desktop software. ex. pasting text/html into
Mail.app might even do it. This API shouldn't be trying to prevent that.

+1, thank you!

~~James

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

[Elliott Sprehn]

On Thu, Jun 11, 2015 at 10:51 AM, Wez  wrote:

> Hallvord,
>
> The proposal isn't to remove support for copying/pasting images, but to
> restrict web content from placing compressed image data in one of these
> formats on the clipboard directly - there's no issue with content pasting
> raw pixels from a canvas, for example, since scope for abusing that to
> compromise the recipient is extremely limited by comparison to JPEG, PNG or
> GIF.
>
> The UA is still at liberty to synthesize these formats itself, based on
> the raw imagery provided by the content, to populate the clipboard with
> formats that other applications want.
>
>
>
I don't think the clipboard should forbid inserting image data, there's so
many ways to compromise desktop software. ex. pasting text/html into
Mail.app might even do it. This API shouldn't be trying to prevent that.

- E

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

[Florian Bösch]

On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng  wrote:
>
> On Thu, Jun 11, 2015 at 11:13 AM Florian Bösch  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.
>
What about raster image formats the browser doesn't happen to implement.

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

[Daniel Cheng]

On Thu, Jun 11, 2015 at 12:53 AM Florian Bösch  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  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 
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  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.

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

[Florian Bösch]

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

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

[Wez]

Hallvord,

The proposal isn't to remove support for copying/pasting images, but to
restrict web content from placing compressed image data in one of these
formats on the clipboard directly - there's no issue with content pasting
raw pixels from a canvas, for example, since scope for abusing that to
compromise the recipient is extremely limited by comparison to JPEG, PNG or
GIF.

The UA is still at liberty to synthesize these formats itself, based on the
raw imagery provided by the content, to populate the clipboard with formats
that other applications want.

HTH,

Wez


On 10 June 2015 at 23:31, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:
>
>> Currently, the Clipboard API [1] mandates support for a number of
>> formats. Unfortunately, we do not believe it is possible to safely support
>> writing a number of formats to the clipboard:
>> - image/png
>> - image/jpg, image/jpeg
>> - image/gif
>>
>
> Hi Daniel,
> copying images to the clipboard is an important use case. Do you have any
> suggestions for how we could meet this use case in a safer way? For
> example, would it be safe and easy to add a little bit of "magic" to make
>
> clipboardData.items.add(canvasElement)
>
> put a PNG on the clipboard? Perhaps copying a rendered imgElement should
> work too?
> -Hallvord
>

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

[Florian Bösch]

Besides, if html clipboards will be crippled beyond usability by security
paranoia, you'll just use good'ol flash to copy your random bytes to the
clipboard again.

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

[Florian Bösch]

If you can't put an image/png into a clipboard from JS, you just put it
into an application/octet-stream, which many image editors will load just
happily. If that doesn't work, you just stick your PNG into a plain/text,
which many image editors will still load just fine.

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

[James M. Greene]

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
On Jun 11, 2015 3:14 AM, "Florian Bösch"  wrote:

> Oh, also while you're on crippling things, please also exclude copying any
> text that contains "http://:"; cause that borks skype.
>

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

[Florian Bösch]

Oh, also while you're on crippling things, please also exclude copying any
text that contains "http://:"; cause that borks skype.

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

[Florian Bösch]

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

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

[Florian Bösch]

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

Wouldn't you have to remove ctrl+c,  ->  etc. from
the UA as well?

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  wrote:

> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gif
>

Hi Daniel,
copying images to the clipboard is an important use case. Do you have any
suggestions for how we could meet this use case in a safer way? For
example, would it be safe and easy to add a little bit of "magic" to make

clipboardData.items.add(canvasElement)

put a PNG on the clipboard? Perhaps copying a rendered imgElement should
work too?
-Hallvord

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

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 2:55 PM, Arthur Barstow  wrote:
> Are you suggesting/proposing new normative requirement(s) in the "spec
> proper" and/or new text in the security/privacy considerations [1]?
>
> https://w3c.github.io/clipboard-apis/#other-security-and-privacy-considerations

The former, the algorithms in the specification should be secure by default.


-- 
https://annevankesteren.nl/

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

[Arthur Barstow]

On 6/10/15 5:32 AM, Anne van Kesteren wrote:

On Wed, Jun 10, 2015 at 11:22 AM, Hallvord Reiar Michaelsen Steen
 wrote:

Developing web browsers and their specs means paranoia should be part of
your job description.
It is a concern and I'm not sure how to solve it.

Well we should be able to allow some things here. Either we verify
that it is an image or we only allow images that are exported from
 or some such... But yeah, passing arbitrary bytes seems bad,
there needs to be some amount of validation.


Are you suggesting/proposing new normative requirement(s) in the "spec 
proper" and/or new text in the security/privacy considerations [1]?


[1] 
https://w3c.github.io/clipboard-apis/#other-security-and-privacy-considerations

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

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 11:22 AM, Hallvord Reiar Michaelsen Steen
 wrote:
> Developing web browsers and their specs means paranoia should be part of
> your job description.
> It is a concern and I'm not sure how to solve it.

Well we should be able to allow some things here. Either we verify
that it is an image or we only allow images that are exported from
 or some such... But yeah, passing arbitrary bytes seems bad,
there needs to be some amount of validation.


-- 
https://annevankesteren.nl/

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

[Hallvord Reiar Michaelsen Steen]

On Wed, Jun 10, 2015 at 1:23 AM, Ashley Gullen  wrote:

> The browser could copy a terminal command to wipe the disk, and the user
> could run it. Or copy a URL to a web page that has a known security
> exploit, and then the user pastes it in to the address bar. Maybe we
> shouldn't allow copying anything at all?
>
> Actually I think this is just security by paranoia.
>

Developing web browsers and their specs means paranoia should be part of
your job description.
It is a concern and I'm not sure how to solve it.
-Hallvord

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

[Ashley Gullen]

The browser could copy a terminal command to wipe the disk, and the user
could run it. Or copy a URL to a web page that has a known security
exploit, and then the user pastes it in to the address bar. Maybe we
shouldn't allow copying anything at all?

Actually I think this is just security by paranoia. If pasting corrupt
images in to another app is enough of a problem to warrant concern, that
app should be fixed, rather than hobble the browser.
On 9 Jun 2015 21:23, "Daniel Cheng"  wrote:

> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  wrote:
>
>>  Daniel,
>>
>> this does not make sense to me.
>>
>> All these image parsers exploits can be triggered by an img tag, or?
>> Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
>> XHTML, ...) in markup.
>>
>
> Sure. That's why Chrome only decodes images in sandboxed processes like
> the renderer.
>
>
>>
>> There's absolutely no difference in the mistrust we should have between
>> content brought by an HTML page and content brought by a JavaScript, or?
>> Hence we should just not accept the reason of knowing of broken parsers to
>> be a reason to change the standards!
>>
>
> The difference is that "copy image to clipboard" never writes a
> GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw
> decoded bitmap from the renderer, validates the size information and some
> other stuff, and then writes it to the clipboard as a bitmap of the
> appropriate format.
>
> On the other hand, supporting this from JS means the untrusted renderer
> would get to control and place arbitrary GIF/JPG/PNG into the clipboard.
> It's not really feasible to do any corresponding validation that the data
> isn't bad.
>
>
>>
>> If, as a president, you need to decide to change the roads because a
>> particular car was built massively and needs a particularirty of your
>> roads, you would also find it nonsense, or? You're making me feel like
>> France which did this for a particular type of trains which required to
>> change all platforms because their ordered trains were already built too
>> wide
>>
>
> It's unfortunate, but I doubt any native apps attempt to securely decode
> images. Previously, it didn't matter, since the clipboard content came from
> other native apps, and if you can't trust other native apps, you're kind of
> hosed anyway. However, going from web content -> native crosses a security
> boundary, which means these sort of issues need to be taken into
> consideration.
>
>
>
>>
>> Paul
>>
>>
>> On 9/06/15 21:15, Daniel Cheng wrote:
>>
>> I'm not against considering more formats to be dangerous. =)
>>
>>  In particular:
>> JS: I'm not support what context we'd ever want to support this, since we
>> go out of our way to try prevent XSS in HTML pastes.
>>  XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
>> bugs on a semi-regular basis.
>>
>>  Daniel
>>
>>  On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>>
>>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>>> > Currently, the Clipboard API [1] mandates support for a number of
>>> formats. Unfortunately, we do not believe it is possible to safely support
>>> writing a
>>> > number of formats to the clipboard:
>>> > - image/png
>>> > - image/jpg, image/jpeg
>>> > - image/gif
>>> >
>>> > If these types are supported, malicious web content can trivially
>>> write a malformed GIF/JPG/PNG to the clipboard and trigger code execution
>>> when
>>> > pasting in a program with a vulnerable image decoder. This provides a
>>> trivial way to bypass the sandbox that web content is usually in.
>>> >
>>> > Given this, I'd like to propose that we remove the above formats from
>>> the list of mandatory data types, and avoid adding support for any more
>>> complex
>>> > formats.
>>> >
>>> > Daniel
>>> >
>>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>>
>>>
>>> Why would text/html, application/xhtml+xml, image/svg+xml,
>>> application/xml, text/xml, application/javascript
>>> be any safer if the program which the data is pasted to has vulnerable
>>> html/xml/js parsing?
>>>
>>>
>>> -Olli
>>>
>>>
>>

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

[Paul Libbrecht]

But then it goes even further with just about any type for which broken
parsers exists.
HTML is certainly a good example since its very diversely implemented.

An application that lives on a desktop and fails on some images would be
exposing its user if the user downloads a content and opens it with the
application.  Is the difference that the browser warns the user that the
picture has been downloaded? I've never seen a warning about a
downloaded picture.

Paul



On 9/06/15 23:25, Wez wrote:
> IIUC that approach won't help, because the problem here is not
> necessarily invalid/malformed data, but even valid data that some
> decoders fail to handle gracefully.
>
> On 9 June 2015 at 14:13, Paul Libbrecht  > wrote:
>
> On 9/06/15 23:08, Daniel Cheng wrote:
>>
>> So the solution is to require that browsers that make known
>> media-types in the clipboard actually parse it for its value?
>> That sounds doable (and probably even useful: e.g. put other
>> picture flavours in case of a pictures).
>>
>> I don't think I understand what this means.
> Since the browser is what would act on behalf of JS when putting a
> given data into the clipboard, it could check that this data is
> well formed and maybe matches the patterns of known exploits.
>
> paul
>
>



signature.asc
Description: OpenPGP digital signature

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

[Wez]

IIUC that approach won't help, because the problem here is not necessarily
invalid/malformed data, but even valid data that some decoders fail to
handle gracefully.

On 9 June 2015 at 14:13, Paul Libbrecht  wrote:

>  On 9/06/15 23:08, Daniel Cheng wrote:
>
>  So the solution is to require that browsers that make known media-types
>> in the clipboard actually parse it for its value? That sounds doable (and
>> probably even useful: e.g. put other picture flavours in case of a
>> pictures).
>>
> I don't think I understand what this means.
>
> Since the browser is what would act on behalf of JS when putting a given
> data into the clipboard, it could check that this data is well formed and
> maybe matches the patterns of known exploits.
>
> paul
>

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

[Paul Libbrecht]

On 9/06/15 23:08, Daniel Cheng wrote:
>
> So the solution is to require that browsers that make known
> media-types in the clipboard actually parse it for its value? That
> sounds doable (and probably even useful: e.g. put other picture
> flavours in case of a pictures).
>
> I don't think I understand what this means.
Since the browser is what would act on behalf of JS when putting a given
data into the clipboard, it could check that this data is well formed
and maybe matches the patterns of known exploits.

paul


signature.asc
Description: OpenPGP digital signature

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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 1:25 PM Paul Libbrecht  wrote:

>  Daniel,
>
> I understand now that the mistrust is about parsers that are even further
> and I understand it's an added risk.
>
> So the solution is to require that browsers that make known media-types in
> the clipboard actually parse it for its value? That sounds doable (and
> probably even useful: e.g. put other picture flavours in case of a
> pictures).
>
>
> Paul
>

I don't think I understand what this means.

Daniel


>
>
>
> On 9/06/15 22:20, Daniel Cheng wrote:
>
>  On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  wrote:
>
>>  Daniel,
>>
>> this does not make sense to me.
>>
>> All these image parsers exploits can be triggered by an img tag, or?
>> Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
>> XHTML, ...) in markup.
>>
>
>  Sure. That's why Chrome only decodes images in sandboxed processes like
> the renderer.
>
>
>>
>> There's absolutely no difference in the mistrust we should have between
>> content brought by an HTML page and content brought by a JavaScript, or?
>> Hence we should just not accept the reason of knowing of broken parsers to
>> be a reason to change the standards!
>>
>
>  The difference is that "copy image to clipboard" never writes a
> GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw
> decoded bitmap from the renderer, validates the size information and some
> other stuff, and then writes it to the clipboard as a bitmap of the
> appropriate format.
>
>  On the other hand, supporting this from JS means the untrusted renderer
> would get to control and place arbitrary GIF/JPG/PNG into the clipboard.
> It's not really feasible to do any corresponding validation that the data
> isn't bad.
>
>
>>
>> If, as a president, you need to decide to change the roads because a
>> particular car was built massively and needs a particularirty of your
>> roads, you would also find it nonsense, or? You're making me feel like
>> France which did this for a particular type of trains which required to
>> change all platforms because their ordered trains were already built too
>> wide
>>
>
>  It's unfortunate, but I doubt any native apps attempt to securely decode
> images. Previously, it didn't matter, since the clipboard content came from
> other native apps, and if you can't trust other native apps, you're kind of
> hosed anyway. However, going from web content -> native crosses a security
> boundary, which means these sort of issues need to be taken into
> consideration.
>
>
>
>>
>> Paul
>>
>>
>> On 9/06/15 21:15, Daniel Cheng wrote:
>>
>> I'm not against considering more formats to be dangerous. =)
>>
>>  In particular:
>> JS: I'm not support what context we'd ever want to support this, since we
>> go out of our way to try prevent XSS in HTML pastes.
>>  XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
>> bugs on a semi-regular basis.
>>
>>  Daniel
>>
>>  On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>>
>>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>>> > Currently, the Clipboard API [1] mandates support for a number of
>>> formats. Unfortunately, we do not believe it is possible to safely support
>>> writing a
>>> > number of formats to the clipboard:
>>> > - image/png
>>> > - image/jpg, image/jpeg
>>> > - image/gif
>>> >
>>> > If these types are supported, malicious web content can trivially
>>> write a malformed GIF/JPG/PNG to the clipboard and trigger code execution
>>> when
>>> > pasting in a program with a vulnerable image decoder. This provides a
>>> trivial way to bypass the sandbox that web content is usually in.
>>> >
>>> > Given this, I'd like to propose that we remove the above formats from
>>> the list of mandatory data types, and avoid adding support for any more
>>> complex
>>> > formats.
>>> >
>>> > Daniel
>>> >
>>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>>
>>>
>>> Why would text/html, application/xhtml+xml, image/svg+xml,
>>> application/xml, text/xml, application/javascript
>>> be any safer if the program which the data is pasted to has vulnerable
>>> html/xml/js parsing?
>>>
>>>
>>> -Olli
>>>
>>>
>>
>

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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 1:17 PM James M. Greene 
wrote:

> Why we would exclude any data formats that the browsers currently already
> support copying today? Definitely not a fan of that idea offhand.
>
> Is it not possible for a malicious image to be displayed (or display as
> broken) in Chrome and allow a user to choose "Copy Image" from that
> element's context menu?
>
See my earlier reply.

> If not, how is that protection/prevention achieved today? Could the same
> process to applied to outgoing copy/cut operations and incoming paste
> operations?
>
> Sincerely,
>James M. Greene
>

Incoming paste isn't the problem, it's just outgoing copy/cut.

Can an implementation really claim to support GIF/JPG/PNG if it has to
decode it to a bitmap and then (potentially lossily) convert it back? Image
encoding is not free either; Chrome has a very poor implementation today to
expose image/png, and you'll find if you try to paste a very large bitmap
(several dozen megapixels), the renderer will stop responding for a period
of time.

Daniel


> On Jun 9, 2015 2:19 PM, "Daniel Cheng"  wrote:
>
>> I'm not against considering more formats to be dangerous. =)
>>
>> In particular:
>> JS: I'm not support what context we'd ever want to support this, since we
>> go out of our way to try prevent XSS in HTML pastes.
>> XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
>> bugs on a semi-regular basis.
>>
>> Daniel
>>
>> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>>
>>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>>> > Currently, the Clipboard API [1] mandates support for a number of
>>> formats. Unfortunately, we do not believe it is possible to safely support
>>> writing a
>>> > number of formats to the clipboard:
>>> > - image/png
>>> > - image/jpg, image/jpeg
>>> > - image/gif
>>> >
>>> > If these types are supported, malicious web content can trivially
>>> write a malformed GIF/JPG/PNG to the clipboard and trigger code execution
>>> when
>>> > pasting in a program with a vulnerable image decoder. This provides a
>>> trivial way to bypass the sandbox that web content is usually in.
>>> >
>>> > Given this, I'd like to propose that we remove the above formats from
>>> the list of mandatory data types, and avoid adding support for any more
>>> complex
>>> > formats.
>>> >
>>> > Daniel
>>> >
>>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>>
>>>
>>> Why would text/html, application/xhtml+xml, image/svg+xml,
>>> application/xml, text/xml, application/javascript
>>> be any safer if the program which the data is pasted to has vulnerable
>>> html/xml/js parsing?
>>>
>>>
>>> -Olli
>>>
>>>

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

[Paul Libbrecht]

Daniel,

I understand now that the mistrust is about parsers that are even
further and I understand it's an added risk.

So the solution is to require that browsers that make known media-types
in the clipboard actually parse it for its value? That sounds doable
(and probably even useful: e.g. put other picture flavours in case of a
pictures).

Paul


On 9/06/15 22:20, Daniel Cheng wrote:
> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  > wrote:
>
> Daniel,
>
> this does not make sense to me.
>
> All these image parsers exploits can be triggered by an img tag, or?
> Similarly for XML using an XHR or some particular XML formats
> (RSS, SVG, XHTML, ...) in markup.
>
>
> Sure. That's why Chrome only decodes images in sandboxed processes
> like the renderer.
>  
>
>
> There's absolutely no difference in the mistrust we should have
> between content brought by an HTML page and content brought by a
> JavaScript, or? Hence we should just not accept the reason of
> knowing of broken parsers to be a reason to change the standards!
>
>
> The difference is that "copy image to clipboard" never writes a
> GIF/JPG/PNG to the clipboard. The trusted browser process grabs the
> raw decoded bitmap from the renderer, validates the size information
> and some other stuff, and then writes it to the clipboard as a bitmap
> of the appropriate format.
>
> On the other hand, supporting this from JS means the untrusted
> renderer would get to control and place arbitrary GIF/JPG/PNG into the
> clipboard. It's not really feasible to do any corresponding validation
> that the data isn't bad.
>  
>
>
> If, as a president, you need to decide to change the roads because
> a particular car was built massively and needs a particularirty of
> your roads, you would also find it nonsense, or? You're making me
> feel like France which did this for a particular type of trains
> which required to change all platforms because their ordered
> trains were already built too wide
>
>
> It's unfortunate, but I doubt any native apps attempt to securely
> decode images. Previously, it didn't matter, since the clipboard
> content came from other native apps, and if you can't trust other
> native apps, you're kind of hosed anyway. However, going from web
> content -> native crosses a security boundary, which means these sort
> of issues need to be taken into consideration.
>
>
>
>
> Paul
>
>
> On 9/06/15 21:15, Daniel Cheng wrote:
>> I'm not against considering more formats to be dangerous. =)
>>
>> In particular:
>> JS: I'm not support what context we'd ever want to support this,
>> since we go out of our way to try prevent XSS in HTML pastes.
>> XML: I wouldn't mind getting rid of this. XML parsers seem to
>> have RCE bugs on a semi-regular basis.
>>
>> Daniel
>>
>> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay > > wrote:
>>
>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>> > Currently, the Clipboard API [1] mandates support for a
>> number of formats. Unfortunately, we do not believe it is
>> possible to safely support writing a
>> > number of formats to the clipboard:
>> > - image/png
>> > - image/jpg, image/jpeg
>> > - image/gif
>> >
>> > If these types are supported, malicious web content can
>> trivially write a malformed GIF/JPG/PNG to the clipboard and
>> trigger code execution when
>> > pasting in a program with a vulnerable image decoder. This
>> provides a trivial way to bypass the sandbox that web content
>> is usually in.
>> >
>> > Given this, I'd like to propose that we remove the above
>> formats from the list of mandatory data types, and avoid
>> adding support for any more complex
>> > formats.
>> >
>> > Daniel
>> >
>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>
>>
>> Why would text/html, application/xhtml+xml, image/svg+xml,
>> application/xml, text/xml, application/javascript
>> be any safer if the program which the data is pasted to has
>> vulnerable html/xml/js parsing?
>>
>>
>> -Olli
>>
>



signature.asc
Description: OpenPGP digital signature

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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  wrote:

>  Daniel,
>
> this does not make sense to me.
>
> All these image parsers exploits can be triggered by an img tag, or?
> Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
> XHTML, ...) in markup.
>

Sure. That's why Chrome only decodes images in sandboxed processes like the
renderer.


>
> There's absolutely no difference in the mistrust we should have between
> content brought by an HTML page and content brought by a JavaScript, or?
> Hence we should just not accept the reason of knowing of broken parsers to
> be a reason to change the standards!
>

The difference is that "copy image to clipboard" never writes a GIF/JPG/PNG
to the clipboard. The trusted browser process grabs the raw decoded bitmap
from the renderer, validates the size information and some other stuff, and
then writes it to the clipboard as a bitmap of the appropriate format.

On the other hand, supporting this from JS means the untrusted renderer
would get to control and place arbitrary GIF/JPG/PNG into the clipboard.
It's not really feasible to do any corresponding validation that the data
isn't bad.


>
> If, as a president, you need to decide to change the roads because a
> particular car was built massively and needs a particularirty of your
> roads, you would also find it nonsense, or? You're making me feel like
> France which did this for a particular type of trains which required to
> change all platforms because their ordered trains were already built too
> wide
>

It's unfortunate, but I doubt any native apps attempt to securely decode
images. Previously, it didn't matter, since the clipboard content came from
other native apps, and if you can't trust other native apps, you're kind of
hosed anyway. However, going from web content -> native crosses a security
boundary, which means these sort of issues need to be taken into
consideration.



>
> Paul
>
>
> On 9/06/15 21:15, Daniel Cheng wrote:
>
> I'm not against considering more formats to be dangerous. =)
>
>  In particular:
> JS: I'm not support what context we'd ever want to support this, since we
> go out of our way to try prevent XSS in HTML pastes.
>  XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
> bugs on a semi-regular basis.
>
>  Daniel
>
>  On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>
>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>> > Currently, the Clipboard API [1] mandates support for a number of
>> formats. Unfortunately, we do not believe it is possible to safely support
>> writing a
>> > number of formats to the clipboard:
>> > - image/png
>> > - image/jpg, image/jpeg
>> > - image/gif
>> >
>> > If these types are supported, malicious web content can trivially write
>> a malformed GIF/JPG/PNG to the clipboard and trigger code execution when
>> > pasting in a program with a vulnerable image decoder. This provides a
>> trivial way to bypass the sandbox that web content is usually in.
>> >
>> > Given this, I'd like to propose that we remove the above formats from
>> the list of mandatory data types, and avoid adding support for any more
>> complex
>> > formats.
>> >
>> > Daniel
>> >
>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>
>>
>> Why would text/html, application/xhtml+xml, image/svg+xml,
>> application/xml, text/xml, application/javascript
>> be any safer if the program which the data is pasted to has vulnerable
>> html/xml/js parsing?
>>
>>
>> -Olli
>>
>>
>

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

[James M. Greene]

Why we would exclude any data formats that the browsers currently already
support copying today? Definitely not a fan of that idea offhand.

Is it not possible for a malicious image to be displayed (or display as
broken) in Chrome and allow a user to choose "Copy Image" from that
element's context menu?

If not, how is that protection/prevention achieved today? Could the same
process to applied to outgoing copy/cut operations and incoming paste
operations?

Sincerely,
   James M. Greene
On Jun 9, 2015 2:19 PM, "Daniel Cheng"  wrote:

> I'm not against considering more formats to be dangerous. =)
>
> In particular:
> JS: I'm not support what context we'd ever want to support this, since we
> go out of our way to try prevent XSS in HTML pastes.
> XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
> bugs on a semi-regular basis.
>
> Daniel
>
> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>
>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>> > Currently, the Clipboard API [1] mandates support for a number of
>> formats. Unfortunately, we do not believe it is possible to safely support
>> writing a
>> > number of formats to the clipboard:
>> > - image/png
>> > - image/jpg, image/jpeg
>> > - image/gif
>> >
>> > If these types are supported, malicious web content can trivially write
>> a malformed GIF/JPG/PNG to the clipboard and trigger code execution when
>> > pasting in a program with a vulnerable image decoder. This provides a
>> trivial way to bypass the sandbox that web content is usually in.
>> >
>> > Given this, I'd like to propose that we remove the above formats from
>> the list of mandatory data types, and avoid adding support for any more
>> complex
>> > formats.
>> >
>> > Daniel
>> >
>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>
>>
>> Why would text/html, application/xhtml+xml, image/svg+xml,
>> application/xml, text/xml, application/javascript
>> be any safer if the program which the data is pasted to has vulnerable
>> html/xml/js parsing?
>>
>>
>> -Olli
>>
>>

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

[Paul Libbrecht]

Daniel,

this does not make sense to me.

All these image parsers exploits can be triggered by an img tag, or?
Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
XHTML, ...) in markup.

There's absolutely no difference in the mistrust we should have between
content brought by an HTML page and content brought by a JavaScript, or?
Hence we should just not accept the reason of knowing of broken parsers
to be a reason to change the standards!

If, as a president, you need to decide to change the roads because a
particular car was built massively and needs a particularirty of your
roads, you would also find it nonsense, or? You're making me feel like
France which did this for a particular type of trains which required to
change all platforms because their ordered trains were already built too
wide

Paul

On 9/06/15 21:15, Daniel Cheng wrote:
> I'm not against considering more formats to be dangerous. =)
>
> In particular:
> JS: I'm not support what context we'd ever want to support this, since
> we go out of our way to try prevent XSS in HTML pastes.
> XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
> bugs on a semi-regular basis.
>
> Daniel
>
> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  > wrote:
>
> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
> > Currently, the Clipboard API [1] mandates support for a number
> of formats. Unfortunately, we do not believe it is possible to
> safely support writing a
> > number of formats to the clipboard:
> > - image/png
> > - image/jpg, image/jpeg
> > - image/gif
> >
> > If these types are supported, malicious web content can
> trivially write a malformed GIF/JPG/PNG to the clipboard and
> trigger code execution when
> > pasting in a program with a vulnerable image decoder. This
> provides a trivial way to bypass the sandbox that web content is
> usually in.
> >
> > Given this, I'd like to propose that we remove the above formats
> from the list of mandatory data types, and avoid adding support
> for any more complex
> > formats.
> >
> > Daniel
> >
> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>
>
> Why would text/html, application/xhtml+xml, image/svg+xml,
> application/xml, text/xml, application/javascript
> be any safer if the program which the data is pasted to has
> vulnerable html/xml/js parsing?
>
>
> -Olli
>



signature.asc
Description: OpenPGP digital signature

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

[Daniel Cheng]

I'm not against considering more formats to be dangerous. =)

In particular:
JS: I'm not support what context we'd ever want to support this, since we
go out of our way to try prevent XSS in HTML pastes.
XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs
on a semi-regular basis.

Daniel

On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:

> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
> > Currently, the Clipboard API [1] mandates support for a number of
> formats. Unfortunately, we do not believe it is possible to safely support
> writing a
> > number of formats to the clipboard:
> > - image/png
> > - image/jpg, image/jpeg
> > - image/gif
> >
> > If these types are supported, malicious web content can trivially write
> a malformed GIF/JPG/PNG to the clipboard and trigger code execution when
> > pasting in a program with a vulnerable image decoder. This provides a
> trivial way to bypass the sandbox that web content is usually in.
> >
> > Given this, I'd like to propose that we remove the above formats from
> the list of mandatory data types, and avoid adding support for any more
> complex
> > formats.
> >
> > Daniel
> >
> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>
>
> Why would text/html, application/xhtml+xml, image/svg+xml,
> application/xml, text/xml, application/javascript
> be any safer if the program which the data is pasted to has vulnerable
> html/xml/js parsing?
>
>
> -Olli
>
>

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

[Olli Pettay]

On 06/09/2015 09:39 PM, Daniel Cheng wrote:

Currently, the Clipboard API [1] mandates support for a number of formats. 
Unfortunately, we do not believe it is possible to safely support writing a
number of formats to the clipboard:
- image/png
- image/jpg, image/jpeg
- image/gif

If these types are supported, malicious web content can trivially write a 
malformed GIF/JPG/PNG to the clipboard and trigger code execution when
pasting in a program with a vulnerable image decoder. This provides a trivial 
way to bypass the sandbox that web content is usually in.

Given this, I'd like to propose that we remove the above formats from the list 
of mandatory data types, and avoid adding support for any more complex
formats.

Daniel

[1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1



Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, 
text/xml, application/javascript
be any safer if the program which the data is pasted to has vulnerable 
html/xml/js parsing?


-Olli