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

[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]

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

[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]

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 mailto:hst...@mozilla.com
 27 août 2015 18:32
 On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht p...@hoplahup.net
 mailto:p...@hoplahup.net 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

[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 dch...@google.com 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  
hst...@mozilla.com 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

[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  
hst...@mozilla.com wrote:



On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com 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

[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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com 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]

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 dch...@google.com 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

[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 pya...@gmail.com 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

[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 pya...@gmail.com 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 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary content-specific
 formats, but IMO the spec should at least give guidance on how to present
 the capability in a safe way.

Which is exactly the core of my question. If you intend to make it say,
safe to put OpenEXR into the clipboard (as opposed to letting an app just
put any bytes there), the UA has to understand OpenEXR. Since I don't see
how the UA can understand every conceivable format in existence both future
and past, I don't see how that should work.

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 pya...@gmail.com 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 w...@google.com 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 pya...@gmail.com 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]

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 pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary content-specific
 formats, but IMO the spec should at least give guidance on how to present
 the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 pya...@gmail.com 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 w...@google.com 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 pya...@gmail.com wrote:

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

 On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com 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 w...@google.com 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 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 pya...@gmail.com wrote:

 the magic bytes of an OpenEXR?


Which is 0x762f3101 btw.

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 w...@google.com 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 pya...@gmail.com 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]

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 pya...@gmail.com 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 w...@google.com 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 pya...@gmail.com 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]

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 w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec mandates
 that user agents let apps place JPEG, PNG or GIF directly on the local
 system clipboard. The spec doesn't currently mandate OpenEXR be supported,
 so it's currently up to individual user agents to decide whether they can
 support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary content-specific
 formats, but IMO the spec should at least give guidance on how to present
 the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 pya...@gmail.com 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 pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give guidance 
 on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary content-specific
 formats, but IMO the spec should at least give guidance on how to present
 the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times in
 the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit without
 a clear indication of what it means in this context) by putting the content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give guidance 
 on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 pya...@gmail.com wrote:

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the clipboard,
 that forces the clipboard user to use application/octet-stream. And in
 consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times in
 the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit without
 a clear indication of what it means in this context) by putting the content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give guidance 
 on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it
 say, safe to put OpenEXR into the clipboard (as opposed to letting an app
 just put any bytes there), the UA has to understand OpenEXR. Since I don't
 see how the UA can understand every conceivable format in existence both
 future and past, I don't see how that should work.

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 w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the clipboard,
 that forces the clipboard user to use application/octet-stream. And in
 consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times
 in the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit without
 a clear indication of what it means in this context) by putting the content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give 
 guidance on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it
 say, safe to put OpenEXR into the clipboard (as opposed to letting an app
 just put any bytes there), the UA has to understand OpenEXR. Since I 
 don't
 see how the UA can understand every conceivable format in existence both
 future and past, I don't see how that should work.

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 pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary content-specific
 formats, but IMO the spec should at least give guidance on how to present
 the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it say,
 safe to put OpenEXR into the clipboard (as opposed to letting an app just
 put any bytes there), the UA has to understand OpenEXR. Since I don't see
 how the UA can understand every conceivable format in existence both future
 and past, I don't see how that should work.

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 pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work around
 the inconvenience, then people will work around the inconvenience. It can't
 be the intention to encourage them work around it. So you've got to either
 not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the clipboard,
 that forces the clipboard user to use application/octet-stream. And in
 consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times
 in the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit without
 a clear indication of what it means in this context) by putting the content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to 
 deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give 
 guidance on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it
 say, safe to put OpenEXR into the clipboard (as opposed to letting an 
 app
 just put any bytes there), the UA has to understand OpenEXR. Since I 
 don't
 see how the UA can understand 

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 dch...@google.com wrote:

 For reasons I've already mentioned, this isn't going to happen because
 there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines of
 gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work around
 the inconvenience, then people will work around the inconvenience. It can't
 be the intention to encourage them work around it. So you've got to either
 not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the clipboard,
 that forces the clipboard user to use application/octet-stream. And in
 consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times
 in the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to 
 deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any 
 other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on 
 the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give 
 guidance on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it
 say, safe to put OpenEXR into the clipboard 

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 pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work around
 the inconvenience, then people will work around the inconvenience. It can't
 be the intention to encourage them work around it. So you've got to either
 not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the clipboard,
 that forces the clipboard user to use application/octet-stream. And in
 consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several times
 in the context of this discussion, where AFAICT the spec actually only
 describes using it as a fall-back for cases of file references on the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit without
 a clear indication of what it means in this context) by putting the content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to 
 deny
 any formats but those a UA can interprete and deem well-formed. If such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give 
 guidance on
 how to present the capability in a safe way.

 Which is exactly the core of my question. If you intend to make it
 say, safe to put OpenEXR into the clipboard (as opposed to letting an 
 app
 just put any bytes there), the UA has to understand OpenEXR. Since I 
 don't
 see how the UA can understand every conceivable 

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 pya...@gmail.com wrote:

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

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote:

 For reasons I've already mentioned, this isn't going to happen because
 there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines of
 gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work around
 the inconvenience, then people will work around the inconvenience. It can't
 be the intention to encourage them work around it. So you've got to either
 not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard to
 know what to do with it. There is also a vast variety of things that could
 find itself in the clipboard in terms of formats, both formal and 
 informal.
 Mime types are one of these things that applications would use to do that.

 If a UA where to restict what mime type you can put into the
 clipboard, that forces the clipboard user to use application/octet-stream.
 And in consequence, that forces any such-willing application to forgoe the
 mime-type information from the OS'es clipboard API and figure out what's 
 in
 it from the content. In turn this would give rise to another way to markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the 
 clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several
 times in the context of this discussion, where AFAICT the spec actually
 only describes using it as a fall-back for cases of file references on 
 the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're
 proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to 
 deny
 any formats but those a UA can interprete and deem well-formed. If such 
 a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any 
 other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and 
 forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on 
 the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com
 wrote:

 On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:

 I think there's obvious value in support for arbitrary
 content-specific formats, but IMO the spec should at least give 
 

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 dch...@google.com 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 pya...@gmail.com wrote:

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

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote:

 For reasons I've already mentioned, this isn't going to happen because
 there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines of
 gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work
 around the inconvenience, then people will work around the inconvenience.
 It can't be the intention to encourage them work around it. So you've got
 to either not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard
 to know what to do with it. There is also a vast variety of things that
 could find itself in the clipboard in terms of formats, both formal and
 informal. Mime types are one of these things that applications would use 
 to
 do that.

 If a UA where to restict what mime type you can put into the
 clipboard, that forces the clipboard user to use 
 application/octet-stream.
 And in consequence, that forces any such-willing application to forgoe 
 the
 mime-type information from the OS'es clipboard API and figure out what's 
 in
 it from the content. In turn this would give rise to another way to 
 markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the 
 clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several
 times in the context of this discussion, where AFAICT the spec actually
 only describes using it as a fall-back for cases of file references on 
 the
 clipboard for which the user agent is unable to determine the file type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're
 proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote:

 Surely you realize that if the specification where to state to only
 safely expose data to the clipboard, this can only be interpreted to 
 deny
 any formats but those a UA can interprete and deem well-formed. If 
 such a
 thing where to be done, that would leave any user of the clipboard no
 recourse but to resort to application/octett-stream and ignore any 
 other
 metadata as the merry magic header guessing game gets underway. For all
 you'd have achieved was to muddle any meaning of the mime-type and 
 forced
 applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly on 
 the
 local system clipboard. The spec doesn't currently mandate OpenEXR be
 supported, so it's currently up to individual user agents to decide 
 whether
 they can support that format safely.

 On Thu, 

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 dch...@google.com 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 pya...@gmail.com 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 dch...@google.com 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 pya...@gmail.com wrote:

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

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com
 wrote:

 For reasons I've already mentioned, this isn't going to happen because
 there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines of
 gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com
 wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because 
 that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around 
 that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended 
 to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work
 around the inconvenience, then people will work around the inconvenience.
 It can't be the intention to encourage them work around it. So you've got
 to either not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard
 to know what to do with it. There is also a vast variety of things that
 could find itself in the clipboard in terms of formats, both formal and
 informal. Mime types are one of these things that applications would 
 use to
 do that.

 If a UA where to restict what mime type you can put into the
 clipboard, that forces the clipboard user to use 
 application/octet-stream.
 And in consequence, that forces any such-willing application to forgoe 
 the
 mime-type information from the OS'es clipboard API and figure out 
 what's in
 it from the content. In turn this would give rise to another way to 
 markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the 
 clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several
 times in the context of this discussion, where AFAICT the spec 
 actually
 only describes using it as a fall-back for cases of file references 
 on the
 clipboard for which the user agent is unable to determine the file 
 type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're
 proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com
 wrote:

 Surely you realize that if the specification where to state to
 only safely expose data to the clipboard, this can only be 
 interpreted to
 deny any formats but those a UA can interprete and deem well-formed. 
 If
 such a thing where to be done, that would leave any user of the 
 clipboard
 no recourse but to resort to application/octett-stream and ignore 
 any
 other metadata as the merry magic header guessing game gets 
 underway. For
 all you'd have achieved was to muddle any meaning of the mime-type 
 and
 forced applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't 

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 pya...@gmail.com 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 dch...@google.com 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 pya...@gmail.com 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 dch...@google.com 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 pya...@gmail.com
 wrote:

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

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com
 wrote:

 For reasons I've already mentioned, this isn't going to happen
 because there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines
 of gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com
 wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because 
 that
 makes it much harder for applications to deal with content. But if 
 that's
 the only way UAs are going to act, then applications will work around 
 that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation 
 pretended to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work
 around the inconvenience, then people will work around the 
 inconvenience.
 It can't be the intention to encourage them work around it. So you've 
 got
 to either not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the
 clipboard to know what to do with it. There is also a vast variety of
 things that could find itself in the clipboard in terms of formats, 
 both
 formal and informal. Mime types are one of these things that 
 applications
 would use to do that.

 If a UA where to restict what mime type you can put into the
 clipboard, that forces the clipboard user to use 
 application/octet-stream.
 And in consequence, that forces any such-willing application to 
 forgoe the
 mime-type information from the OS'es clipboard API and figure out 
 what's in
 it from the content. In turn this would give rise to another way to 
 markup
 mime-types in-line with the content. And once you've forced such 
 ad-hoc
 solutions to emerge for meddling with what people can put in the 
 clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several
 times in the context of this discussion, where AFAICT the spec 
 actually
 only describes using it as a fall-back for cases of file references 
 on the
 clipboard for which the user agent is unable to determine the file 
 type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're
 proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com
 wrote:

 Surely you realize that if the specification where to state to
 only safely expose data to the clipboard, this can only be 
 interpreted to
 deny any formats but those a UA can interprete and deem 
 well-formed. If
 such a thing where to be done, that would leave any user of the 
 clipboard
 no recourse but to resort to application/octett-stream and ignore 
 any
 other metadata as the merry magic header guessing game gets 
 underway. For
 all you'd have achieved was 

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 pya...@gmail.com 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 dch...@google.com 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 pya...@gmail.com wrote:

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

 On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote:

 For reasons I've already mentioned, this isn't going to happen because
 there is no so-called dumping ground.

 No one is going to risk their paste turning into thousands of lines of
 gibberish because they tried to stuff binary data in text/plain.

 Daniel


 On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote:

 No, what I'm saying is that if you restrict mime types (or don't
 explicitly prohibit such restriction), but require
 application/octet-stream, that application/octet-stream becomes the
 undesirable mime-type dumping ground. And that would be bad because that
 makes it much harder for applications to deal with content. But if that's
 the only way UAs are going to act, then applications will work around that
 by using elaborate guessing code based on magic bytes, and perhaps some
 application developers will use their own mime-type annotation pretended 
 to
 the octet-stream.

 If you inconvenience people, but don't make it impossible to work
 around the inconvenience, then people will work around the inconvenience.
 It can't be the intention to encourage them work around it. So you've got
 to either not inconvenience them, or make working around impossible.

 On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote:

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

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

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

 It's very simple. Applications need to know what's in the clipboard
 to know what to do with it. There is also a vast variety of things that
 could find itself in the clipboard in terms of formats, both formal and
 informal. Mime types are one of these things that applications would 
 use to
 do that.

 If a UA where to restict what mime type you can put into the
 clipboard, that forces the clipboard user to use 
 application/octet-stream.
 And in consequence, that forces any such-willing application to forgoe 
 the
 mime-type information from the OS'es clipboard API and figure out 
 what's in
 it from the content. In turn this would give rise to another way to 
 markup
 mime-types in-line with the content. And once you've forced such ad-hoc
 solutions to emerge for meddling with what people can put in the 
 clipboard,
 you'll have no standing to put that geenie back in the bottle, again,
 relevant XKCD quote omitted.

 On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote:

 You've mentioned resorting to application/octet-stream several
 times in the context of this discussion, where AFAICT the spec actually
 only describes using it as a fall-back for cases of file references on 
 the
 clipboard for which the user agent is unable to determine the file 
 type.

 So IIUC you're suggesting that user agents should implement
 application/octet-stream (as is also mandated by the spec, albeit 
 without
 a clear indication of what it means in this context) by putting the 
 content
 on the clipboard as an un-typed file?

 Again, I'm unclear as to what the alternative is that you're
 proposing?

 On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com
 wrote:

 Surely you realize that if the specification where to state to
 only safely expose data to the clipboard, this can only be 
 interpreted to
 deny any formats but those a UA can interprete and deem well-formed. 
 If
 such a thing where to be done, that would leave any user of the 
 clipboard
 no recourse but to resort to application/octett-stream and ignore 
 any
 other metadata as the merry magic header guessing game gets underway. 
 For
 all you'd have achieved was to muddle any meaning of the mime-type and
 forced applications to work around an unenforceable restriction.

 On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote:

 And, again, I don't see what that has to do with whether the spec
 mandates that user agents let apps place JPEG, PNG or GIF directly 
 on the
 local system clipboard. The spec 

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

[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 w...@google.com 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 w...@google.com 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 w...@google.com 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 pya...@gmail.com wrote:

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

 On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com 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 w...@google.com 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 w...@google.com 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 pya...@gmail.com wrote:

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

 On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com 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 w...@google.com 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

[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 dch...@google.com
 mailto:dch...@google.com 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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn espr...@chromium.org
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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 7:51 PM, Wez w...@google.com 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

[James M. Greene]

On Jun 11, 2015 2:02 PM, Elliott Sprehn espr...@chromium.org 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

[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 james.m.gre...@gmail.com
wrote:

 On Jun 11, 2015 2:02 PM, Elliott Sprehn espr...@chromium.org 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

[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 dch...@google.com 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]

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

[Daniel Cheng]

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

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


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

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

 On a further note. If UAs (which are among the more prevalent applications
 out there being used) intentionally disable declaring mime-types for some
 classes of content, so that it can't be pasted into applications that might
 not be equipped to handle those mimetypes, application programmers (such as
 adobe, gimp etc.) will do something else:


- The first 4 bytes of a PNG: \89PNG
- Bytes 9 trough 13 of a JPEG: JFIF
- etc.

 Every notable non text format in common use today contains magic headers
 that make it easy to identify what a file is without having the mimetype or
 file extension.

 Omission of metadata information is

- not going to address your security concern since applications do
routinely read in random bytes and figure out what they are
- it's not going to make applications behave any more securely (or
reliably) as it'll promote even more of them to resort to guessing because
information is omitted

 The clipboard is a key-value store of flavors of data (in this case, MIME
types) to their corresponding data. We're not omitting metadata; we'd block
image/png written by web content from being mapped to its native clipboard
flavor (ATOMs on Windows, UTI on OS X, MIME types on Linux).

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

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

 I can make a plugins for legitimate text/image editors that would override
 default behavior for paste operations to instead execute arbitrary
 processes (e.g. recursively delete the entire working directory) unless the
 parent application is well sandboxed.

 Unless the vendors that establish a lightning fast sanity check for a
 subset of binary data types, I really don't believe this is a positive
 change.

 While we're on it, how about the good ole harbinger of the unknown:
 application/octet-stream? Where do we reasonably draw the line? Will that
 MIME type be blocked? Doesn't seem like there would be any reasonable way
 to scrub it.

 Sincerely,
James M. Greene

Well... sure, if you have a plugin, you can do anything. People (should)
expect plugins to be able to run arbitrary code... because that's what they
are. The point is we don't want pasting an image to be able to do anything
to your system. People would be unpleasantly surprised if pasting an image
results in arbitrary code execution.

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

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


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

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

[Florian Bösch]

On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng dch...@google.com wrote:

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

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

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

What about raster image formats the browser doesn't happen to implement.

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

[Elliott Sprehn]

On Thu, Jun 11, 2015 at 10:51 AM, Wez w...@google.com 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]

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 pya...@gmail.com 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]

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, right-click - copy-image 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 dch...@google.com 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]

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]

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

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 2:55 PM, Arthur Barstow art.bars...@gmail.com 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
hst...@mozilla.com 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
canvas 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

[Hallvord Reiar Michaelsen Steen]

On Wed, Jun 10, 2015 at 1:23 AM, Ashley Gullen ash...@scirra.com 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

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 11:22 AM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com 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
canvas 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

[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

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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net 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 o...@pettay.fi 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 dch...@google.com 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 o...@pettay.fi 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 o...@pettay.fi
 mailto:o...@pettay.fi 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 1:17 PM James M. Greene james.m.gre...@gmail.com
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 dch...@google.com 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 o...@pettay.fi 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:25 PM Paul Libbrecht p...@hoplahup.net 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 p...@hoplahup.net 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 o...@pettay.fi 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]

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]

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 o...@pettay.fi 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 p...@hoplahup.net
 mailto:p...@hoplahup.net 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 o...@pettay.fi
 mailto:o...@pettay.fi 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

[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 dch...@google.com wrote:

 On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net 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 o...@pettay.fi 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

[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 p...@hoplahup.net 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]

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 p...@hoplahup.net
 mailto:p...@hoplahup.net 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