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 -~----------~----~----~----~------~----~------~--~---
