Discussion: new IE add-on guidelines may forbid Quero

[Viktor Krammer]

Update 2010-06-19: Version 5.0.0.5 has been approved by the IE team

Hi,

In principle Web browser add-ons have two purposes:

1 add new functionality to the Web browser

2 replace or improve existing functionality of the Web browser


In September 2009 [1] the IE team has published a set of new guidlines for add-on developers, which may effectively forbid category 2 add-ons such as Quero.

While I think it is a good thing to have some guidelines in order to improve the overall user experience and keep the user in control, the proposed guidelines are too restrictive in my opinion and may harm IE's ecosystem in the long run by disallowing feature enhancements.

Recently, I was contacted by the IE team and was informed that Quero does not follow the following guidelines:

"Limiting access to IE features"
1 replacing the default address bar
2 hiding the toolbar close button

Ok, I agree with this, because the whole intention of Quero is to provide an experiemental new user interface to Internet Explorer, which unified navigation, search and in-page find operations into one input box (long time before Google did this in Chrome by the way).

Unfortunately, it seems that such add-ons are not allowed any more, and add-ons which do not follow the guidelines will be blacklisted in future updates of IE8.


My plan is to release a new version, which will not hide the standard address bar and toolbar close button by default any more.
Update 2010-05-20: Version 5.0.0.5 released, which implements these changes


Another problem is that IE does not provide enough official APIs to customize it.

Here is a list of things which cannot be done in IE (officially):

* IE is lacking official APIs for filtering DOM maninpulations (JavaScript calls, content creation) necessary for implementing ad blockers or content filters. (but it has an official MIME filter API for static content filtering)

* customize IE's user interface

* hide the toolbar close button (some users prefer to intentionally remove them)

* hide the favorites button

* hide the address bar (for kiosk scenarios, etc.)

* functions to get the information from the active security certificate (SSL, EV)

* tab management (enumeration, tab events)

* Aero UI support for toolbars

* access to favicons

* programmatic access to InPrivate Blocking


I hope to see improvements in IE9 for add-on developers, but I am afraid the opposite might be the case.

To summarize the post, I think the new guidelines are too restrictive. What do you think?

Best regards,
Viktor Krammer


Web Links

1 IE Blog: Guidelines for add-on developers
http://blogs.msdn.com/ie/archive/2009/0 ... opers.aspx

2 Guidelines and requirements for add-ons that extend Internet Explorer
http://support.microsoft.com/kb/973764

[Davey126]

While I agree there is a risk Microsoft may stymie add-on developers (as seems to be the trend in other MS products of late), I do not take issue with the specific IE8 interface recommendations provided the user can override default preferences with explicit consent (eg: selecting/deselecting an option). Of greater concern is the lack of API support for various features and the trend toward discontinuing APIs in newer versions to enforce UI and/or functionality as envisioned by MS.

Thanks for the opportunity to comment and your continued support/development of Quero.

[Viktor Krammer]

I am bit concerned about this general trend seeing software development being more and more confined and restricted.

Currently, "strict guidelines" are most evident on the mobile market such as:

Apple iPhone & iPad
Zune & Windows Phone 7 Series also take the same line
Xbox, PS3 (removed other OS support recently), ...

The advantage of this trend is a better and more consistent user experience and better security (although malware authors usually do not have to comply with any guidelines and circumvent any technical limitation given enough time and motivation).

However, regulations reduce freedom! (i.e. no "competing" Apps on Apple's iPhone, no homebrew Apps, no native code Apps on WP7, "no porn" on Apple hardware, etc.).

API support is also a serious problem of Internet Explorer. IE add-ons are basically stuck with APIs from the IE4 time frame. Update: Ok, there have been some updates to the API in IE7 and IE8, but some more global concepts are missing (see above list that I posted).

[bobster]

Viktor,

As a simple user and not a developer, I'm not too concerned about IE's default settings as long as I can still over-ride them and select the Quero configurations of my choice. I have been so pleased with Quero/IE8 that I want to have the ability to configure any future IE releases (IE9 e.g.) similarly.

The title of this discussion "new IE add-on gluidelines may forbid Quero" seems to imply that this may not be possible. Is this true or may we merely over-ride the IE defaults and use Quero as we now can?

Bobster

[Viktor Krammer]

I have notified Microsoft about my changes and hope that they will accept them. I will post an update here as soon as I get their response.

[krokodylowy]

Don't think about IE8 nonsenses.

IE7 and IE8 also get a "Limiting access to IE6 features" so should be blacklisted. The result is people migration to Firefox.

[BobbyPhoenix]

Don't think about IE8 nonsenses.

IE7 and IE8 also get a "Limiting access to IE6 features" so should be blacklisted. The result is people migration to Firefox.

I agree. Quero is the best add-on I have found. If it is ever blocked I will change browsers.

[Alex]

Hiya, if I install the new version my av Norton 2010 removes it and puts the Quero.dll into quarantine sayinging WS.Reputaion.1, I'm not sure what that means . I installed it a couple of times with the same result so have gone back to the 5.0.0.4 version for the time being. Just thought I'd let you know. Thanks for a great toolbar.

[Viktor Krammer]

WS.Reputaion.1 seems to be a new "feature" from Norton to classify newly released software as a "virus". I have submitted a false positve report to Symantec.

[Viktor Krammer]

Hi, there is now also a discussion on the IE blog about this topic:
http://blogs.msdn.com/b/ie/archive/2010 ... olbar.aspx