W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 16 May 2011 23:29:23 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1105162315210.19153@ps20323.dreamhostps.com>
On Mon, 14 Feb 2011, David Levin wrote:
>
> 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.
> 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)
> 
> Proposal
> Add two apis to window.external:
>   IsSearchProviderInstalled
>   AddSearchProvider

These appear to be implemented by IE, Chrome (partly on Windows only), and 
Firefox (though IsSearchProviderInstalled is stubbed only).


> 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.)

I have specified this, except instead of throwing an exception it returns 
0. This means that stubbing out this method is easy and doesn't require 
complicated origin checks to be compatible with full implementations.


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

I haven't specified the "asDefault" argument since it isn't implemented 
anywhere except Chrome, but other than that I have specified it. The UI is 
left very open-ended. Note that there is already an equivalent declarative 
feature in HTML: <link rel=search>.


On Tue, 15 Feb 2011, Bjartur Thorlacius wrote:
>
> This seems like a slight privacy violation. Not a serious one, but 
> nothing I'd like to be explicitly exposed.

It's mitigated to some extent by being limited to same-domain checks (you 
can't check if someone has made another search engine their default), 
since frankly if you've made a particular search engine your default they 
can already tell pretty easily just by looking at your usage, if they 
really wanted to violate your privacy.

However, I have made sure to allow UAs to lie and always return 0.


> 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".

I've left the UI entirely open.


On Fri, 18 Feb 2011, Bjartur Thorlacius wrote:
>
> I don't believe that the best solution to that is to implement a cross 
> browser API to allow sites to create their own inconsistent UI to make 
> themselfes default. A user who knows how to make Google default, should 
> be able to make Bing default using the same procedure. Thus the UI has 
> to be implemented by the browser.

I agree that a good UA would make this easy and consistent.


> Why not just have a <link rel=search href=#search><form
> id=search><input type=text></form>?

I'm not sure I understand how this would work. Can you elaborate?


On Sat, 19 Feb 2011, timeless wrote:
> 
> Spammers and other fraudsters seem to be perfectly happy with things 
> where they capture things like the default search engine of normal users 
> w/o the users really understanding the consequences.
> 
> Oddly, even major companies seem willing to risk the wrath of customers. 
> Some seem to enjoy tacking on toolbars to other random apps which make 
> them the default search engine, etc..

Indeed.


On Tue, 15 Feb 2011, Kornel Lesi?~Dski wrote:
> 
> Change of default search provider is a big thing. You don't change that 
> often, and there are only few search engines that make sense to be set 
> as the default one. Browsers can simply ship with predefined set of 
> engines, and that may be easiest and safest option for users.
> 
> There are many many sites that dream they were used as a default search 
> engine, but their use of this API is only going to annoy or confuse 
> users.
> 
> Change of default search engine may have security implications ??? there 
> are less tech-savvy people who rely on search engine for *everything* 
> they do on the net and blindly trust the results (see famous "facebook 
> login" case). Malicious sites could try to trick people into setting 
> them as default in order to inject links into (proxied) search results.

This seems reasonable, indeed.


> There's already <link rel=search> that allows browsers discreetly 
> integrate site's search in the UI, without having sites clutter layout 
> with yet another begging button. All the "like-me", "digg-me" & 
> "tweet-me" buttons are awful enough ;)

True.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 16 May 2011 16:29:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC