[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

On 2/14/11, David Levin <levin at chromium.org> wrote:
> Problem
> Although the default search provider may have a significant impact on a
> user?s web experience, it isn?t easy for users to set this.
>
> Ideally, a search engine should be able to offer the user the ability to
> easily use it as the default. Currently, there are two obstacles to this:
> 1. The search engine may not be able to detect that it already is the
> default, so it would offer this too broadly.
The browser will both understand how search engines are managed
and what engine(s) are enabled and default.
> 2. When a user decides to use it, they have to follow a set of complex
> instructions (http://www.google.com/search?q=switch+default+search+engines)
>
Annoying implementation issue. http://bugzilla.mozilla.com/enter_bug.cgi
mailto:implementors at lists.whatwg.org

> Proposal
> Add two apis to window.external:
>   IsSearchProviderInstalled
>   AddSearchProvider
>
> IsSearchProviderInstalled(string url) returns
>   * 2 if the origin in the given url is the default search provider
>   * 1 if the origin in the given url is a search provider but not the
> default.
>   * 0 otherwise
> If the given url doesn?t have the same security origin as the page, this api
> throws an access denied exception. (This makes the url redundant but it is
> kept to be consistent with the method exposed by IE 7.)
>
This seems like a slight privacy violation. Not a serious one, but nothing I'd
like to be explicitly exposed.

> AddSearchProvider(string openSearchUrl, [optional] bool asDefault) retrieves
> the open search document from openSearchUrl and decides in a UA specific
> manner whether to prompt the user about the change or addition.
>
> Won?t the InstallSearchProvider api get abused?
> The home page setting for users has a similar value. Yet, the SetHomePage
> api available in IE does not seem to be abused significantly. Largely this
> will depend on the UA providing appropriate measures to protect users. In
> Chromium, we rely on a combination of user gesture (click, etc.) plus a
> dialog which clearly explains what is going to happen with the default being
> that nothing is changed (
> https://sites.google.com/a/chromium.org/dev/developers/design-documents/chromium-search-provider-js-support
> ).
Frankly, this reminds me of the security UI of Windows Vista. First,
you command some app to modify your settings, then you have to command
the system to obay the command. Users tend to dislike that.
Developing an discoverable UI that'll be consistent between pages
seems more important than implementing an API and using complicated
heuristics so that it'll hopefully "seem" not be abused
"significantly".

Received on Tuesday, 15 February 2011 09:42:26 UTC