chrome:// pages cannot load HTTP-based sub-resources. We don't want to taint the processes that render Chrome UI. -Darin
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman <[email protected]> wrote: > Let's say the feed is http://foo.com/feed.xml > > What about a setup where the content rendered in the tab area is > running on chrome://, but contains a frame that hosts the actual feed > running on http://foo.com? The subscribe UI runs on the other page, so > it is the only thing that needs elevated privileges. Initially, the > two frames would run in the same process, but they'd still be > separated by same-origin. Someday, we could even separate them by > process as we have no need to ever communicate between these frames > via JS. > > Adam, what is the concern with having the feed run in the context of > the hosting site? That they might XSS themselves? > > - a > > On Wed, May 6, 2009 at 11:22 PM, Ben Goodger (Google) <[email protected]> > wrote: > > > > Regardless of whose authority they run at, it is somewhat desirable to > > have the feed URL display in the address bar, since that's the content > > that's being loaded. > > > > I would like to keep the flow in page as much as possible. We should > > be able to come up with some solution here that doesn't involve > > elevation. > > > > -Ben > > > > On Wed, May 6, 2009 at 10:51 PM, Adam Barth <[email protected]> wrote: > >> I don't think we want these feed previews to run with foo.com's > >> authority. I'd rather they ran with no one's authority. > >> > >> Adam > >> > >> > >> On Wed, May 6, 2009 at 8:42 PM, Darin Fisher <[email protected]> > wrote: > >>> WebKit does not support nested schemes. It would fail in so many > places to > >>> recognize that the authority of such an URL is actually foo.com. > >>> > >>> (However, we could perhaps support this as we do view-source, where > WebKit > >>> never actually sees the view-source URL.) > >>> -Darin > >>> > >>> On Wed, May 6, 2009 at 6:56 PM, Adam Barth <[email protected]> > wrote: > >>>> > >>>> I think Darin had some strong opinions about whether we should do > >>>> nested schemes like feed-view:http://foo.com/bar. > >>>> > >>>> From a security point of view, we'd ideally like to render feeds with > >>>> JavaScript and plug-ins disabled, as well as in a noAccess > >>>> SecurityOrigin. This is easier if the feed preview lives in its own > >>>> scheme. I'm happy to help out with the security bits once you have > >>>> the basics up and running. > >>>> > >>>> Adam > >>>> > >>>> > >>>> On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) < > [email protected]> > >>>> wrote: > >>>> > > >>>> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <[email protected]> > wrote: > >>>> >> - Some existing practice on the web is to use > >>>> >> "feed://hostname/etc.xml", which drops the protocol (and should be > >>>> >> interpreted as HTTP). Ideally you should redirect these into > >>>> >> view-feed:http://hostname/etc.xml so our view-feed works with > https, > >>>> >> ftp, etc. URLs. > >>>> > > >>>> > Firefox retains the URL of the feed in the address bar (including > >>>> > scheme), which is nice, though it falls back to an internal URL > under > >>>> > the hood to do the render of the preview. > >>>> > > >>>> > -Ben > >>>> > > >>>> > >>> > > >>>> > > >>> > >>> > >> > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
