I just wanted to give you heads up that soon it will be time for me to devote most of my time on the second part of the Feed handling support in Chrome, namely: Feed Previews ( http://dev.chromium.org/user-experience/feed-subscriptions).
Consider this a request for your feedback, especially if you know about the status of the previous feed preview work or have opinions on the general direction/approach we should take.
I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews.
I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed:
I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time.
The way that makes most sense to me to implement this in the
extensions system is:
a) In C++ use content sniffing to make sure that the content type is
always correct for feeds
b) Add a feature to content scripts in extensions, so that they can
match by content type
c) Have a content script that matches the feed content type and uses
XSLT to reformat the page into the prettier UI
On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson <fin...@chromium.org> wrote:
> I just wanted to give you heads up that soon it will be time for me to
> devote most of my time on the second part of the Feed handling support in
> Chrome, namely: Feed Previews
> (http://dev.chromium.org/user-experience/feed-subscriptions).
> Consider this a request for your feedback, especially if you know about the
> status of the previous feed preview work or have opinions on the general
> direction/approach we should take.
> I have already added an API for PageActions and have a working RSS
> PageAction extension, which does feed auto-detection on the page. Now it is
> time to look into Feed previews.
> I have spoken briefly to AdamB and EvanM about feed previews and both
> suggested modelling this after the view-source implementation. It was also
> suggested to add a scheme for this (like we do with view-source), such as
> view-feed: or feed:
> I know there has been some work on this front before, although the status of
> that is not clear to me -- except that it was disabled at some point (or
> removed from the codebase?). I would love to see what was done back then, if
> anyone knows more. A cursory look through the code indicated that mime type
> sniffing for feed is done. I've heard there is also some remaining work
> required for sanitizing the feeds before showing, but besides the above
> there is not much more I know at this point in time.
> Comments welcome.
On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson <fin...@chromium.org> wrote: > I have already added an API for PageActions and have a working RSS > PageAction extension, which does feed auto-detection on the page. Now it is > time to look into Feed previews. > I have spoken briefly to AdamB and EvanM about feed previews and both > suggested modelling this after the view-source implementation. It was also > suggested to add a scheme for this (like we do with view-source), such as > view-feed: or feed: > I know there has been some work on this front before, although the status of > that is not clear to me -- except that it was disabled at some point (or > removed from the codebase?). I would love to see what was done back then, if > anyone knows more. A cursory look through the code indicated that mime type > sniffing for feed is done. I've heard there is also some remaining work > required for sanitizing the feeds before showing, but besides the above > there is not much more I know at this point in time.
Feed previews only ever got to the state of "we know this page is a feed, so right <here> is where we'd stick in the template". Actually, the old file has somehow evaded deletion: webkit/glue/resources/feed.html .
Here are some things to consider: - Parsing feeds is an absolute nightmare. See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss . You definitely want to at least do it in the renderer process. Ideally it'd be from JavaScript -- you might then be able to borrow the parsing code from Mozilla(?) -- but I guess that may reject invalid XML, which there is (or at least used to be) a ton of. Maybe we don't care and XSL is sufficient. Definitely look at the Mozilla implementation.
- You should be careful about HTML content. Say site A publishes a feed, and site B publishes a feed that mixes posts from A in among others. If A puts <script> tags in their feed, you don't want to run those scripts on B's origin when you attempt to preview the feed on B. (Normally, this kind of untrusted input handling is B's problem, but that's not how the feed world works.) Ideally, you could work around this by somehow not having an origin *at all* when displaying a feed -- abarth would know more about this than I would.
- 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.
I'd suggest starting with getting view-feed: to do the right thing when it's handed something correct, and then worry about fleshing out all the sniffing/redirecting/etc. second. I'd be happy to review any changes you make in this area.
Why bother with view-feed://? Why not just have the feed be styled
more nicely, similar to the way that XML is styled more nicely by
default in most browsers?
On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> wrote:
> On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson <fin...@chromium.org> wrote:
>> I have already added an API for PageActions and have a working RSS
>> PageAction extension, which does feed auto-detection on the page. Now it is
>> time to look into Feed previews.
>> I have spoken briefly to AdamB and EvanM about feed previews and both
>> suggested modelling this after the view-source implementation. It was also
>> suggested to add a scheme for this (like we do with view-source), such as
>> view-feed: or feed:
>> I know there has been some work on this front before, although the status of
>> that is not clear to me -- except that it was disabled at some point (or
>> removed from the codebase?). I would love to see what was done back then, if
>> anyone knows more. A cursory look through the code indicated that mime type
>> sniffing for feed is done. I've heard there is also some remaining work
>> required for sanitizing the feeds before showing, but besides the above
>> there is not much more I know at this point in time.
> Feed previews only ever got to the state of "we know this page is a
> feed, so right <here> is where we'd stick in the template". Actually,
> the old file has somehow evaded deletion:
> webkit/glue/resources/feed.html .
> Here are some things to consider:
> - Parsing feeds is an absolute nightmare. See e.g.
> http://diveintomark.org/archives/2004/02/04/incompatible-rss . You
> definitely want to at least do it in the renderer process. Ideally
> it'd be from JavaScript -- you might then be able to borrow the
> parsing code from Mozilla(?) -- but I guess that may reject invalid
> XML, which there is (or at least used to be) a ton of. Maybe we don't
> care and XSL is sufficient. Definitely look at the Mozilla
> implementation.
> - You should be careful about HTML content. Say site A publishes a
> feed, and site B publishes a feed that mixes posts from A in among
> others. If A puts <script> tags in their feed, you don't want to run
> those scripts on B's origin when you attempt to preview the feed on B.
> (Normally, this kind of untrusted input handling is B's problem, but
> that's not how the feed world works.) Ideally, you could work around
> this by somehow not having an origin *at all* when displaying a feed
> -- abarth would know more about this than I would.
> - 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.
> - The feed-sniffing code we have is probably not very good and may
> currently be disabled. Eye it with suspicion. This page (sorry for
> the non-public URL) summarizes the behaviors of various browsers in
> various circumstances:
> http://www/~evanm/projects/chrome/feeds/ > http://www/~evanm/projects/chrome/xml/
> I'd suggest starting with getting view-feed: to do the right thing
> when it's handed something correct, and then worry about fleshing out
> all the sniffing/redirecting/etc. second. I'd be happy to review any
> changes you make in this area.
On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
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) <b...@chromium.org> wrote:
> On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
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.)
On Wed, May 6, 2009 at 6:56 PM, Adam Barth <aba...@chromium.org> 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) <b...@chromium.org>
> wrote:
> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
> 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.
FWIW, Firefox has had several security issues crop up with the mixed- content feed preview implementation. Placing privileged controls so close to web content should be avoided, IMO, if you want to keep this from being a problem for Chrome as well.
On Wed, May 6, 2009 at 8:42 PM, Darin Fisher <da...@chromium.org> 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 <aba...@chromium.org> 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) <b...@chromium.org>
>> wrote:
>> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
On Wed, May 6, 2009 at 8:45 PM, Mike Beltzner <beltz...@mozilla.com> wrote: > FWIW, Firefox has had several security issues crop up with the mixed-content > feed preview implementation. Placing privileged controls so close to web > content should be avoided, IMO, if you want to keep this from being a > problem for Chrome as well.
Thanks for weighing in Mike.
Maybe we should put the "subscribe now" button in browser chrome instead of in the content area? That makes a lot of sense from a security point of view. Perhaps the feed preview can teach the user how to use the RSS icon in the location bar?
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.
On Wed, May 6, 2009 at 10:51 PM, Adam Barth <aba...@chromium.org> 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 <da...@chromium.org> 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 <aba...@chromium.org> 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) <b...@chromium.org>
>>> wrote:
>>> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
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) <b...@chromium.org> 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 <aba...@chromium.org> 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 <da...@chromium.org> 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 <aba...@chromium.org> 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) <b...@chromium.org>
>>>> wrote:
>>>> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org> 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.
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman <a...@chromium.org> wrote: > 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?
Sure, we could do that. Or even better is if the outer page is a chrome-extension. Presumably we'll have a "subscribe to feed" API for extensions?
> Adam, what is the concern with having the feed run in the context of > the hosting site? That they might XSS themselves?
There are two concerns:
1) The site might XSS itself by aggregating content from third parties into its RSS feed. Last time I looked into this, there were lots of examples of these, even on Google properties.
2) Our feed preview template might be screwed up and let the feed XSS the template. In a poor design, this might let the feed auto-subscribe the user to itself.
Minor comment, but I assume you will be triggering the feed-preview
when people click on a link to the feed as well.
Many sites have an RSS link to the feed's XML file because it is
previewable in many browsers without autodiscovery.
Currently, Chrome shows unformated XML. Doing CTRL-U after shows the
formatted XML source which is at least better
than its unformatted version.
- Itai
On May 6, 8:36 pm, Finnur Thorarinsson <fin...@chromium.org> wrote:
> I just wanted to give you heads up that soon it will be time for me to
> devote most of my time on the second part of the Feed handling support in
> Chrome, namely: Feed Previews (http://dev.chromium.org/user-experience/feed-subscriptions).
> Consider this a request for your feedback, especially if you know about the
> status of the previous feed preview work or have opinions on the general
> direction/approach we should take.
> I have already added an API for PageActions and have a working RSS
> PageAction extension, which does feed auto-detection on the page. Now it is
> time to look into Feed previews.
> I have spoken briefly to AdamB and EvanM about feed previews and both
> suggested modelling this after the view-source implementation. It was also
> suggested to add a scheme for this (like we do with view-source), such as
> view-feed: or feed:
> I know there has been some work on this front before, although the status of
> that is not clear to me -- except that it was disabled at some point (or
> removed from the codebase?). I would love to see what was done back then, if
> anyone knows more. A cursory look through the code indicated that mime type
> sniffing for feed is done. I've heard there is also some remaining work
> required for sanitizing the feeds before showing, but besides the above
> there is not much more I know at this point in time.
On Wed, May 6, 2009 at 10:51 PM, Adam Barth <aba...@chromium.org> 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 <da...@chromium.org> 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 <aba...@chromium.org> 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) <b...@chromium.org>
> >> wrote:
> >> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org>
> 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.
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman <a...@chromium.org> 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) <b...@chromium.org>
> 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 <aba...@chromium.org> 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 <da...@chromium.org>
> 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 <aba...@chromium.org>
> 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) <
> b...@chromium.org>
> >>>> wrote:
> >>>> > On Wed, May 6, 2009 at 6:13 PM, Evan Martin <e...@chromium.org>
> 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.
On Thu, May 7, 2009 at 12:03 AM, Adam Barth <aba...@chromium.org> wrote: > On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman <a...@chromium.org> wrote: >> 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?
> Sure, we could do that. Or even better is if the outer page is a > chrome-extension. Presumably we'll have a "subscribe to feed" API for > extensions? On Thu, May 7, 2009 at 7:57 AM, Darin Fisher <da...@chromium.org> wrote: > chrome:// pages cannot load HTTP-based sub-resources. We don't want to > taint the processes that render Chrome UI.
Yeah, I actually meant chrome-extension:// for the outer page.
But I don't know what to do about wanting the inner frame to have no authority. Hm.
|
