See breakdown bug 1029725. Quoting https://wiki.mozilla.org/User:Mconnor/Search_API_Change: > /** > * Selects a new search engine to use as the current engine. > * > * Behaviour is to require explicit confirmation from > * the user through a browser-provided dialog. Add-ons must use > * this API to modify search behaviours or face blocklisting > * > * @param engine > * The engine to select. > * @param addonID > * the ID of the add-on requesting the change > * > * @throws NS_ERROR_INVALID_ARG if engine is unknown or addonID is invalid > */ > void selectEngine(in nsISearchEngine engine, > in AString addonID); > > * addonID should be used to get the name (at least) of the add-on triggering the > prompt to include as the requester. Invalid > > * addonID + version should be recorded, and multiple prompt attempts blocked if > the user chooses to keep current. > > * [optional] To reduce bad behaviour, we should attempt to identify the source > of the API call and verify it's the same add-on as passed in. Bad behaviours > should be recorded/reported somehow. nsIBrowserSearchService lives in netwerk and its implementation is in toolkit. To hook it up to the UI part in the front end, I think we can do what prompts do: have an nsISearchEnginePrompt, have an object in browser implement it, and then the search service implementation would call a method on it that shows the UI. The method would return the user's choice, I guess asyncly via a callback? This bug only covers the netwerk/toolkit part. Another bug will cover the front-end part. Regarding the optional third bullet point above, I wonder if it's possible to get the compartment or sandbox or principle of the calling add-on code, and then look up the add-on's metadata with it. It's weird that selectEngine takes an add-on ID to begin with. It's the honor system and pushes security out to add-on reviewers. But, given that this is the spec, and this point is optional, we should leave it to a follow-up.

(In reply to Drew Willcoxon :adw from comment #0) > Regarding the optional third bullet point above, I wonder if it's possible > to get the compartment or sandbox or principle of the calling add-on code, > and then look up the add-on's metadata with it. It's weird that > selectEngine takes an add-on ID to begin with. It's the honor system and > pushes security out to add-on reviewers. But, given that this is the spec, > and this point is optional, we should leave it to a follow-up. Certainly a follow up - we don't yet have the capability to reliably isolate add-on code and do this kind of correlation automatically (bug 990729 might get us most of the way there once it's enabled everywhere, bug 956883 may also be relevant). So the optional add-on ID parameter is an interim solution (see also bug 1040931).

Please make sure you think about legitimate uses here. An enterprise should be able to deploy a version of Firefox with a different search engine.

I'm interested in picking up this feature as a way to get more in depth knowledge of the search service. I've included a skeleton patch to start with that simply adds the API call to nsSearchService and gives it basic functionality (no checking or logging yet).

Implemented calling AddonManager to get information about the calling addon. Next steps are logging and attempt checking after that. Gavin do you have any suggestions with blocking multiple attempts? Is there a specific time period that we should block for? Should we ask the user before blocking multiple attempts?

We could use the outcome of bug 1148188 to derive the add-on ID here.

Hey Chris - thanks for diving in. I think we may need to take a step back and revisit how this fits into our other search hijacking efforts currently underway. It's possible this is less relevant/useful if add-on signing is implemented, for example, which we're also working on currently. mconnor, does that match your understanding?

I think it's still useful, as it provides a clear, unambiguous UI that all add-ons must use for opt-in. Past history suggests this would avoid a lot of problems.

Mike, do you still think we need this?

I think this was for legacy add-ons, and WebExtensions now do something that achieve the same goal. -> WONTFIX.