Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
1) if there is a ':' in the URI, you split the URI into scheme and scheme-specific part. No. The first check is is this an absolute file path. That check is done with platform-specific logic: #if windows if the path matches letter:\ or \\... #else if the path starts with a slash #endif Then we load it as an absolute file. Otherwise we load it as a URL relative to file:///[pwd] --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
I'm not sure if we reached a conclusion on this, but I don't like a couple of aspects of the Firefox logic (assuming I understood it correctly). The way I would look at it, the browser always has a current context that indicates the current base to use for relative URIs. In the case where you are launching the browser for the command line, the current base = $CWD (and, implicitly, file://). So, you then get the following algorithm: 1) if there is a ':' in the URI, you split the URI into scheme and scheme-specific part. 2) If there is a scheme: 2.1) If the scheme is a recognized/supported one, dispatch the URL as you would normally. 2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an absolute local file URL 2.3) Else, treat this as a syntax error in the URI 3) If there is no scheme: 3.1) If the URI starts with a /, treat it as a full path relative to the current context (e.g., current scheme, host and port. If your current context is a local filesystem, then treat it as a file:// scheme 3.2) If the URI starts with a \, you're on Windows, and the context is a local file system point, repeat as above, prepending with the current drive 3.3) If the URI doesn't start with a / or a \, then, optionally, check to see if the URI resolves to a valid hostname. This catches the chrome.exe www.google.com use case 3.4) If the URI doesn't resolve to a valid hostname, then interpret it as a relative URL I think this is mostly the same as the FF algorithm, except for 3.3. I agree that trying the local then remote logic is probably going to lead to weird and/or unintended consequences. I could be convinced to omit 3.3, but I don't see any real risks here. The worst case is that you'd have to specify ./www.google.com to open a relative local file called www.google.com, but that's a pretty obscure corner case. I wouldn't add the -url switch, since it is actually misleadingly named (relative URLs are URLs). -- Dirk On Mon, Jan 11, 2010 at 2:23 PM, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke dpra...@chromium.org wrote: So, you then get the following algorithm: 1) if there is a ':' in the URI, you split the URI into scheme and scheme-specific part. 2) If there is a scheme: 2.1) If the scheme is a recognized/supported one, dispatch the URL as you would normally. 2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an absolute local file URL 2.3) Else, treat this as a syntax error in the URI 3) If there is no scheme: 3.1) If the URI starts with a /, treat it as a full path relative to the current context (e.g., current scheme, host and port. If your current context is a local filesystem, then treat it as a file:// scheme 3.2) If the URI starts with a \, you're on Windows, and the context is a local file system point, repeat as above, prepending with the current drive 3.3) If the URI doesn't start with a / or a \, then, optionally, check to see if the URI resolves to a valid hostname. This catches the chrome.exe www.google.com use case 3.4) If the URI doesn't resolve to a valid hostname, then interpret it as a relative URL I'd pretty strongly like to not specify steps like these. They duplicate code we already have for interpreting user input, except with less fidelity. We have quite sophisticated heuristics for how to figure out the correct scheme, parse drive letters, UNC paths, etc. We don't need to write another set. I also don't really care about trying to fix up www.google.com; if it falls out of the existing code, fine, but I wouldn't bother spending time on it. I'm definitely opposed to doing anything like try DNS resolution on X and fall back to Y since it makes the results unpredictable based on your network. What if the user specifies a filename that's also an intranet host? What if the user says www.google.com but the network is currently down -- does the browser show a couldn't open local file www.google.com error? etc. It's enough to simply say run the input through fixup, supplying the CWD as the relative file path base. We have code that can basically take it from there. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Mon, Jan 18, 2010 at 7:16 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke dpra...@chromium.org wrote: So, you then get the following algorithm: 1) if there is a ':' in the URI, you split the URI into scheme and scheme-specific part. 2) If there is a scheme: 2.1) If the scheme is a recognized/supported one, dispatch the URL as you would normally. 2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an absolute local file URL 2.3) Else, treat this as a syntax error in the URI 3) If there is no scheme: 3.1) If the URI starts with a /, treat it as a full path relative to the current context (e.g., current scheme, host and port. If your current context is a local filesystem, then treat it as a file:// scheme 3.2) If the URI starts with a \, you're on Windows, and the context is a local file system point, repeat as above, prepending with the current drive 3.3) If the URI doesn't start with a / or a \, then, optionally, check to see if the URI resolves to a valid hostname. This catches the chrome.exe www.google.com use case 3.4) If the URI doesn't resolve to a valid hostname, then interpret it as a relative URL I'd pretty strongly like to not specify steps like these. They duplicate code we already have for interpreting user input, except with less fidelity. We have quite sophisticated heuristics for how to figure out the correct scheme, parse drive letters, UNC paths, etc. We don't need to write another set. I also don't really care about trying to fix up www.google.com; if it falls out of the existing code, fine, but I wouldn't bother spending time on it. I'm definitely opposed to doing anything like try DNS resolution on X and fall back to Y since it makes the results unpredictable based on your network. What if the user specifies a filename that's also an intranet host? What if the user says www.google.com but the network is currently down -- does the browser show a couldn't open local file www.google.com error? etc. It's enough to simply say run the input through fixup, supplying the CWD as the relative file path base. We have code that can basically take it from there. This sounds fine, although I'd be curious to see where the logic in fixup differs from the above. I certainly agree that we don't want an additional code path. I would perhaps amend resolve to a valid hostname to looks like a hostname, although I don't know what heuristics we use for that (if any other than passing it to name resolution). PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr. phajdan...@chromium.orgwrote: Thanks for the responses. However, I'm not sure about the next steps. Did you mean it's a security risk, don't do it, or the risk is negligible, do it? How about requiring a --file switch before a relative file path is considered? I think it means that idea to try to open local file and it that fails open remote one as bad. The exact scheme which answers should we try local file or remote file? is not very important (Firefox scheme looks Ok to me), but the situation where EXACT SAME command line can open local file or remote one is surprising and dangerous. Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
But this way will not trigger the file access code (as far as I understand), since you will start Chrome with an http://;, which means it is a URL, so Chrome will not open the file. And even if they click on the file, it is a .com file, not a URL shortcut. Or maybe I did not understand you correctly. ☆PhistucK On Thu, Jan 14, 2010 at 11:31, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: Thanks for the responses. However, I'm not sure about the next steps. Did you mean it's a security risk, don't do it, or the risk is negligible, do it? How about requiring a --file switch before a relative file path is considered? I think it means that idea to try to open local file and it that fails open remote one as bad. The exact scheme which answers should we try local file or remote file? is not very important (Firefox scheme looks Ok to me), but the situation where EXACT SAME command line can open local file or remote one is surprising and dangerous. Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
Sure. It's the way to exploit naive scheme (open local file, then try to open remote one if this fails). If you distinguish local/remote using filename only and don't involve the filesystem the scheme fails: people will not create shortcuts which don't work! And if they worked once they'll work the same way in the future... On Thu, Jan 14, 2010 at 12:37 PM, PhistucK phist...@gmail.com wrote: But this way will not trigger the file access code (as far as I understand), since you will start Chrome with an http://;, which means it is a URL, so Chrome will not open the file. And even if they click on the file, it is a .com file, not a URL shortcut. Or maybe I did not understand you correctly. ☆PhistucK On Thu, Jan 14, 2010 at 11:31, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.comsecure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
[BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. If it doesn't start with a protocol, we don't open it. 99.99% of the users who even would understand what we're talking about could trivially write a shell script or alias to handle it, if they care to.] On Thu, Jan 14, 2010 at 9:15 AM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
I would say that with systems where you can actually use a scheme (http://;) as a file name (or folder, or something like that), there should be an indication that this is a file and not a URL, just for the sake of phishing protection. Even put a red strike (like you do with invalid https) on the 'fake scheme' part, just so the user will be somewhat notified. ☆PhistucK On Thu, Jan 14, 2010 at 19:15, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com(as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote: [BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote: [BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess sh...@google.com wrote: If you try to open a relative path and it doesn't work, you go Oh, right, relative path. No, actually, what I say every time is What the heck, why did it try to open this as a hostname? and then I laboriously navigate through twenty folders of hierarchy on my disk inside the browser, and it sucks. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. I know. You do what Firefox does, is my answer. I don't think Victor's objections have merit. The number of users who supply filenames on the command line is small, but of those users, I think pretty much all would prefer the Firefox method to our current method, so I see no reason to leave things as they are. The only thing that the small userbase affects is the priority of this implementation, which should be low. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 2:05 PM, Peter Kasting pkast...@google.com wrote: I don't think Victor's objections have merit. (For public benefit) Partly because you can't put ':' in a filename on Windows, which is the OS where local files aren't resolved. On the Mac opening local files already works (according to Scott) and I'd be surprised if Linux was different. In other words, I'm not asking for new surface area from this purported attack possibility. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
BTW, AFAICT on both Mac and Linux, chrome-cmd file.html opens file:///path/to/cwd/file.html. Mac works for opening relative http:/file.html. Since http: is not a valid filename for Windows, I'd say making them all consistent would make sense. On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote: [BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
Michał, Chris: could you comment on security aspects and give some recommendations? Ben, could you comment on the user interaction / usability aspect? We have few choices here, I'm not sure which one is preferred. On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Wed, Jan 13, 2010 at 8:36 AM, Evan Martin ev...@google.com wrote: Since the proposed vulnerability is that I have cd'ed into a specially crafted malicious directory then type out google-chrome some-particular-url, at which point I will end up at a file:// URL under the attacker's control, I am skeptical we should worry about this. 1) 99% of users don't have attackers writing arbitrary files to their disk (most users don't have shared disk environments) 2) 99% of users don't launch URLs from the command line 3) the attacker can't do much (how can a file url attack you? phishing?) Steal all your local files and send them off to some website. I recently made this a tiny bit harder (restrict directory listings). I'll do something much stronger sometime soon. Cheers Chris On Wed, Jan 13, 2010 at 7:44 AM, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: Michał, Chris: could you comment on security aspects and give some recommendations? Ben, could you comment on the user interaction / usability aspect? We have few choices here, I'm not sure which one is preferred. On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
I'm fine with the Firefox way. It seems OK for command line inputs to require more strictly validated inputs for URLs, and to follow shell semantics for handling files. -Ben On Wed, Jan 13, 2010 at 7:42 AM, Paweł Hajdan jr phajdan...@gmail.com wrote: Michał, Chris: could you comment on security aspects and give some recommendations? Ben, could you comment on the user interaction / usability aspect? We have few choices here, I'm not sure which one is preferred. On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Wed, Jan 13, 2010 at 23:01, Chris Evans cev...@chromium.org wrote: On Wed, Jan 13, 2010 at 8:36 AM, Evan Martin ev...@google.com wrote: Since the proposed vulnerability is that I have cd'ed into a specially crafted malicious directory then type out google-chrome some-particular-url, at which point I will end up at a file:// URL under the attacker's control, I am skeptical we should worry about this. Steal all your local files and send them off to some website. I recently made this a tiny bit harder (restrict directory listings). I'll do something much stronger sometime soon. Thanks for the responses. However, I'm not sure about the next steps. Did you mean it's a security risk, don't do it, or the risk is negligible, do it? How about requiring a --file switch before a relative file path is considered? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: opening local files with chrome from command line, relative paths
That's easy to answer: Copy the code from Firefox that allows it to handle both local paths and URLs correctly and incorporate that into Chrome. On Jan 8, 5:15 am, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: We havehttp://crbug.com/4436, and the problem is that if you launch chrome index.html (with index.html in the current directory) it will try to navigate tohttp://index.html/instead. This behavior is useful for cases like chromewww.google.com, and generally I don't see a good solution to this issue other than WontFix. Other shell launchers are expected to pass a full path I think. explorer.exe behaves in a reverse way (www.google.comfails, index.html succeeds). In firefox both local relative paths and urls without http work. What should we do for Chrome? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: opening local files with chrome from command line, relative paths
I would also like to point out that this is *NOT* just for launching chrome with index.html in the current directory. It must work for all these cases: C:\path\to\chrome.exe index.html C:\path\to\chrome.exe .\index.html C:\path\to\chrome.exe ..\index.html C:\path\to\chrome.exe ..\lots\of\directory\names\index.html That is, it must work for *all* path types: current directory, any relative path, and fullpath. So again, just copy the working code from Firefox. On Jan 8, 8:42 am, krtulmay krtul...@gmail.com wrote: That's easy to answer: Copy the code from Firefox that allows it to handle both local paths and URLs correctly and incorporate that into Chrome. On Jan 8, 5:15 am, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: We havehttp://crbug.com/4436, and the problem is that if you launch chrome index.html (with index.html in the current directory) it will try to navigate tohttp://index.html/instead. This behavior is useful for cases like chromewww.google.com, and generally I don't see a good solution to this issue other than WontFix. Other shell launchers are expected to pass a full path I think. explorer.exe behaves in a reverse way (www.google.comfails, index.html succeeds). In firefox both local relative paths and urls without http work. What should we do for Chrome? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
