On Tue, Jan 5, 2010 at 5:34 PM, Adam Barth <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
> >> <[email protected]> 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 <[email protected]>
> >>>>
> >>>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy <[email protected]>
> 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: [email protected]
> >>> View archives, change email options, or unsubscribe:
> >>>    http://groups.google.com/group/chromium-dev
> >>>
> >>
> >
> > --
> > Chromium Developers mailing list: [email protected]
> > View archives, change email options, or unsubscribe:
> >    http://groups.google.com/group/chromium-dev
> >
>
> --
> Chromium Developers mailing list: [email protected]
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to