Here are a few differences between your proposal and the actual
implementation I'm landing shortly:

* It allows overriding of chrome:// URLs, it doesn't just intercept at
the UI access points
* The URL will be displayed exactly as if it wasn't being overridden
(not visible for newtab and chrome://... for the rest)
* the key name is chrome_url_overrides
* we only support extension-relative resources (you can't put
http://www.google.com)
* for the initial release, we're only allowing "newtab" to be
overridden.  We'll see how this one goes and what the demand is for
overriding other pages.

The rest matches your proposal.

Erik


On Mon, Aug 24, 2009 at 6:30 PM, Nick Baum<[email protected]> wrote:
> Two additional comments:
>
> According to Aaron, we will actually redirect "chrome://" pages to the
> extension pages.
> We obviously won't let extensions replace "chrome://extensions", since they
> could remove the ability to uninstall the extension.
>
> -Nick
> On Mon, Aug 24, 2009 at 6:02 PM, Nick Baum <[email protected]> wrote:
>>
>> Hi all,
>> Several people have requested an API to replace Chrome's built-in UI pages
>> (new tab, downloads, etc.)
>> Please send feedback on the proposal below.
>>
>> -Nick
>>
>> UI Pages API
>>
>> Overview
>> This API would allow an extension developer to replace Chrome's built-in
>> pages (New Tab page, History, Downloads & Bookmarks). It does not override
>> the "chrome-ui://" urls, but simply hooks into the various access points
>> (Ctrl+N, Wrench>History...). This API does not exclude the possibility of
>> more specific APIs to modify the built-in implementations of these pages
>> (for example, the oft-requested New Tab page API).
>>
>>
>> Use cases
>> Many extension authors would like to provide alternate implementation of
>> these pages. For example, some users might want to have their delicious
>> bookmarks as their bookmarks page, or their google web history as their
>> history page.
>>
>>
>> Could this API be part of the web platform?
>> No, these pages are completely browser-specific and don't make sense in
>> the context of a web page.
>>
>>
>> Do you expect this API to be fairly stable?
>> Yes, the API is small and unlikely to change. Besides, if we were to
>> deprecate any of the pages exposed, we could simply ignore those entries in
>> the manifest.
>>
>> What UI does this API expose?
>> The UI for this API should be small. First of all, pages served from
>> extensions usually do not display a URL. However, in this case, showing the
>> origin of a particular page would mitigate the phishing risk (see below). A
>> simple solution is to display "[page]: [name of the extension]" in the
>> address bar.
>> Second, we must deal with the edge case of multiple extensions using this
>> API at the same time.We should default to using the pages provided by the
>> most recently installed extension. Assuming we keep track of first install
>> date, this should work well even when an extension is uninstalled. At some
>> point, we may also want to expose a setting to override this ordering,
>> although I think we could ship without this.
>>
>> How could this API be abused?
>> There is some phishing risk. An extension could implement a new tab page
>> that looks identical to Chrome's new tab page, but links the thumbnail of a
>> popular site to a phishing site instead (for example, a thumbnail to
>> facebook.com leading to www.evilfacebook.com). Showing the name of the
>> extension in the address bar would let a savvy user know when the page is
>> not the original, but it's unclear how to protect less cautious users.
>> Finally, we should make sure that a poorly implemented new tab page
>> doesn't slow down the user's browsing experience. For this reason, we should
>> discuss whether to allow extensions to set these pages to "http://"; urls,
>> even though there is a clear use case for this. Opinions appreciated on this
>> question.
>> Given that this is a UI API, there are no particular privacy concerns – an
>> extension would need additional permissions to access any personal data.
>>
>> Are you willing and able to develop and maintain this API?
>> N.A. (on the Chrome team)
>>
>> Draft API spec
>> Manifest format:
>>
>> "chrome-pages": {
>>
>> "newtab" : "foo.html",
>> "history" : "bar.html",
>> "downloads" : "fu.html",
>> "bookmarks" : "baaar.html"
>>
>> }
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-extensions" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/chromium-extensions?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to