All of these sound good, except I wonder if we should display the extension name in the url bar when the page is overridden (see the phishing concerns). Thanks for implementing!
-NIck On Wed, Aug 26, 2009 at 3:49 PM, Erik Kay <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
