Add-on Guidelines in action – AVG Security Toolbar
The AVG Security Toolbar team has recently released a new version of their toolbar. It has a more predictable user experience and does a better job of allowing users to stay in control of their browser. It’s a great example of the Guidelines for add-on developers in action.
It’s encouraging to see the example set by the AVG Security Toolbar team. They’re building valuable add-ons for people and at the same time they’re respecting user choice. Here are some high level examples of the changes they’ve made in the new version of their toolbar:
- It no longer takes over the search provider. Instead it uses the proper IE8 set default provider API so that users can choose their default.
- The close button is visible so that users can manage it like other toolbars. Additionally, the toolbar is positioned in a supported location which improves stability and performance.
- It no longer modifies the new tab page to maintain a predictable new tab experience for users.
Kudos goes out to the AVG Security Toolbar team. On behalf of our shared customers, thanks. Following the Guidelines and using supported extensibility points in this way means that people have a consistent and reliable experience that allows them to stay in control of their browser. This is exactly what we’d like to see from all add-on developers.
Before: Previous version of AVG Security Toolbar
After: Newest version (2.507.24.1) of the AVG Security Toolbar provides a predictable experience and lets users stay in control of their browser
-Paul Cutsinger and Herman Ng
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Haha ... i.e. it used to be $#!7...Anonymous
October 06, 2009
now if only other programs like nis would do thisAnonymous
October 06, 2009
Thanks for that - I removed my AVG toolbar because it was hijacking my browser.Anonymous
October 06, 2009
The comment has been removedAnonymous
October 06, 2009
The comment has been removedAnonymous
October 06, 2009
The 29th version of my site does a lot of JavaScript object detection and upon critical failure asks users if they want to upgrade. If they choose so they are redirected to a browser ballot page. I'm trying to get SVG images of the four major browsers and have Firefox and Opera though can't seem to find an SVG icon image of IE or Safari (Chrome would work too). I'm not trying to pry about SVG support in IE9; I'd simply appreciate a heads up if any one could help me find an IE and/or Safari SVG image. :-)Anonymous
October 07, 2009
The comment has been removedAnonymous
October 07, 2009
The comment has been removedAnonymous
October 07, 2009
AVG makes millions from Yahoo for this...Anonymous
October 07, 2009
@John A. Bilicki III - "the 29th version" of your website? Are you serious? I hope you don't display this on your site! I understand your quest for an SVG graphic of the IE logo (it would be quite handy), but an official version would need to come from MSFT/IE Team and since such a file would not render in their browser, and would re-highlight to anyone attempting to get the file that IE doesn't support SVG - I highly doubt that MSFT would release such a file "officially".Anonymous
October 07, 2009
And anyway, the IE logo's original graphics file isn't available in SVG. It was made with Adobe Illustrator, and stored as EMS :p (disregard this, it's a joke - I really don't know).Anonymous
October 07, 2009
The comment has been removedAnonymous
October 07, 2009
The comment has been removedAnonymous
October 07, 2009
This is all very interesting but it doesn't explain when IE will support all of the ECMAScript Properties, Methods and Events properly.. or when CSS opacity and rounded corners will be supported.. or when SVG and CANVAS will be supported in IE. I thought the IE Blog was where MSFT regularly announced that "We heard you!", "we're listening to you", "we value your input", "we're serious about standards", "IE will eventually catch up", "we intend to open up a fully public bug tracking site for IE" All of these are very nice statements.. but we are waiting for at least one of them to come true. Any details on that? I think the next version of IE should be code named: IE9 - Pinocchio EditionAnonymous
October 07, 2009
@Clark: It's hard to tell what you mean. I think you're talking about DOM properties, methods and events? Maybe they'd say more if comments were less obnoxious?Anonymous
October 07, 2009
@harvey I can't STAND software with week knees about version numbers. Version 14 shouldn't be called "CS4". That sort of stuff justifies a good trout smacking. @Clark If you did some research you would know that there are plenty of talk about if IE gets to C it has to accomplish B. Things like border-radius, SVG, and JScript improvements are on the radar...I'm also holding out for XHTML support. If we can get decent support for all of those things I'll be one happy duck. I found an Illustrator .ai file of Safari's logo though the SVG export is 573KB! Ouch! Doing basic SVG related research I'd have to say Opera has the lead as far as reliable implementation of SVG is concerned. It's able to properly display SVG via object and img elements, Safari can too though its background is not transparent with the object element. That creates friction with Firefox as Gecko does not support SVG via the image element (hint hint wink wink IE team).Anonymous
October 07, 2009
Unfortunately, it's way too hard to develop IE add-ons, because it currently only makes sense to write them in C++ (VB6/Delphi cannot create 64-bit code - for IE 64-bit; .NET is not supported for IE add-ons; JScript - like in Firefox - is not supported). In addition, you must grasp the complicated COM stuff first before you can write IE add-ons). I wish the IE team would create a JScript JIT compiler à la Chrome for IE8.1 and then a JScript wrapper framework that allows writing performant IE add-ons in JScript - perhaps in IE 8.2. The framework could wrap all the low-level COM stuff for creating BHOs etc.Anonymous
October 07, 2009
@Roland: As virtually no one uses 64-bit IE, the lack of a 64bit Delphi compiler is no impediment to writing IE extensions in Delphi. (I've written a few over the years, FWIW; TamperIE, PopupPopper, etc). Beyond Accelerators (which are implemented with web technologies) you can also write Menu Extensions and toolbar buttons using JavaScript: http://www.enhanceie.com/ie/dev.aspAnonymous
October 07, 2009
The comment has been removedAnonymous
October 07, 2009
With the free MSE security package now available and not bothering to nag users like AVG I think AVG will drop a lot of users. Their anoying toolbar becoming slihtly less anoying won't save them from that.Anonymous
October 07, 2009
Since we are talking about add ons, I hope it is not deemed too off topic. I wonder if any of the team could give us their opinions on Google Chrome Frame. Thanks in advance!Anonymous
October 08, 2009
@Roland, "Unfortunately, it's way too hard to develop IE add-ons, because it currently only makes sense to write them in C++" I don't think there's anything "way too hard" about C++, it's just a programming language, and it's not any harder to learn than JavaScript. It's not really any easier to develop in JavaScript+XUL than develop in C++Anonymous
October 08, 2009
@hitch1: the thing is that C++ is a strictly typed, compiled language where you need to manage your RAM allocations, while XUL, Javascript etc. are interpreted - meaning that you can be looser with your data types (and length), allocations (garbage collectors) and thus, while they are not harder to learn than C++, they are much easier to use in the default configuration (go and program in 'strict' JS, feel the pain - JSlint will hurt your feelings).Anonymous
October 08, 2009
The comment has been removedAnonymous
October 08, 2009
@Bill The issue you pointed out is more of a change in expected behaviour rather than a massive security issue. I don't really buy this idea that using chrome frame is going to make IE less secure. If this was the case then it is an issue with all IE plugins. The point is this blog is meant to be a place for the development team to communicate. Why the complete silence over chrome frame? If it is insecure maybe the team can point out why and where the responsibility lies, is it the fault of google or IE plugin architecture.Anonymous
October 08, 2009
The comment has been removedAnonymous
October 08, 2009
Also if the IE team is working on SVG and wants to REALLY make the SVG crowd really happy I can't think of anything that would top this... div.example {background-image: url(happy.svg);}Anonymous
October 08, 2009
The comment has been removedAnonymous
October 08, 2009
@Mike even if you assume chrome and IE are equivalently exploitable, they aren't identically exploitable. So you've now got a website that can have frames which target the default (IE) renderer, and frames which target the chrome-on-IE renderer. Not only does that give you the chance to attack chrome vulns from IE, you might be able to use, say, an IE vuln to turn a less-severe bug in chrome into a critical exploit, or vice versa. You haven't doubled the attack surface, you've squared it.Anonymous
October 08, 2009
The comment has been removedAnonymous
October 08, 2009
The comment has been removedAnonymous
October 11, 2009
Thanks for posting this. I'm so excited to install my AVG Security Toolbar!Anonymous
October 12, 2009
Hi IEteam, I found IE's address bar cannot correctly highlight the domain of http://xs.to/ website I am using Win7 EnglishAnonymous
October 12, 2009
Don't you think it's a little ironic to be preaching UI design to add-on developers when the UI in Internet Explorer itself is now so poor? I mean, the user is presented with a bizarre and random arrangement of icons, some of which are really menus, and by default they even get that "you've got more stuff off the side" miniature low-contrast double right arrow (I guess you aren't aiming at older folk with that one then…) I don't know who's in charge of UI at Microsoft these days, but it seems to me that whoever it is totally lost the plot around the time of IE 7.Anonymous
October 12, 2009
@wai, please see http://blogs.msdn.com/ieinternals/archive/2009/09/19/Private-Domain-Names-and-Public-Suffixes-in-Internet-Explorer.aspxAnonymous
October 14, 2009
Please provide in IE8
- extra data on the in private filtering such as content type, image size (x by y), content size.
- I want to block all 1x1 pixel images and block most images smaller than 4x4.
- I'd like to detect and get the option to block third party objects referenced from within a web page. For example, I'd like to see only ABC.ORG content when browsing their web site.
- I'd like to block all images from a given site. For example, an I'd like to block all images from a web based email site I use as I only want the email and not all of the other content.
- Can we get a View option on in private filtered objects so thaht we can see if we want to block the script, html, css, or image?
Anonymous
October 14, 2009
Greg, IE8 was finished nearly half a year ago. You're asking for an advanced feature for IE9.Anonymous
October 14, 2009
The comment has been removedAnonymous
October 14, 2009
fudch: You cite a two+ year old article with broken links as somehow the fault of the IE team? And what on earth does "IE loses sessions like a sieve" even mean???Anonymous
October 17, 2009
>You cite a two+ year old article with broken links as somehow the fault of the IE team? How can IE team say they are serious about addons if they throw them away like trash? Only two years and the add-ons are gone. And you say it means nothing? Show me a "two+ year old article" with broken links to add-ons on Mozilla's site. >IE loses sessions like a sieve Bad idiom, I guess. Have you ever tried to carry water in a sieve? It leaks. Just like opened tabs (pages) gradually disappear from IE sessions.