Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Fri, Dec 16, 2011 at 3:08 PM, Peter Kasting wrote: > > > > On Tue, 17 May 2011, Bjartur Thorlacius wrote: > > > Then why add an API when we've already got (IMO superior) declarative > > > markup? > > > > In the case of adding the API to the spec, because it's already > > implemented. As to why it was added to the browsers, no idea. > > > Certainly there's no declarative markup for IsSearchProviderInstalled(). > As for AddSearchProvider(), I know one reason it was added to Chrome was > explicitly to expose the "and make default" functionality. Of course one > could argue that a UA could give users the option to make any provider > default for whatever UI it exposes for the declarative case. But there are > a couple fine points worth mentioning: one is that since users rarely want > to make an engine default, adding that option to the UI all the time would > be even more annoying than adding "[ ] And set as my homepage" to whatever > UI is shown for "bookmark this page", and thus UAs may shy away from this > idea. Another is that engines may wish to explicitly request to be made > default in response to some explicit user action on the page, e.g. clicking > a "Make this my default search engine" button. Creating this UI and making > it work smoothly is difficult with the existing mechanisms. > > Note that I am not the one who proposed, specced, or implemented this in > Chrome; I'm just trying to convey a few things that seem apparent to me as > another Chrome UI engineer :) > Just to clarify, it was clear that many including other browsers didn't suppport the asDefault parameter, and Google Chrome no longer supports it. dave
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Fri, Dec 16, 2011 at 3:08 PM, Peter Kasting wrote: > > As for AddSearchProvider(), I know one reason it was added to Chrome was > explicitly to expose the "and make default" functionality. > I've been informed that the "set default" part is going away in Chrome 17+ anyway, so since that will leave no UAs implementing that, all discussion related to it is probably moot. PK
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
> > On Tue, 17 May 2011, Bjartur Thorlacius wrote: > > Then why add an API when we've already got (IMO superior) declarative > > markup? > > In the case of adding the API to the spec, because it's already > implemented. As to why it was added to the browsers, no idea. Certainly there's no declarative markup for IsSearchProviderInstalled(). As for AddSearchProvider(), I know one reason it was added to Chrome was explicitly to expose the "and make default" functionality. Of course one could argue that a UA could give users the option to make any provider default for whatever UI it exposes for the declarative case. But there are a couple fine points worth mentioning: one is that since users rarely want to make an engine default, adding that option to the UI all the time would be even more annoying than adding "[ ] And set as my homepage" to whatever UI is shown for "bookmark this page", and thus UAs may shy away from this idea. Another is that engines may wish to explicitly request to be made default in response to some explicit user action on the page, e.g. clicking a "Make this my default search engine" button. Creating this UI and making it work smoothly is difficult with the existing mechanisms. Note that I am not the one who proposed, specced, or implemented this in Chrome; I'm just trying to convey a few things that seem apparent to me as another Chrome UI engineer :) PK
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Mon, 16 May 2011, Adam Shannon wrote: > On Mon, May 16, 2011 at 18:39, Ian Hickson wrote: > > On Mon, 16 May 2011, Adam Shannon wrote: > >> > >> I don't like having the only barrier between changing the default > >> search engine for a user's browser be a single dialog box. This list > >> (and others) have repeatedly found that dialogs don't work and users > >> skip past them. > >> > >> Think of the non-techy user who simply clicks yes to evil.com's > >> request to change default search provider. Will they even know what > >> that means? Will they care at the time of the dialog? How will they > >> revert back? > >> > >> I'd rather see UA's implement better controls on their end than see > >> an API which could be largely abused. (Drag and drop browser controls > >> over tons of sites asking for permission to be the default.) > > > > I agree. Note that the spec doesn't say there should be a dialog box > > at all; it's left entirely up to the UAs. > > Perhaps it would be better for the group to send a proposal for a UI (or > at least guidelines) that's acceptable both from a realistic usability > and security standpoint? If anyone would like to make some UI proposals on the wiki that would certainly be a helpful thing to do, sure. On Tue, 17 May 2011, Bjartur Thorlacius wrote: > > Then why add an API when we've already got (IMO superior) declarative > markup? In the case of adding the API to the spec, because it's already implemented. As to why it was added to the browsers, no idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On 5/16/11, Ian Hickson wrote: > On Mon, 16 May 2011, Adam Shannon wrote: >> I'd rather see UA's implement better controls on their end than see an >> API which could be largely abused. (Drag and drop browser controls over >> tons of sites asking for permission to be the default.) > > I agree. Note that the spec doesn't say there should be a dialog box at > all; it's left entirely up to the UAs. > Then why add an API when we've already got (IMO superior) declarative markup? The user has to consent. Even confirmation prompts may not be a usable authorization mechanism (as most users generally don't understand them). Use case: User wants to add a search provider. Requirements: A GET form from a site & user's consent The chosen solution should be easily adaptable if not usable for publishing as well as searching. Creating a hyperlink to a POST form (without the "search" relation) should be suitable for microblogging. Solutions: A document advertises a form to the browser; if not installed: the browser advertises the form to the user; the user commands the browser to install the form. document -> browser & browser <-> user -- the site is never informed A document ask the browser if the user has installed the form; if not: begs the user to install it; the user asks the document to ask the browser to install the form; the document ask the browser; the browser asks the user whether it should proceed; the user consents. Or do you mean that a script is to ask the browser without user interaction? document <-> browser & document <-> user & browser <-> user Security considerations: In the case of an API a script bundled with a document may at any point ask for form installation, irrespective of isSearchProviderInstalled making isSearchProviderInstalled redundant, as if it's installed (or blacklisted as in explicit user refusal to install) the call would be ignored anyway. Also, my UA would probably always act as if the form was installed, to protect agaisnt blackmailing á la Facebook scams and sites funded by getting money for endorsing (unwanted) forms.
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Mon, May 16, 2011 at 18:39, Ian Hickson wrote: > On Mon, 16 May 2011, Adam Shannon wrote: >> >> I don't like having the only barrier between changing the default search >> engine for a user's browser be a single dialog box. This list (and >> others) have repeatedly found that dialogs don't work and users skip >> past them. >> >> Think of the non-techy user who simply clicks yes to evil.com's request >> to change default search provider. Will they even know what that means? >> Will they care at the time of the dialog? How will they revert back? >> >> I'd rather see UA's implement better controls on their end than see an >> API which could be largely abused. (Drag and drop browser controls over >> tons of sites asking for permission to be the default.) > > I agree. Note that the spec doesn't say there should be a dialog box at > all; it's left entirely up to the UAs. > > -- > Ian Hickson U+1047E )\._.,--,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > Perhaps it would be better for the group to send a proposal for a UI (or at least guidelines) that's acceptable both from a realistic usability and security standpoint? -- Adam Shannon Web Developer University of Northern Iowa Sophomore -- Computer Science B.S. http://ashannon.us
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Mon, 16 May 2011, Adam Shannon wrote: > > I don't like having the only barrier between changing the default search > engine for a user's browser be a single dialog box. This list (and > others) have repeatedly found that dialogs don't work and users skip > past them. > > Think of the non-techy user who simply clicks yes to evil.com's request > to change default search provider. Will they even know what that means? > Will they care at the time of the dialog? How will they revert back? > > I'd rather see UA's implement better controls on their end than see an > API which could be largely abused. (Drag and drop browser controls over > tons of sites asking for permission to be the default.) I agree. Note that the spec doesn't say there should be a dialog box at all; it's left entirely up to the UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Mon, May 16, 2011 at 18:29, Ian Hickson wrote: >> 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: . > (First, I like that asDefault hasn't been specified yet.) I don't like having the only barrier between changing the default search engine for a user's browser be a single dialog box. This list (and others) have repeatedly found that dialogs don't work and users skip past them. Think of the non-techy user who simply clicks yes to evil.com's request to change default search provider. Will they even know what that means? Will they care at the time of the dialog? How will they revert back? I'd rather see UA's implement better controls on their end than see an API which could be largely abused. (Drag and drop browser controls over tons of sites asking for permission to be the default.) -- Adam Shannon Web Developer University of Northern Iowa Sophomore -- Computer Science B.S. http://ashannon.us
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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: . 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 id=search>? 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 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
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
> This should be rare as annoying and confusing your users typically isn't a > good business strategy. Not all strategies involve wanting to keep normal, happy, satisfied customers. 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..
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On 2/16/11, David Levin wrote: > On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius > wrote: > >> > 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:implement...@lists.whatwg.org > > > It is still complicated in all browsers, so I wasn't trying to point out > flaws in any particular browser -- only that it is complicated and hard for > users to do. > 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. > > On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius > wrote: > >> > IsSearchProviderInstalled(string url) >> This seems like a slight privacy violation. Not a serious one, but nothing >> I'd >> like to be explicitly exposed. > > > Note that it only tells a search engine if they are the default. They cannot > query about other search engines. > > > On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński > wrote: >> >> 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. >> > > This should be rare as annoying and confusing your users typically isn't a > good business strategy. > > > On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius > wrote: > >> > >> 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. ... >> > On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński > wrote: > >> Change of default search engine may have security implications > > > I understand your concern. In this case, the UI is similar to what happens > in many browsers when AddSearchProvider is called in response to a user > action. In addition, the default is to not change anything. > > Yet, we are discussing one possible UI of many that I simply gave as one > possible example. It is completely up to the UA to decide what to do in this > case. I look forward to others proposing other solutions too in this regard. > Why not just have a ? > > On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński > wrote: > >> 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. >> > > If a UA wanted to limit this to only be available to a predefined set of > search engines, that would be possible. It is up to the UA to decide what > to do. Technically a "AddSearchProvider" that did nothing ever would be > conforming though certainly against the spirit of the api. > > > Best wishes, > dave >
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > 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:implement...@lists.whatwg.org It is still complicated in all browsers, so I wasn't trying to point out flaws in any particular browser -- only that it is complicated and hard for users to do. On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > IsSearchProviderInstalled(string url) > This seems like a slight privacy violation. Not a serious one, but nothing > I'd > like to be explicitly exposed. Note that it only tells a search engine if they are the default. They cannot query about other search engines. On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > > 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. > This should be rare as annoying and confusing your users typically isn't a good business strategy. On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > > 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. ... > On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > Change of default search engine may have security implications I understand your concern. In this case, the UI is similar to what happens in many browsers when AddSearchProvider is called in response to a user action. In addition, the default is to not change anything. Yet, we are discussing one possible UI of many that I simply gave as one possible example. It is completely up to the UA to decide what to do in this case. I look forward to others proposing other solutions too in this regard. On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > 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. > If a UA wanted to limit this to only be available to a predefined set of search engines, that would be possible. It is up to the UA to decide what to do. Technically a "AddSearchProvider" that did nothing ever would be conforming though certainly against the spirit of the api. Best wishes, dave
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
* Kornel Lesi?ski wrote: >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). (There are in fact many people who do not know what the address bar might be for and put any address they want to go to into the input field of the engine they are using; for some value of "many", I personally know several.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Mon, 14 Feb 2011 21:34:27 -, David Levin wrote: 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.) 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. 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. There's already 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 ;) -- regards, Kornel Lesiński
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On 2/14/11, David Levin 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:implement...@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".
[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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. 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 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.) 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. FAQ Doesn’t this already exist? Both of these api’s are present in IE7 (and later) except for the additional argument to AddSearchProvider (asDefault) and a change in the url's that may be queried. The pair of apis aren’t in a standard or many of the other browsers. 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 ). Thanks, dave
