Re: risks of custom clipboard types
Hallvord, The risks is latent but it should be possible for a user to accept that a given site produces a given type. I do not think it is thinkable to avoid platform-dependent code when going to a platform specific OS. Everyone knows platform specific code is harder to maintain and should be avoided as much as possible, nonetheless, lots of it happens. I feel there is no chance, before everyone agrees on a mapping between clipboard flavors and media-types, that platform specific code in scripts for a rich copy and paste can be done. I don't fear for Linux clipboards, they are almost web-like so they have a much better chance than any other OS. Ryosuke, why would sensitive information be readable or writable? paul Le 17 mai 2011 à 06:34, Hallvord R. M. Steen a écrit : Some types will be predefined but the door should stay opened for others. I think what you are asking implies that the UA should get out of the way and just pass the arbitrary string the script gives it to the OS. Then you risk that script authors need to a) start writing platform-detection and OS-specific code b) be forced to handle cases like a Windows OS whose list of possible clipboard types is full I think in particular a) is a very bad consequence. Browser sniffing is an awful failure, holding the web back, preventing compatibility and competition. We should certainly avoid specifying something that will be even worse if we can. (I see scripts detecting Windows and Macs only and not fall back to anything but broken clipboard support for other platforms if we go down this route). Le 17 mai 2011 à 07:57, Ryosuke Niwa a écrit : 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.
Re: risks of custom clipboard types
On Tue, May 17, 2011 at 12:11 AM, Paul Libbrecht p...@activemath.orgwrote: Ryosuke, why would sensitive information be readable or writable? Because it has been available through clipboard. e.g. a popular productivity application puts a local file path in link elements whenever you copy paste table cells. - Ryosuke
Re: risks of custom clipboard types
Le 17 mai 2011 à 09:21, Ryosuke Niwa a écrit : On Tue, May 17, 2011 at 12:11 AM, Paul Libbrecht p...@activemath.org wrote: Ryosuke, why would sensitive information be readable or writable? Because it has been available through clipboard. e.g. a popular productivity application puts a local file path in link elements whenever you copy paste table cells. Interesting. A link in the sense of a web-link with appropriate media-type or flavour is, to my understanding, something ok. It's a path only (it's not access to that path) and it is even formulated for web purpose. I agree it's a risk but since it's only when the user pastes intentionally, I don't think it is a risk to be excluded. Actually, if on my Mac now, I copy a file from the Finder and paste plain text in jEdit, I get the file-name, that's ok I think. A link in the OLE sense has no way to be allowed. You did mean the first form, did you not? paul
Re: risks of custom clipboard types
On Tue, May 17, 2011 at 12:26 AM, Paul Libbrecht p...@activemath.orgwrote: I agree it's a risk but since it's only when the user pastes intentionally, I don't think it is a risk to be excluded. I don't think it's okay. I didn't even save the file and file path was invisible to a user. As a user, I would have never guessed that I was revealing my local file path and thereby my user name when I pasted the content. - Ryosuke
Re: risks of custom clipboard types
Le 17 mai 2011 à 18:20, Ryosuke Niwa a écrit : On Tue, May 17, 2011 at 12:26 AM, Paul Libbrecht p...@activemath.org wrote: I agree it's a risk but since it's only when the user pastes intentionally, I don't think it is a risk to be excluded. I don't think it's okay. I didn't even save the file and file path was invisible to a user. As a user, I would have never guessed that I was revealing my local file path and thereby my user name when I pasted the content. 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
Re: risks of custom clipboard types
Le 17 mai 2011 à 18:39, Boris Zbarsky a écrit : 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. You want to transmit the file contents. You don't want to transmit the location of the file on your disk. Certainly most users don't. To be clear, we (Mozilla) would consider this an unacceptable privacy breach. This is why we (and other browsers) don't send the full path for file inputs too... this case is no different. 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? Ryosuke, do you see other possible flavor exploits with local-paths? (you seemed to have something more precise in mind) paul
Re: risks of custom clipboard types
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
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
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
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: risks of custom clipboard types
Le 17 mai 2011 à 19:31, Daniel Cheng a écrit : 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). It is not because Chromium specifically clears the plain text type if it detects a file drag. So file-flavour is something special that should be always filtered?? (in DnD or in CnP), which should be warned against in the spec? Ryosuke, can you confirm this is the only risk you were talking about? paul
Re: risks of custom clipboard types
Ryosuke Niwa Software Engineer Google Inc. On Tue, May 17, 2011 at 10:48 AM, Paul Libbrecht p...@hoplahup.net wrote: 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). It is not because Chromium specifically clears the plain text type if it detects a file drag. So file-flavour is something special that should be always filtered?? (in DnD or in CnP), which should be warned against in the spec? Ryosuke, can you confirm this is the only risk you were talking about? No. There are some applications that embed sensitive information such as local file path and user name inside a content put into clipboard without notifying the user. As far as I'm concerned, giving websites access to such information is not acceptable. - Ryosuke
Re: risks of custom clipboard types
Le 17 mai 2011 à 20:05, Ryosuke Niwa a écrit : So file-flavour is something special that should be always filtered?? (in DnD or in CnP), which should be warned against in the spec? Ryosuke, can you confirm this is the only risk you were talking about? No. There are some applications that embed sensitive information such as local file path and user name inside a content put into clipboard without notifying the user. As far as I'm concerned, giving websites access to such information is not acceptable. Please be more precise with some applications. There could be some applications that put the email of the user (or the sender of the mail being read) in the plain text variant without the user knowing! paul
