I'm not sure the phishing threat here is worth trying to surface more UI elements. For example, compare the threat to all the tricks an extension with access to the tabs API can pull off (e.g., focusing the phish.com tab when you were about to visit bank.com).
In general, I think we'd be better off recognizing that the ability to replace the browser's UI surfaces is a relatively powerful privilege. Adam On Wed, Aug 26, 2009 at 5:59 PM, Nick Baum<[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
