Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Is it illegal for the WebKit glue layer to send synchronous messages to the browser requesting the icon data URI? 2010/1/7 Darin Fisher da...@chromium.org It could... but, I though the conclusion was to avoid DOM UI for file:// and ftp:// directory listings (for other reasons). In that case, we should be able to continue using the same UI. I think there is just the open question of how to provide icon resources to the page. -Darin On Thu, Jan 7, 2010 at 4:11 AM, Dean McNamee de...@chromium.org wrote: Yeah, so my question was, does that mean test_shell would have a separate mechanism (the current one?) for file:/// listings? On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher da...@chromium.org wrote: DOM UI implies chrome://, which is implemented by the ChromeURLDataManager (in browser/dom_ui/). TestShell wouldn't be able to use that. -Darin On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote: I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- Chromium Developers mailing list:
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Is it illegal for the WebKit glue layer to send synchronous messages to the browser requesting the icon data URI? I don't know, but in general sync messages suck. Why couldn't you use an async message and just show the icon once it arrives? 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
True, there really is no need for it to be synchronous. 2010/1/10 Peter Kasting pkast...@google.com On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Is it illegal for the WebKit glue layer to send synchronous messages to the browser requesting the icon data URI? I don't know, but in general sync messages suck. Why couldn't you use an async message and just show the icon once it arrives? PK -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Yeah, so my question was, does that mean test_shell would have a separate mechanism (the current one?) for file:/// listings? On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher da...@chromium.org wrote: DOM UI implies chrome://, which is implemented by the ChromeURLDataManager (in browser/dom_ui/). TestShell wouldn't be able to use that. -Darin On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote: I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
It could... but, I though the conclusion was to avoid DOM UI for file:// and ftp:// directory listings (for other reasons). In that case, we should be able to continue using the same UI. I think there is just the open question of how to provide icon resources to the page. -Darin On Thu, Jan 7, 2010 at 4:11 AM, Dean McNamee de...@chromium.org wrote: Yeah, so my question was, does that mean test_shell would have a separate mechanism (the current one?) for file:/// listings? On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher da...@chromium.org wrote: DOM UI implies chrome://, which is implemented by the ChromeURLDataManager (in browser/dom_ui/). TestShell wouldn't be able to use that. -Darin On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote: I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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:
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
DOM UI implies chrome://, which is implemented by the ChromeURLDataManager (in browser/dom_ui/). TestShell wouldn't be able to use that. -Darin On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote: I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. On Tue, Jan 5, 2010 at 1:04 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Apparently Google Groups doesn't add the [chromium-dev] in the subject line when you post from the web app... 2010/1/1 plafayette pierre.lafaye...@gmail.com http://crbug.com/24421 and http://crbug.com/27772 seem to hint that these directory listing pages would benefit from being handled at a higher level than the WebKit Glue Layer (or the net module in the case of file:///), namely as a DOM ui page. Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? I haven't looked too deeply into what amount of work this would require. Is this a reasonable solution for these issues? Thanks, Pierre. -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Instead of DOMUI, why not use an extension to display the directory listing? You can put the icons in the CRX. Adam On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 5:34 PM, Adam Barth aba...@chromium.org wrote: Instead of DOMUI, why not use an extension to display the directory listing? You can put the icons in the CRX. this would drastically inflate the size of the extension and wouldn't match the system icon theme Adam On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 2:50 PM, Evan Martin e...@chromium.org wrote: On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. Yes, exactly. Remember that ftp:// directories can be loaded in iframes by web content. We don't want to grant any extra privileges to renderer processes that display ftp:// content b/c those privileges could leak to other content loaded by the same renderer if cross-site-scripting exploit happens to exist. I think there's a good opportunity to spiff up the directory listing template to be nicer, but I think we have to avoid changing these directory listings over to DOMUI. -Darin It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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
