Re: [clipboard] navigator.registerClipboardFormats( ... )
On Wed, Jul 22, 2015 at 12:27 PM Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our what about clipboard data from various native
applications? conundrum. The proposal is to let a page indicate what
native clipboard identifiers it is interested in handling:
registerClipboardFormats({
application/vnd.mathsoft.equation+xml:[
XMCD Format, //Windows handle
MCD Format, //old Windows handle with the same format
XMCD_FORMAT, //Linux handle
com.mathsoft.xml], // OSX handle
application/vnd.mathsoft.equation.meta+xml:[
Provenance Data, //windows handle
PROVENANCE_DATA, //Linux handle
com.mathsoft.pd] // OSX handle
});
//returns:
//{
// application/vnd.mathsoft.equation+xml:true,
// application/vnd.mathsoft.equation.meta+xml:true
//}
And my current understanding of how this work work is
https://github.com/w3c/clipboard-apis/issues/9#issuecomment-123829662 :
What happens under the hood here is basically:
The UA has a registry mapping the supported native clipboard types to the
MIME types used for the clipboard API. For example, on Windows one of the
entries is probably 'text/html' - 'CF_HTML'
When registerClipboardFormat() is called, for each MIME type (key) in the
dictionary, it will check with the OS if the native clipboard knows about
each format description on the list.
The first matching format description the OS has registered (if any) will
be added to the mapping table
On reading from the clipboard, all data with the descriptions given in our
mapping table will be exposed to JS with the corresponding MIME type.
On writing to the clipboard, all data with a MIME type listed in the
mapping table will be placed on the clipboard with the corresponding native
description.
Right?
I'm not sure if implementors are happy about this. There's some pushback
against allowing web contents to write binary data to the clipboard for
security reasons - if you have vulnerabilities in local software (which is
of course a when, not an if) an attacker can trick you into pasting some
exploit payload into the vulnerable software.
Also, I know that on Windows applications register their clipboard
formats - how does this work on other platforms? Will the OSX clipboard be
able to confirm that com.mathsoft.xml is a known type when the relevant
software is installed?
Comments welcome here or in the Github issue.
-Hallvord R.
editor of https://w3c.github.io/clipboard-apis/
This proposal is very dangerous.
It's not just about the fingerprinting danger discussed in the GitHub
issue. The clipboard is an untyped and unsafe broadcast IPC mechanism. Many
native programs weren't written with the expectation of parsing malformed
data, but exposing this to the web means this assumption won't hold.
DOCX/RTF/PDF are all quite complicated, and common for remote code
execution vulnerabilities to turn up.
In fact, if this proposed API were implemented, web content would be able
to execute arbitrary code even in the absence of a bugs. A Pwn2Own exploit
abused the clipboard to do precisely this:
https://code.google.com/p/chromium/issues/detail?id=352395.
Gating this behind a permission doesn't make this proposal any less
dangerous: the permission may as well be called do anything to your
computer.
Daniel
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 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
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
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
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 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
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.
Clipboard API: remove dangerous formats from mandatory data types
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
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. 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
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
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
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] Dilemma: getData('text/html') and useful CF_HTML quirks
On Thu, Apr 23, 2015 at 1:16 AM Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.
Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as
headers (name:value meta data)
htmlhead/head
body
!--StartFragment--HTML!--EndFragment--
/body
/html
where the StartFragment / EndFragment comment tags are inserted by
implementations writing HTML to the clipboard to show where the actually
selected content starts and ends. Several very common implementations
(including I believe Microsoft Word's) will add tags like STYLE outside of
the StartFragment/EndFragment tags and add rules that may be significant
for rendering the content of the fragment correctly. Also noteworthy is
that the meta data may include a SourceURL property showing the URL of the
page you copied from.
So, because of the significance of the STYLE information and other stuff
outside Start/EndFragment, certain browsers return the full document
including the Start/EndFragment comment tags when a script does
getData('text/html'). This is obviously very useful when there's important
stuff outside these tags. It still means scripts have to do extra work to
find those comments and extract the content inside them to know what data a
user actually intended to paste. This also adds a risk that scripts will be
tested only on Windows and authored to require those comments and fail if
they aren't there on other platforms.
Chrome's behavior is to return the literal HTML data, but without the
metadata header when a page calls getData('text/html'). However, if Chrome
is executing the default action of paste, we attempt to parse out the
fragment and only paste the fragment (however, we incorrectly don't include
styles).
Should we, then, standardise returning the full document including
Start/EndFragment comments (basically requiring or encouraging other
platform implementations to start using those comments when serializing
HTML for the OS clipboard) - or should getData() return only what's inside
the Start/EndFragment tags? Are any other important platforms already using
CF_HTML conventions, or would their developers balk at being encouraged to
do so?
CF_HTML is not a format that any other app on any other platform would be
expecting, so you wouldn't be able to just start writing it to the
clipboard on Mac/Linux in place of the original HTML. So there's a bit of a
chicken and egg problem here.
I also can't say I love the CF_HTML format: the markup is a lot easier to
work with when the styles are inlined, etc. Plus pasting style blocks
means there might be collisions in style rules, etc.
On a related topic, I see SourceURL as useful (could be used to properly
attribute citations automatically and such) - it would be nice to
standardise DataTransfer.sourceURL or something like that, to be set when
available.
-Hallvord
(editor of https://w3c.github.io/clipboard-apis/ )
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=586587
You'd have to get all UAs to agree on a data property to use to transfer
this since I don't think using CF_HTML on other platforms is currently
workable.
Re: PSA: publishing new WD of Clipboard API and events on Sept 18
I'm not quite sure what you're asking for here. The clipboard is system global. Why should the spec disallow a user from copying from https://www.example.com and pasting in http://www.ads.com? Daniel On Mon, Sep 15, 2014 at 11:19 AM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Sep 15, 2014 at 4:27 AM, Arthur Barstow art.bars...@gmail.com wrote: This is a heads-up Hallvord intends to publish a WD of Clipboard API and events and he is targeting a publication date of September 18. The ED http://dev.w3.org/2006/webapi/clipops/clipops.html If anyone has any comments or concerns about this plan, please let us know before the 18th. Please forgive my ignorance. But I don't see a requirement that data egressed from the local machine to be protected with SSL/TLS. Also, if the origin uses a secure scheme like HTTPS, then shouldn't the script's also require the same? That is, shouldn't the spec avoid fetching from https://www.example.com and then shipping clipboard data off to http://www.ads.com? Is these intended?
Re: PSA: publishing new WD of Clipboard API and events on Sept 18
Again, what are you trying to defend against? Why is it beneficial to try to block this? Daniel On Sep 15, 2014 3:18 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Sep 15, 2014 at 5:26 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: http://dev.w3.org/2006/webapi/clipops/clipops.html Please forgive my ignorance. But I don't see a requirement that data egressed from the local machine to be protected with SSL/TLS. I can certainly add a note *encouraging* encryption, but it's not something we can require in a meaningful sense - it's several layers away from the parts of the process the spec is about. Also, if the origin uses a secure scheme like HTTPS, then shouldn't the script's also require the same? That is, shouldn't the spec avoid fetching from https://www.example.com and then shipping clipboard data off to http://www.ads.com? As an end user, I would go absolutely nuts if a computer was behaving inconsistently in apparently random ways like that. I'm pretty sure that no matter how security conscious you are, you probably copy and paste data between HTTPS and HTTP pages several times every month.. Having the browser block that because it pretends to know that some random data is important when I know it's not doesn't sound user friendly at all. Well, usually the attacker has to work for a downgrade attack :) Wouldn't it be better for the user if a consistent policy were applied across the board when handling their data? If one leg of the connection uses HTTPS, then all legs must use it. If I were a user and visited a site with HTTPS, then that's what I would expect when moving my data around. Proper handling of the data shifts the onus to the webmaster and developers, but webmasters and developers are in a better position to manage these sorts of things. Its not really a burden on the technology folks - they just have to pay attention to the details. I don't think that's asking too much. And the clipboard standard is new, so its a great opportunity to avoid the patching used to address gaps. If the gaps are addressed early, then they won't be an issue in the future.
Re: [clipboard] Add RTF to the mandatory data types list?
Right now, the default action for copy/cut also populates text/plain on the clipboard if you're copying HTML (I don't think the spec explicitly mentions this, but I'm pretty sure this is how most browsers behave). Given the current discussion, it seems expected that the browser will automatically convert between RTF and HTML. If a user copies markup, the browser should add RTF. If the user pastes RTF, the browser should convert it back into HTML. Implementing this conversion has one major problem: RTF parsing is complicated. The spec is several hundred pages long. Every browser is going to have to add rich text parser that's almost completely unrelated to the web when it already has a perfectly good parser for HTML. In the past, RTF support would have helped text that wanted to include inline images, but there has been progress on solving this without depending on RTF: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0103.html On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? I'm curious about the answer to this as well. I haven't seen any examples raised outside of TextEdit. While TextEdit is widely deployed, is it actually widely used as a rich text editor? I know I just use it as the occasional scratch pad. If there aren't any good examples, I don't think it makes sense to make RTF a mandatory data type. If there are, I still think it'd make more sense to push those editors towards supporting HTML rather than trying to make browsers support RTF. Daniel On Tue, Aug 19, 2014 at 8:17 PM, Karl Dubost k...@la-grange.net wrote: Le 19 août 2014 à 19:36, Hallvord R. M. Steen hst...@mozilla.com a écrit : If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? On MacOSX Test 1: Copy styled text with a link in a Web page (grey and pink text, black background, Big size) into an RTF editor (TextEdit). * Safari - TextEdit: color, size, position and links preserved * Firefox - TextEdit: only size and links are preserved Test 2: Copy styled text from an RTF editor to content editable form http://codepen.io/matt-west/full/gtruC * TextEdit - Safari: Everything is preserved * TextEdit - Firefox: Nothing is preserved, just the text. Checking by inspecting the DOM content in the form in Safari: p style=margin: 0px 0px 10px; font-size: 34px; line-height: normal; font-family: Times; color: rgb(225, 44, 155);foobar/p -- Karl Dubost http://www.la-grange.net/karl/
Re: [clipboard] Add RTF to the mandatory data types list?
On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't necessarily mean we should not add it. I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? Chrome Mac should (though I've never tested this functionality). I think the code for this was inherited from Camino, so Firefox may have this as well. It's not common--it's only implemented on Mac because there's some platform support already for parsing RTF into a NSAttributedString and then dumping the result as HTML. Did anyone ever write a complete RTF parser in JavaScript? If you could read raw RTF data off the clipboard, how would you process it? How likely do you think it is that those who write web editors will go through the efforts and add code to handle RTF paste? -Hallvord
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
On Wed, Feb 12, 2014 at 1:25 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially
since the IE team has done some interesting work in this area and is
arguably ahead of the rest! :-)
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog
[2]), and it was designed as a
simple way for sites to choose DataURI or Blob for otherwise
inaccessible images.
X
As you mention, it is not possible to tell which file/image corresponds
to which img because it’s
really designed as a simple approach for cases where a site wants to
always use blob or dataURI for
images that they couldn’t otherwise access.
That's more or less what I thought, based on the blog post, so thanks for
describing it in detail.
We are considering doing the CID approach as well in the future. It is
nice to have the additional
control of seeing which img src you are changing, and it will likely
work better for copy, not just
paste like convertURL.
Actually, I haven't truly considered the copy case here yet. I've sort of
assumed that given that you can put multiple bits of data on a clipboard,
the various clipboard implementations should already have a way one piece
of data can reference one specific other piece of data - I haven't really
found the technical details here.
I don't actually know of any native clipboard formats that allow data
associated with one format to reference other data in the same operation,
so browsers would have to roll their own implementation/figure out how to
get it to work well with native apps.
Of course it would be nice to support a script that wants to generate
random HTML with embedded files to place on the clipboard (although I think
most of those use cases can already be met by using URLs and assuming that
any software reading HTML from the clipboard can understand URLs..).
However, one can imagine a use case for example with a CANVAS app where the
script wants to copy the state of the CANVAS as an image inside HTML it
places on the clipboard - having the script create src=cid:n type markup,
append files, and make the UA translate that to the platform's native
clipboard implementation's way of referencing one part on the clipboard
from another part..
We believe that convertURL does not block using the CIDs you have in the
current spec.
I suppose not, but perhaps the more relevant question is: should we
standardise convertURL? Would it still have a use case if we take the cid:
route? (And I guess a related question is: given that we've done data: URLs
for a while, how much content will we break if, say, Firefox moves from
data: to cid:? Do we need to make cid: opt-in somehow, like you're doing
with convertURL?)
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample (
http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it
looks like if a user pastes in some HTML that references local images, IE11
automatically captures the referenced files into the clipboard. Then the
page uses msConvertUrl() rewrites references to the src attributes in the
text/html DataTransferItem to reference the blob URLs, right?
Given that the drag data store is in read only mode at this point, it
seems weird to allow mutations at this point.
In addition, from a security perspective, what stops a malicious website
from embedding something like img src=file:///etc/passwd
style=display:none/img in the markup?
To better understand your approach and allow us to help move it forward,
can you give us sample
javascript that a site would use to set the DataTransferItems for HTML
and the related images during copy?
As I said, I have not really considered this use case - so the spec
doesn't actually cover this. If we want to make this work, I suppose the JS
would look somewhat like this?
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No
problem.
// Let's say this game generates a number of PNG graphics from
CANVAS tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
Second, can you provide the javascript for how a site would put them
into the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR
uploads from the paste processing, and shows some intermediate 'loading'
animation or something before it gets the final URLs back from the server.
A bit like this (although some things could be more elegant, like the
insertion of
Re: MathML and Clipboard API and events
When I suggested formats that implementations ought to support, I specifically mentioned image/svg+xml because it was mostly convertible to native types (Windows metafile on Windows, PDF on Mac). I don't think anyone's implemented this conversion, but it's technically possible. On the other hand, MathML doesn't have a corresponding native equivalent on Windows or Mac. You could argue that this is a chicken and egg problem, but without any native format equivalents, there's no good way to map that data. You should still be able to set MathML in the clipboard if you want. It just won't be visible to native apps. Daniel On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote: Hi Halvord, Yes, your rewording sounds like a good direction to me. I still worry that placing plain text on the clipboard along with MathML will result in a lot of apps failing to paste the MathML but doing so would probably be considered a bug in such an app. Thanks for filing the bugs. I suspect that the MathML community would be eager to help define what needs to get stripped out of MathML to maintain security. However, speaking for myself, I do not know what kinds of things are considered dangerous. For example, MathML has markup that lets a math expression act as a hyperlink. Do we need to strip that out completely or is that dependent on the url? If there are guidelines on what is considered dangerous, then we could figure out exactly which MathML constructs need to be pruned. Or is there some other procedure for getting this done? Paul -Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Monday, April 15, 2013 1:50 AM To: public-webapps@w3.org; Paul Topping Subject: Re: MathML and Clipboard API and events Hi Paul, thanks for your comments. Mathematical information This section says MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign in a formula plain-text input. Such a transformation should not be part of a normal copy operation since that would transfer MathML. My concern is that readers get the idea that x 2 should always or often be transformed to x^2. What about saying something like Some applications may want to place plain text alternatives along with MathML formulas on he clipboard, for example to make sure .. ? 10. Mandatory data types I am surprised not to see a MathML type in this list Well, since you mention it.. I've filed a bug ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to your question. If you have comments or information please add (either by replying here or in the bug). Would be great if you could help me understand whether allowing an application to write MathML to the clipboard could expose an app to attacks if the MathML markup is pasted without further processing - see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700 -- Hallvord R. M. Steen Core tester, Opera Software
Re: MathML and Clipboard API and events
On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping pa...@dessci.com wrote: Why would the answer to this question be dictated by the need to convert the MathML format to some other “native” format? I just want my app (native or web) to be able to identify the clipboard data type so it can consume the data as it sees fit. Conversion to some other format is but one thing an app can do with data. If apps can’t identify MathML with confidence, they are stuck with ad hoc sniffing of any non-specific data types that might contain MathML. I might look at the plain text and XML data types to see if they contain “math”, for example. ** Because if there is no native format to convert it too, then every browser is likely to do it differently anyway... which means you're stuck with ad hoc detection of MathML anyway. Like I said, there's nothing that stops you from setting text/mathml on the HTML clipboard today. It just won't have the magic conversion to the native type. ** In some sense MathML does have a native format on Mac and Windows. Microsoft and Design Science (my company) got together years ago and defined one. There are some other companies that support it but it seems like it is hard to get the word out there with a “standard” offered by commercial app vendors. I can't find any information about this native format. And even if there is a native format, that is not the same as having a standard format in the native data transfer object (IDataObject on Windows, NSPasteboard on Mac). If browsers supported MathML rendering and a distinct MathML clipboard type and both were defined by the W3C, it would go a long way to establishing a standard that matters and it would get adopted widely. ** ** Paul ** ** *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel Cheng *Sent:* Monday, April 15, 2013 1:56 PM *To:* Paul Topping *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org *Subject:* Re: MathML and Clipboard API and events ** ** When I suggested formats that implementations ought to support, I specifically mentioned image/svg+xml because it was mostly convertible to native types (Windows metafile on Windows, PDF on Mac). I don't think anyone's implemented this conversion, but it's technically possible. ** ** On the other hand, MathML doesn't have a corresponding native equivalent on Windows or Mac. You could argue that this is a chicken and egg problem, but without any native format equivalents, there's no good way to map that data. ** ** You should still be able to set MathML in the clipboard if you want. It just won't be visible to native apps. ** ** Daniel ** ** On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote:*** * Hi Halvord, Yes, your rewording sounds like a good direction to me. I still worry that placing plain text on the clipboard along with MathML will result in a lot of apps failing to paste the MathML but doing so would probably be considered a bug in such an app. Thanks for filing the bugs. I suspect that the MathML community would be eager to help define what needs to get stripped out of MathML to maintain security. However, speaking for myself, I do not know what kinds of things are considered dangerous. For example, MathML has markup that lets a math expression act as a hyperlink. Do we need to strip that out completely or is that dependent on the url? If there are guidelines on what is considered dangerous, then we could figure out exactly which MathML constructs need to be pruned. Or is there some other procedure for getting this done? Paul -Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Monday, April 15, 2013 1:50 AM To: public-webapps@w3.org; Paul Topping Subject: Re: MathML and Clipboard API and events Hi Paul, thanks for your comments. Mathematical information This section says MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign in a formula plain-text input. Such a transformation should not be part of a normal copy operation since that would transfer MathML. My concern is that readers get the idea that x 2 should always or often be transformed to x^2. What about saying something like Some applications may want to place plain text alternatives along with MathML formulas on he clipboard, for example to make sure .. ? 10. Mandatory data types I am surprised not to see a MathML type in this list Well, since you mention it.. I've filed a bug ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to your question. If you have comments or information please add (either by replying here or in the bug). Would be great if you could help me understand whether allowing an application
Re: MathML and Clipboard API and events
I see. I wasn't aware of that reference since I didn't find it in my searching. In that case, I don't have any particular objection though I don't really know what would needs to be sanitized. Daniel On Mon, Apr 15, 2013 at 4:12 PM, Paul Topping pa...@dessci.com wrote: http://www.w3.org/TR/MathML3/appendixb.html mentions both Mac and Windows formats for MathML. ** ** *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel Cheng *Sent:* Monday, April 15, 2013 3:49 PM *To:* Paul Topping *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org *Subject:* Re: MathML and Clipboard API and events ** ** On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping pa...@dessci.com wrote:*** * Why would the answer to this question be dictated by the need to convert the MathML format to some other “native” format? I just want my app (native or web) to be able to identify the clipboard data type so it can consume the data as it sees fit. Conversion to some other format is but one thing an app can do with data. If apps can’t identify MathML with confidence, they are stuck with ad hoc sniffing of any non-specific data types that might contain MathML. I might look at the plain text and XML data types to see if they contain “math”, for example. Because if there is no native format to convert it too, then every browser is likely to do it differently anyway... which means you're stuck with ad hoc detection of MathML anyway. ** ** Like I said, there's nothing that stops you from setting text/mathml on the HTML clipboard today. It just won't have the magic conversion to the native type. In some sense MathML does have a native format on Mac and Windows. Microsoft and Design Science (my company) got together years ago and defined one. There are some other companies that support it but it seems like it is hard to get the word out there with a “standard” offered by commercial app vendors. I can't find any information about this native format. And even if there is a native format, that is not the same as having a standard format in the native data transfer object (IDataObject on Windows, NSPasteboard on Mac). If browsers supported MathML rendering and a distinct MathML clipboard type and both were defined by the W3C, it would go a long way to establishing a standard that matters and it would get adopted widely. Paul *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel Cheng *Sent:* Monday, April 15, 2013 1:56 PM *To:* Paul Topping *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org *Subject:* Re: MathML and Clipboard API and events When I suggested formats that implementations ought to support, I specifically mentioned image/svg+xml because it was mostly convertible to native types (Windows metafile on Windows, PDF on Mac). I don't think anyone's implemented this conversion, but it's technically possible. On the other hand, MathML doesn't have a corresponding native equivalent on Windows or Mac. You could argue that this is a chicken and egg problem, but without any native format equivalents, there's no good way to map that data. You should still be able to set MathML in the clipboard if you want. It just won't be visible to native apps. Daniel On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote:*** * Hi Halvord, Yes, your rewording sounds like a good direction to me. I still worry that placing plain text on the clipboard along with MathML will result in a lot of apps failing to paste the MathML but doing so would probably be considered a bug in such an app. Thanks for filing the bugs. I suspect that the MathML community would be eager to help define what needs to get stripped out of MathML to maintain security. However, speaking for myself, I do not know what kinds of things are considered dangerous. For example, MathML has markup that lets a math expression act as a hyperlink. Do we need to strip that out completely or is that dependent on the url? If there are guidelines on what is considered dangerous, then we could figure out exactly which MathML constructs need to be pruned. Or is there some other procedure for getting this done? Paul -Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Monday, April 15, 2013 1:50 AM To: public-webapps@w3.org; Paul Topping Subject: Re: MathML and Clipboard API and events Hi Paul, thanks for your comments. Mathematical information This section says MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign in a formula plain-text input. Such a transformation should not be part of a normal copy operation since
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
On Sat, Feb 18, 2012 at 07:28, Hallvord R. M. Steen hallv...@opera.comwrote: On Fri, 17 Feb 2012 19:23:29 +0100, Daniel Cheng dch...@chromium.org wrote: Also, what does it mean to be supported? In new versions of Chrome, any kind of MIME type is supported in the sense that you can set data for any arbitrary type, and it can be understood by any browser that uses the same native conventions (I'd be happy to work with any other developers interested in making sure this works across different browsers on the same computer). That's interesting. How do you do that, on Windows in particular? Have you registered a clipboard format called MIME type of main clipboard part where you store type strings, or something? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ Chrome registers a clipboard format on Windows called Chromium Web Custom MIME Data Format (we do the same thing on Mac and Linux at the moment to keep the various implementations similar), and when we see an attempt to add data of a type which we don't have a native translation for, we just place the string in there. We currently have a bug open to figure out how to standardize the serialization, so we can stop using the Chromium-specific types. I'd like to extend it to binary data at some point too. With respect to enabling copy/cut/paste in context menu items, IE/WebKit have beforecut/beforepaste (both) and beforecopy (WebKit only?) events that fire before a context menu is displayed. I'm not sure how widely used they are though. That being said, it'd be nice to have something that works well for native context menus and custom editing controls created with HTML elements like the one at http://ckeditor.com/demo. Daniel
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Any MIME type support restrictions that apply to clipboard MIME types will
almost certainly apply to DnD MIME types as well. Therefore, it wouldn't
make sense to tie it to ClipboardEvent.
Also, what does it mean to be supported? In new versions of Chrome, any
kind of MIME type is supported in the sense that you can set data for any
arbitrary type, and it can be understood by any browser that uses the same
native conventions (I'd be happy to work with any other developers
interested in making sure this works across different browsers on the same
computer).
Daniel
On Fri, Feb 17, 2012 at 10:10, Paul Libbrecht p...@hoplahup.net wrote:
Hello Hallvord,
I think it is a very good idea if such a method would be available from
the point of view of a web-app author.
I have one concern: media-types are likely to be insufficient and flavour
names, whatever they are on the host platform should be allowed I think.
Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac
should be allowed, I think.
Le 17 févr. 2012 à 18:53, Ryosuke Niwa a écrit :
I like the idea of letting authors dynamically detectthe supported mime
types. But providing methods on the interface object seems rather unusual.
It sounds like ok to me. An alternative would be to have a Capabilities
object...
Also, I'm thinking if there are cases where the supported mime types
change dynamically without reloading the page.
(I hope I patched correctly)
Yes, it does happen: I think I know that in Windows the supported
flavour-names depend on the launched applications. On Mac it depends on the
applications whose descriptor has been loaded (by the Finder I think, it
might also be those that have been launched once).
At least an application download and launch can cause a change in the
supported media-types of the OS.
However, would the browsers be informed of such a change?
Would they be able to consider a given type as being safe and not needing
a sanitization?
paul
Le 17 févr. 2012 à 14:23, Hallvord R. M. Steen a écrit :
Hi,
I have an open issue noted in the spec - seems no implementor has worked
on this yet so I'm throwing it out here to see what you all think.
Given that
a) We can't give a random script access to every format on the clipboard
for security/privacy reasons (per earlier feedback from Chrome/WebKit devs
and common sense)
b) Certain clipboard formats have meta data or special formatting
requirements that mean the implementation needs to do a bit of processing
on reading/writing (thinking of Windows' CF_HTML)
c) Text may apparently be placed on the clipboard in different encodings,
an implementation may have to do conversions
d) Clipboard contents can also be file references, in which case we'll
make the *file* and not the actual clipboard data available
- it's obvious that the implementation needs to do a bit of work to
support reading/writing given types of data from/to the native clipboard.
Hence, there should be a way a script can check if a clipboard format is
registered and whether the implementation allows writing this format to the
clipboard.
My idea (at the moment) is to define a method on an interface (not on
instances, on the interface object itself) like this:
ClipboardEvent.isTypeSupported('mime/type')
or, perhaps:
DataTransfer.isTypeSupported('mime/type')??
(but it's more clipboard-specific and maybe it's confusing to mix it with
the DnD stuff?)
An application can then for example do something like
if( ClipboardEvent.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
// prepare fancyformat content and place on clipboard
}else{
// fall back to for example put xml-data-as-plain-text or
json-data-as-plain-text
}
I'm suggesting to define this method on the interface object because it
helps web applications do feature detection early. It could of course be
defined on instances
addEventListener('copy', function(e){
if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
// prepare fancyformat content and place on clipboard
}else{
// fall back to for example put xml-data-as-plain-text or
json-data-as-plain-text
}
})
but then a feature/compatibility test would have to be deferred until a
point where the user potentially has done a lot of work in the web
application.
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: innerHTML in DocumentFragment
The clipboard events http://www.w3.org/TR/clipboard-apis/ spec has some text about HTML sanitization. It might be good to make sure any work in this area is shared. Daniel On Tue, Nov 8, 2011 at 17:10, Ojan Vafai o...@chromium.org wrote: Providing concise, easy and XSS safe ways to generate a DOM is certainly something we have to solve. I don't think sandbox is the best way to achieve this. Specifically, I don't believe sandbox on iframes actually strips the script elements, does it? It just doesn't execute them. If we want to continue down the string-DOM approach, then I agree with Jonas, we need to define an algorithm for safe innerHTML and use it in all the places where we can currently set HTML. I'm open to supporting this use-case because the XHR pattern is so common. The other solution being proposed for easy, safe DOM creation is quasi-literals, which I believe we should definitely also do. In those cases, you'd have something like: var myDom = html'a href=foo/a'; The browser would provide a built-in html function that returns a DOM and uses the browser's html parser. These are not strings though, so you can't use the response from an XHR here. On Mon, Nov 7, 2011 at 8:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon seddon.r...@gmail.com wrote: On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai o...@chromium.org wrote: I don't really follow. Script won't execute until you append the fragment to the DOM, at which point the fragment itself doesn't go in the DOM, just it's children. So, I'm not really sure what sandboxing on fragments would do. If I was ajaxing in potentially hostile content that had malicious script tags in it it would be ideal to sandbox the content so the HTML parser in the browser would strip the content for me. xhr.responseText = divscript src=//malicious.site/cookieStealer.js/scripth1content/h1/div; var frag = document.createDocumentFragment(); frag.sandbox = ; frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s) will be stripped by the parser. document.body.appendChild(frag); The following article demonstrates the same concept using an iframe with the sandbox attribute set[1]. This to me would also make sense to be extended to fragments. [1] http://community.jboss.org/people/wesleyhales/blog/2011/08/28/fixing-ajax-on-mobile-devices I do think we should add something like this, however I think we should have a more explicit syntax for it. There's an old thread with subject innerStaticHTML in the WHATWG list which discusses this topic and various possible syntaxes. Note that inserting a untrusted piece of HTML into your document is interesting not just when dealing with document fragments. Both div.innerHTML as well as div.insertAdjecentHTML(...) seems like they could use safe variants. In short, I think a separate thread is needed for this :) / Jonas
Re: innerHTML in DocumentFragment
Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? Daniel On Fri, Nov 4, 2011 at 05:54, João Eiras jo...@opera.com wrote: On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren ann...@opera.com wrote: On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-**parsing.html#dom-range-** createcontextualfragmenthttp://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda wants a way of parsing where you do not know the context in advance. This is something I've always wanted, so I always wrote my piece of code to make the task easier. But I do suggest a different solution: Instead of # var f = document.**createDocumentFragment() # f.innerHTML = '...'; which is quite verbose, I would suggest a simpler API, like # var document_fragment_node = parseFragment(markup_fragment, Node contextNode, boolean safe); # var element_node = parseNode(markup_fragment, Node contextNode, boolean safe); # var document_node = parseDocument(markup_fragment, boolean safe); * markup_fragment is the html string, or xml depending on the type of document of the ownerDocument of contextNode. * contextNode is an Element for parsing context and to know the ownerDocument, or if context is not important, the Document which will be the ownerDocument of the resulting fragment * stripScripts is a boolean that tells the parser to strip unsafe content like scripts, event listeners and embeds/objects which would be handled by a 3rd party plugin according to user agent policy. - parseFragment parses a markup fragment which may not have a single root element, hence having siblings, with context. - parseFragment parses a markup fragment which must have a single root element, so the DocumentFragment can be spared. This is usually the most wanted use case. - parseDocument similar to DOMParser but for html. At least for me, an API with these features are everything that I've ever needed. Thanks.
Re: innerHTML in DocumentFragment
In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Daniel On Fri, Nov 4, 2011 at 09:45, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 4, 2011 at 9:33 AM, Daniel Cheng dch...@chromium.org wrote: Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? If I understand your suggestion correctly, then no, that would mean that Yehuda's original example: var frag = document.createDocumentFragment(); frag.innerHTML = trtdhello/td/tr someTable.appendChild(frag) would break - the frag would end up with a table and tbody inside, which is wrong when you then try to insert it into an existing table. ~TJ
Re: innerHTML in DocumentFragment
On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Daniel
Re: innerHTML in DocumentFragment
On Fri, Nov 4, 2011 at 12:15, Yehuda Katz wyc...@gmail.com wrote: Sent from my iPhone On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote: On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Isn't that an argument for changing the in-body insertion mode, or perhaps creating a new insertion mode for contenteditable? Daniel I don't think it's an argument for changing in-body insertion mode, since it feels like a return to the tag soup days of HTML. And simply making contenteditable special doesn't help either--what if you have a read-only view of the data? Daniel
Re: Question about implementing DataTransfer.addElement
On Mon, Oct 10, 2011 at 15:26, Ian Hickson i...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' It seems like setDragImage() does that as well: If the element argument is an img element, then set the drag data store bitmap to the element's image (at its intrinsic size); otherwise, set the drag data store bitmap to an image generated from the given element (the exact mechanism for doing so is not currently specified). Doesn't the otherwise clause describe exactly what addElement() does? Daniel
Question about implementing DataTransfer.addElement
What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. However, if we don't implement dynamic drag image updates, doesn't that make it essentially the same as setDragImage()? In that case, what's the point of having addElement(); wouldn't it make more sense to just remove it rather than having two different ways of doing the same thing? Daniel
Re: Question about implementing DataTransfer.addElement
The way drag images work today is we take a snapshot and then hand it off to the system. To support addElement(), we'd need: 1. Some way to detect when that element has changed in visual appearance so we can update the drag image. 2. Some way to actually update the drag image in the middle of a drag. This is (as far as I'm aware) impossible with the documented interface for Windows DnD, and I'm not aware of an undocumented way to do it either. I'm more concerned about the latter, and while I don't believe it's impossible to solve, I think it would be difficult to make performant in case of things like video or other embedded content. Daniel On Fri, Oct 7, 2011 at 15:01, James Robinson jam...@google.com wrote: On Fri, Oct 7, 2011 at 2:56 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng dch...@chromium.org wrote: For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. I would think that it's basically identical, technically, to implementing the element() function from CSS Image Values, which I believe we're planning to do. Not quite. With the element() function the 'live copy' still lives in the page and renders the same way everything else does. My understanding (and Daniel can correct me if I'm wrong) is that drag images do not render the same way due to platform integration concerns and so the technical cost for the two is fairly different. - James ~TJ
Re: [Clipboard API] Copy to clipboard
Why do you need to create an element? Just call execCommand('copy') and
setData('text/html', 'blah') in your copy handler.
Daniel
On Mon, Sep 5, 2011 at 03:57, João Eiras jo...@opera.com wrote:
On Mon, 05 Sep 2011 12:47:28 +0200, Hallvord R. M. Steen
hallv...@opera.com wrote:
On Mon, 05 Sep 2011 02:14:10 +0200, João Eiras joao.ei...@gmail.com
wrote:
Hi !
The spec for setData [1] states that this method when calling from a
cut/copy event sets new data on the clipboard. Unfortunately, this is
insufficient to implement the typical copy to clipboard button
It is indeed. However, you already have things like
document.execCommand('copy') for that.
So lets say I have one of features which let me copy to the clipboard a
snippet of html to embed a video for instance, to paste somewhere.
A script needs to create an element, put the contents inside, wrap a
selection around it, call execCommand('copy'), remove the element and shift
focus back to the button.
Seems a bit overkill. Are you really sure it can't be made simpler ? The
feature is there already, theoretically.
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 17:41, João Eiras joao.ei...@gmail.com wrote:
On , Paul Libbrecht p...@hoplahup.net wrote:
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
To get a table started in the spec, could you give me a small list of
(MIME) types one should mandate the UA to be aware of and be able to
roundtrip to/from native clipboard types? Just off the top of your head?
The typical Web MIME types would of course be something along the lines of
text/plain
text/html
image/jpg
image/gif
image/png
application/xhtml+xml
image/svg+xml
I would like to add all of the 3 MathML flavors:
- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml
More generic
- text/* (I've see in too many places mime-types like text/x-c-src, and
text is text.)
- application/*+xml
- application/*script (ecmascript, javascript)
e.clipboardData.setData('text/x-c-src', 'Foo');
e.clipboardData.setData('text/plain', 'Bar');
e.clipboardData.setData('text/xml', 'Baz');
e.clipboardData.setData('application/xhtml+xml', 'Blah');
Which one should get placed into the native plain text type? Which one gets
to be the definitive XML on the native clipboard?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 04:01, João Eiras joao.ei...@gmail.com wrote: On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled. To me, this sounds like an implementation detail. There are reasons why a UA wouldn't want to pull the contents of the system clipboard into the proxy clipboard. Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 22:07, Hallvord R. M. Steen hallv...@opera.comwrote:
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will be
so rare that throwing is fine? After all, most applications manipulate the
clipboard only in response to user input, which is a pretty modal source of
events, and by definition the paste event will fire in response to user
input within the document..
I think it's fine to simply throw as this typically happens in response to a
user action.
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread. Implementor
feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by the
page, since reading data off the clipboard is a potentially slow operation.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen hallv...@opera.comwrote:
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read on
demand.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Shouldn't we have similar concerns about the text/html content of a drop?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Mon, May 16, 2011 at 21:23, Hallvord R. M. Steen hallv...@opera.comwrote: On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng dch...@chromium.org wrote: I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml What about e.g. RTF? The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. That's dragging from UA to another app, right? So the way to spec it would be during copy/cut processing, the UA should support placing content of these MIME types on the clipboard and translate the type to the OS native equivalent where applicable or something like that? When pulling data from the clipboard X I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. Again the specific list of types for this would be great :-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028926.htmlis a set of types I proposed originally. I omitted GIF/JPG because platform support for GIFs/JPGs isn't as strong, nor is it widely used. Daniel
Re: request for custom clipboard types (Re: clipboard events)
On Mon, May 16, 2011 at 22:57, Ryosuke Niwa rn...@webkit.org wrote: On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen hallv...@opera.comwrote: On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org wrote: A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. I can see there are some really nice and tempting use cases. The problem is the serious downsides.. I would however assume that if we support placing a main XML (or JSON) payload plus alternate- or sub-parts on the clipboard, many custom formats and applications would be able to do their custom business in XML or JSON plus binary blobs. What do you think? I'm also concerned that website may access sensitive information such as local file path and user name via clipboard if we allow arbitrary format. - Ryosuke An XML + JSON payload seems reasonable, but I wonder how long it would take for native apps to interop with web apps. My original plan for adding custom MIME type support to Chromium was to avoid security issues by confining the custom types inside Chromium--they'd work when dragging/dropping or copying/pasting within the browser, but wouldn't be visible to, say, Photoshop. Ideally, there'd be cooperation about the browser vendors so it'd even work across different browsers. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 00:12, Paul Libbrecht p...@hoplahup.net wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml What about e.g. RTF? I feel it fits. paul I don't think we need all 3. Why not just application/mathml+xml? On Tue, May 17, 2011 at 07:03, timeless timel...@gmail.com wrote: On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen hallv...@opera.com wrote: to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml i'd suggest ATOM [application/atom+xml] as a type to support. Browsers generally support it. This is somewhat to the exclusion of RDF and RSS. This provides a way to serve listings and enclosures and things Should application/octet-stream be supported for cases when authors want to pass along binary data? This really doesn't have corresponding native equivalent other than files. The problem with files is the MIME type doesn't really mean anything when you're transferring data out of the browser, so it's difficult to guarantee round tripping. Also, what about vCard? Daniel
Re: risks of custom clipboard types
On Tue, May 17, 2011 at 09:27, Paul Libbrecht p...@activemath.org wrote: On my mac, as far as I know, this can only happen if I copied the the file explicitly (as a file, not as a content). Pasting in some web-page means I want to transmit the information of the clipboard to the page. paul I actually did implement reading arbitrary types from the clipboard/drop at one point on Linux just to see how it'd work. When I copied a file in Nautilus, the full path to the file was available in several different flavors from the clipboard X selection. In order to prevent attacks of this sort, we'd have to determine the full set of types that file managers and other programs could potentially populate with file paths and then explicitly try to clean them of file paths. It's much easier to just go the other direction with a whitelist. On Tue, May 17, 2011 at 09:55, Boris Zbarsky bzbar...@mit.edu wrote: On 5/17/11 12:50 PM, Paul Libbrecht wrote: So you (Mozilla) would not accept to include URL-list as acceptable flavor to be read from the clipboard at paste time if that URL-list contains file URLs. Correct? I believe this is correct, yes. -Boris Chromium and WebKit try to prevent this as well, though we currently have a few cases we still need to fix. File paths aren't necessarily exploitable, but they are a privacy violation. Daniel
Re: risks of custom clipboard types
On Tue, May 17, 2011 at 10:18, Paul Libbrecht p...@hoplahup.net wrote: Le 17 mai 2011 à 19:14, Daniel Cheng a écrit : I actually did implement reading arbitrary types from the clipboard/drop at one point on Linux just to see how it'd work. When I copied a file in Nautilus, the full path to the file was available in several different flavors from the clipboard X selection. In order to prevent attacks of this sort, we'd have to determine the full set of types that file managers and other programs could potentially populate with file paths and then explicitly try to clean them of file paths. It's much easier to just go the other direction with a whitelist. This was certainly at least copied in plain-text as well, or? The risk is here today then already, correct? (even with traditional forms and a quick onchange that makes it invisible). paul It is not because Chromium specifically clears the plain text type if it detects a file drag. Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 14:03, Hallvord R. M. Steen hallv...@opera.comwrote: On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org wrote: I believe this problem is solvable without a spec change. OK. I'd like to put in some non-normative warning or note about this problem though. On Windows and Mac, implementations can use a native clipboard sequence number to determine the contents of the clipboard have changed. Interesting. What, in your view, should the implementation do if it discovers the contents has changed while a paste event thread is running? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ Safari returns an empty string from getData() if this happens. If the caller is using event.clipboardData.items, maybe throw a DOM exception when getAs*() is called. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 16:26, Ryan Seddon seddon.r...@gmail.com wrote: What about image/webp? I'd suggest that if we want to support image formats in the spec, we should try to support the same set that Canvas::toDataURL() does. +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? -Ryan Seddon I don't understand what problem you're trying to solve with application/octet-stream. My bigger concern is that this list of things to support seems to be growing quite rapidly. It'd be nice if we had some sort of criteria to run proposals by, though I have no idea what they'd be. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 20:44, Hallvord R. M. Steen hallv...@opera.comwrote: Do native OS clipboards generally tend to have a data type saying this is some random binary data? That's more or less what I think application/octet-stream indicates on the web. If there isn't a common format to map it to on the OS clipboard side, I don't understand what's being proposed either. (If I had to define common I guess I really mean that the same concept exists in Desktop Win/Mac/*nix clipboard implementations.) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ If I had to map it to something, it'd represent a native file in a clipboard/drag-and-drop operation. Daniel
Re: clipboard events
On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote: Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel
Re: clipboard events
The alternative is sites that attempt to implement this functionality by preventing the default and clearing all the data on the clipboard instead. I'm not really sure that's any better. Daniel On Tue, May 10, 2011 at 00:41, timeless timel...@gmail.com wrote: I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). On 5/10/11, Daniel Cheng dch...@chromium.org wrote: On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote: Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel -- Sent from my mobile device
Concerns regarding cross-origin copy/paste security
There was a recent discussion involving directly exposing the HTML fragment
in a paste to a page, since we're doing the parsing anyway for security
reasons. I have some concerns regarding
http://www.w3.org/TR/clipboard-apis/#cross-origin-copy-paste-of-source-codethough.
From my understanding, we are trying to protect against [1] hidden data
being copied without a user's knowledge and [2] XSS via pasting hostile
HTML. In my opinion, the algorithm as written is either going to remove too
much information or not enough. If it removes too much, the HTML paste is
effectively useless to a client app. If it doesn't remove enough, then the
client app is going to have to sanitize the HTML itself anyway.
I would argue that we should primarily be trying to prevent [1] and leave it
up to web pages to prevent [2]. [2] is no different than using data from any
other untrusted source, like dragging HTML or data from an XHR. It doesn't
make sense to special-case HTML pastes.
In order to achieve [1], the algorithm merely needs to be:
- Remove HTML comments, script, input type=hidden, and all other elements
that have no effect on layout (display: none). Possibly remove applet as
well.
- Remove event handlers, data- and form action attributes.
- Blanking input type=password elements.
To me, it doesn't make sense to remove the other elements:
- OBJECT: Could be used for SVG as I understand.
- FORM: Essentially harmless once the action attribute is cleared.
- INPUT (non-hidden, non-password): Content is already available via
text/plain.
- TEXTAREA: See above.
- BUTTON, INPUT buttons: Most of the content is already available via
text/plain. We can scrub the value attribute if there is concern about that.
- SELECT/OPTION/OPTGROUP: See above.
The draft also does not mention how EMBED elements should be handled.
Finally:
If a script calls getData('text/html'), the implementation supports pasting
HTML, and the data available on the clipboard is from a different origin,
the implementation must sanitize the content by following these steps:
Should this sanitization be done during a copy as well to prevent data a
paste in a non-conforming browser from pasting unexpected things?
Daniel
(resending from the right address, sorry for the spam Hallvord)
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 11:30, Charles McCathieNevile cha...@opera.comwrote:
comments on a couple of timeless' comments.
On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote:
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Yes - should that comment be on HTML5 though, or alternatively is there a
reason not to copy it?
I'm not sure the spec needs to go out of its way to guard against this.
Typically, when writing to a clipboard, you'd clear all the data on the
clipboard before writing the new data; otherwise, you might end up with text
from one window, HTML from another, and a URL from a third. A page that
wanted to stomp on user data could simply do something like
event.clipboardData.setData('text/plain', '').
Daniel
Re: clipboard events
On Mon, Jan 31, 2011 at 01:31, Hallvord R. M. Steen hallv...@opera.com wrote: On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa rn...@webkit.org wrote: Another thing. Should getData guarantee to return the same result each time called within the same event handler? i.e. if some external applications overrode clipboard's data between two calls to getData, what should happen? IMO getData() should be 'live' - i.e. return what's on the clipboard. Do you think that is harder to implement or less performant than the other possible behaviour? I guess it might give less performance, but I doubt repeated calls to getData() is a use case worth optimising for. Thanks again for your feedback :) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ I think having it return live data could result in potential security issues. Couldn't a script loop inside the paste event to keep sniffing out live data? On Mon, Jan 31, 2011 at 01:59, Hallvord R. M. Steen hallv...@opera.comwrote: On Thu, 27 Jan 2011 05:12:58 +0900, Daniel Cheng dch...@chromium.org wrote: Platform capabilities vary. - Windows will be unhappy if you use up all the custom clipboard formats (~65535 or so). There is no way to release formats once registered. - Mac uses UTIs which are strings but not MIME types. - GTK+ seems to support arbitrary MIME types. So for push support, Windows will be unable to natively support arbitrary string types. Thanks. Do you think it is OK to say that we allow arbitrary strings but it may not be available on all platforms, and recommend that script authors stick to known MIME types? I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. When pulling data from the clipboard, I wonder if it may also be a bad idea to expose all the native types. I was working on a patch to do this in WebKit, and it turns out some of the native types leak information about filesystem paths when files are involved in the dragging/paste operation. Do you remember any further details? Seems like something we should mention but I don't know how. Since Linux uses MIME types in its clipboard, I changed the Clipboard implementation in WebKit to directly mirror the contents of the native clipboard. As a result though, pages could access a bunch of random types that included full filesystem paths as part of their data when dragging a file. I suspect that the list of types that happens to leak filesystem paths will vary based on the window manager in use. Because of this, I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. * There is not yet a clear way to push multi-part or alternate formats to the OS clipboard from JS. To use something like iCal, I guess best practise would be to push one human-readable text/plain string for target software without iCal support, and one alternate entry in iCal format. I guess that can be done with DataTransferItem add(in DOMString data, in DOMString type); I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. If the default action is prevented and no data was added to the drag data store, does that imply the clipboard should be cleared? No, that sounds like it should be a no-op to me. Does the spec now imply otherwise? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ From a strict interpretation, preventing the default event should push an empty drag data store onto the clipboard--e.g. erasing it. I believe it should be a no-op instead. Daniel
Re: clipboard events
On Mon, Jan 31, 2011 at 09:00, Ryosuke Niwa rn...@webkit.org wrote: Making it live seems more efficient. If we allowed arbitrary MIME types and spec'ed to always return the same data, then we must copy contents in the clipboard of all MIME types into some internal data structure. This will create a huge performance bottle-neck because even if the page never called getData, we need to make copies of, say, a 5MB jpeg image and the corresponding 100MB bmp along with various other MIME types in the clipboard when firing paste or copy event. - Ryosuke It is definitely less efficient, but it's already how drag-and-drop works in Chrome. On Mon, Jan 31, 2011 at 09:09, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jan 31, 2011 at 3:25 AM, Paul Libbrecht p...@activemath.orgwrote: Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit : The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. This is really really a hard task that I wish neither the spec nor browsers implement. Here's a use case that I would find usefully implemented by this spec. A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. How do we make sure it works across different platforms? I don't think we should be encouraging authors to create website that only works with applications on a particular platform. Le 26 janv. 2011 à 06:26, Hallvord R. M. Steen a écrit : It intends to, but this has two open issues: * I assume that many OS clipboard implementations have an enumerated list of known formats, Just a few of them. (I'm trying to maintain pointers to that here: http://eds.activemath.org/transfers-literature ) I'm not sure if all OSes can handle a request to push text/foobar data to the clipboard. Not an arbitrary mime-type, an arbitrary flavour conforming to the platform's specifics. Does anyone know if we can rely on such functionality being truly cross-platform? Do you mean a mapping from mime-type? No they are unfortunately extremely platform specific. This is the problem. If the format is platform-specific, we'll be exposing platform-dependent API to the Web. If we are to allow arbitrary data types, then I would really like to provide an abstraction around it so that the Web authors don't have to detect platform and do different things for each platform. And if that's unpractical or impossible, then we shouldn't allow arbitrary data types. - Ryosuke I think there's value in exposing arbitrary MIME types. However, my proposal is to effectively limit them to a web sandbox so it's only visible from HTML pages for the reasons that you listed. Exposing arbitrary types between HTML and the native OS has potential security issues as well--a page could access some data that it shouldn't see (e.g. filesystem paths) and it could write malformed data into the clipboard that could crash/corrupt other programs. Daniel
Re: clipboard events
On Tue, Jan 25, 2011 at 21:26, Hallvord R. M. Steen hallv...@opera.comwrote: (Responding to multiple E-mails. Plead guilty to Ianesque behaviour there. Last draft of spec is http://dev.w3.org/2006/webapi/clipops/clipops.html.) On Fri, 24 Dec 2010 07:21:35 +0900, Paul Libbrecht p...@hoplahup.net wrote: - this seems to support the insertion in the clipboard's data of other types than what is currently commonly supported by browsers and the minimum quoted there; this is good and important. I think, for example, that such data as the iCal format would fit very well and be very useful here. It intends to, but this has two open issues: * I assume that many OS clipboard implementations have an enumerated list of known formats, I'm not sure if all OSes can handle a request to push text/foobar data to the clipboard. Does anyone know if we can rely on such functionality being truly cross-platform? Platform capabilities vary. - Windows will be unhappy if you use up all the custom clipboard formats (~65535 or so). There is no way to release formats once registered. - Mac uses UTIs which are strings but not MIME types. - GTK+ seems to support arbitrary MIME types. So for push support, Windows will be unable to natively support arbitrary string types. When pulling data from the clipboard, I wonder if it may also be a bad idea to expose all the native types. I was working on a patch to do this in WebKit, and it turns out some of the native types leak information about filesystem paths when files are involved in the dragging/paste operation. * There is not yet a clear way to push multi-part or alternate formats to the OS clipboard from JS. To use something like iCal, I guess best practise would be to push one human-readable text/plain string for target software without iCal support, and one alternate entry in iCal format. I guess that can be done with DataTransferItem add(in DOMString data, in DOMString type); I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. If the default action is prevented and no data was added to the drag data store, does that imply the clipboard should be cleared? Daniel
