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
