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

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

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

> 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

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

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

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

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,

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

(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

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

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

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch 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:

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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