Good Practices for ActiveX Updates
One of the most important activities we do in the software industry is service our customers through software updates. Like any other binary software, ActiveX controls often need to be updated with bug fixes and new functionality. So what is the best way to get updates to our customers?
Steve, from our Silverlight team, and I were just chatting about good update practices for ActiveX controls, and we want to share them with you. Most of these practices are already in common use among ActiveX controls; we thought it would be helpful to list them all in one place.
These good practices can be broken down into three steps:
- Add detection logic to your ActiveX control to check for updates
- Build an update executable and launch it out of Protected Mode to install the update
- Give end users and IT Admins the choice to make updates
1. Add detection logic to your ActiveX control to check for updates
The best way to distribute an update is to have your ActiveX control download and install it. This update process should be kicked-off by checking the server for updates when your control is loaded in IE.
As you know, designing for great performance is important, and there are a few practices worth sharing that Silverlight follows to give the user the most visually responsive experience possible. First, complete the server check on a worker thread instead of on IE’s main UI thread, where your ActiveX control gets loaded. Following the same design principle, asynchronously check for updates quickly but not immediately. You might also want to check for the latest version only once a day or once a week instead of at every time your control gets loaded in IE.
For improved performance on the server-side, it’s a good idea to have the capability to communicate with your ActiveX control to manage its requests and downloads. Specifically, your server can tell your ActiveX control to download an update immediately or “try again” later when the server is not under a heavy load.
2. Build an update executable and launch it out of Protected Mode to install the update
When IE is in Protected Mode on Windows Vista, ActiveX controls running in the IE process cannot install updates themselves. This is because IE and ActiveX controls do not have write access to most locations in the file system or registry under Protected Mode. As a result, it’s best to use a separate executable to download and install the update. You can further protect users against "man-in-the-middle" attacks by using an SSL connection to download updates. For more information on Protected Mode see the technical article Understanding and Working in Protected Mode.
Similar to the initial install process, your executable will need administrative privileges to install updates for all users on the machine. To request administrative privileges on Windows Vista, create an application manifest for your executable with the following requested execution level:
<requestedExecutionLevel
level="requireAdministrator"/>
Note that Windows Vista will see the requested execution level and display a User Account Control (UAC) dialog so the user can elevate the update executable out of Protected Mode. For more information see the section Step Six: Create and Embed an Application Manifest with Your Application in the technical article Windows Vista Application Requirements for User Account Control Compatibility
3. Give end users and IT Admins the choice to make updates
It’s a good idea to notify users when updates are available, and let them choose to install them. Notifying users gives them more control over the update experience and also gives them context for the UAC dialog that will follow if they choose to install the update.
Following the same principle of giving users control and context, it’s not a good idea to automatically install updates or even give the user this option. Automatically installing updates doesn’t give the user control and doesn’t give them context for the UAC prompt as mentioned above.
If your ActiveX control is used in corporate environments, it is good practice to give the IT Admin a way to turn-off your update mechanism through Group Policy so that they can control update deployment. With that said, you don’t want to give end users this option because it will make their computer more vulnerable to attack.
The on/off switch for updates can be as simple as your ActiveX control reading a registry key that the IT Admin writes through Group Policy. It’s a good idea to give IT Admins an .adm file so they can easily configure Group Policy. For more information see the section How to Write a Simple .Adm File for Registry-based Group Policy in the technical article Using Administrative Template Files with Registry-Based Group Policy.
Note on checking for latest version during install
Checking the server for updates and launching an update executable are also good practices to do when your ActiveX control is being installed. The server check can be used to ensure that the latest version is being installed.
The best time to perform the server check during install in the DllRegisterServer phase. Following the above performance design principle, add a timeout to the server check and fail the install if no response is received before the timeout. In the unlikely event that the user is installing an older version of your control, you can use the update executable mentioned above to download and install the latest version.
If you would like to read more on ActiveX control best practices, check out the MSDN article on ActiveX Security: Improvements and Best Practices.
Marc Silbey
Program Manager
Internet Explorer
Steve Herndon
Lead Program Manager
Silverlight
Comments
Anonymous
August 13, 2007
Thanks for the chatter folks, I'll check in again in 6 months to see if issue tracking is online. goodbye!Anonymous
August 13, 2007
Hey Charles make it 12 months so we can miss you less. QuitchurbitchinAnonymous
August 13, 2007
I remember when having ActiveX controls "phone home" was considered a security/privacy risk. And its odd that calling WinVerifyTrust before executing your upgrade binary isn't on the list.Anonymous
August 13, 2007
Just found another bug in IE7. When an element has the :hover pseudo class applied (where the background image changes), mousing over the element (or several if close together (e.g. a menu/list)) causes the favicon in the tab to flicker. Im guessing that for a split second IE thinks it needs to load a resource, switches to the toilet bowl flushing icon, then realizes it has the resource loaded already, and displays the page's favicon again. I can partially understand this on the 'very' first mouseover of an un-cahced image, but every flicker after that appears to be a bug. Im not sure why but if the item has a z-index applied, the effect is even more prevelant. Dare I ask where the bug tracking site is so I can enter this? BrentAnonymous
August 13, 2007
@charles you won't likely see this reply but i'm with you. I've had enough. samAnonymous
August 13, 2007
@Brent: What cache-related headers were returned on your background image?Anonymous
August 13, 2007
@Brent Presumably you have checked your server log to ensure the image is not being downloaded repeatedly.Anonymous
August 13, 2007
So a javascript popup says that "Microsoft Silverlight needs to update, do you wish to continue" and a download for a completly different (malicious) activex control happens, the user gets asked if they want to give admin priveledge to the activex control and then it runs amock on the system. The best update to ActiveX is turning it off.Anonymous
August 13, 2007
"After much discussion on the team, we've decided that people are right and that we should have a public way for people to give us feedback or make product suggestions." http://blogs.msdn.com/ie/archive/2006/03/24/560095.aspxAnonymous
August 14, 2007
@IE8 Re: "After much discussion on the team, we've decided that people are right and that we should have a public way for people to give us feedback or make product suggestions. http://blogs.msdn.com/ie/archive/2006/03/24/560095.aspx " Are you pointing out to the community that follows this blog that there is a feedback site? If so, this was torn down almost a year ago. Or are pointing out that Microsoft realized the extreme importance of such a system, implemented it, then went back on their words and the community by taking the feedback site down? Either way it is a sad reality. =================================== 1.17 Billion people use the Internet (http://www.internetworldstats.com/stats.htm) 58.5% Are using Internet Explorer (http://www.w3schools.com/browsers/browsers_stats.asp) Do 684 Million people not deserve the right to be able to submit a bug report? Do the developers that make applications and sites that run in IE not deserve to have a central repository of bug workarounds so they can fix what is broken in IE? Its the dawn of another new day, lets sit down and hammer out a plan to get this up and running ASAP.Anonymous
August 14, 2007
In the last paragraph you mention that if the check for the newest version times out, to fail the install. Why? I should have my product fail to install when; a) Users internet not connected (an offline install) b) My website breaks (hopefully only temporarily). c) User has a proxy server (or similar) which my DLL can't use (eg HTTP Auth). This sounds like a good way to ensure my product doesn't get installed a lot! It appears to make more sense if the DLL cannot confirm that it is old to install... doesn't it?Anonymous
August 14, 2007
@EricLaw[MSFT] Its not related to caching AFAIK. Here are the relevant headers HTTP/1.1 200 OK Date: Tue, 14 Aug 2007 13:05:05 GMT Server: Apache/2.0.52 (Win32) Last-Modified: Mon, 13 Aug 2007 20:49:17 GMT Content-Length: 693 Cache-Control: max-age=2592000 Expires: Thu, 13 Sep 2007 13:05:05 GMT Content-Type: image/gif @ash, no the image only gets downloaded once, firebug headers/fiddler headers and server logs confirm. I think the toilet bowl spinner kicks in whenever the browser is 'working' on an image, regardless of whether it is cached or not. An easy test is to set a div, with a class, with a background image that is BIG! (like a 1280x1024 desktop image (GIF/JPG/PNG (it doesn't matter)) then on :hover, swap it for another (any format) of the same BIG size. hover once, to load the second image. then rollover/off the div several times while watching the spinner. Reproducable: IE6: Never (doesn't support :hover) IE7: Always Safari: Never Firefox: Never Opera 9: Sometimes thanksAnonymous
August 14, 2007
IEBlogで、ActiveXコントロールのダウンロードはどうあるべきか、という...Anonymous
August 14, 2007
Enterprise users should never be able to install ActiveX controls through IE, except via the ActiveX Installer Service on Vista. Enterprise users should be running as Standard User, not as admins with the option to elevate. Barring AxIS, ActiveX installation and updating has to be through another mechanism.Anonymous
August 16, 2007
In my view activeX updates must be turned on. When they want to be updated allow them to update.Microsoft is the number one company and in case they have decided to make update it is better for all of us (the end users) to download and install the update. Microsoft will not try to harm our computers so I believe them about everything. Every time I get asked about an update I do it. This is my view and I am not asking you to update too, only telling what I think. Big thanks to all microsoft developers that work hard everyday!Anonymous
August 16, 2007
The comment has been removedAnonymous
August 16, 2007
"it’s not a good idea to automatically install updates or even give the user this option. Automatically installing updates doesn’t give the user control and doesn’t give them context for the UAC prompt as mentioned above." Bingo! Give the user the control back! ... I waited years to hear such a statement. Thank your! It is great to hear this out of your mouth ;PAnonymous
August 16, 2007
This suggestions are completely unacceptable! "add a timeout to the server check and fail the install if no response is received before the timeout" I work in an corporate environment and the very last thing I want is that an installation of a PC or software failes if prerequisites just decide that they need to phone home. the way to reliable systems is to NOT depend on ANY online service and have stable versions. Yet you suggest so balantly offensive things like mandatory update checks, not possible to turn off, additional admin-executables, and failed und unreliable, unpredictable magic installations! That is really disgusting!Anonymous
August 16, 2007
Is there sample code availabe for these methods ?Anonymous
August 22, 2007
I specially agree with the third point. The user always must have the chance to decide if he really want to update or not. Using vista for serveral month now and all the unasked updates installing themselves really go on my nerves!Anonymous
August 22, 2007
I can totally agree with Fliesen. Getting an update in the wrong moment without wanting it is like an illness.Anonymous
August 22, 2007
看过了,谢谢 http://www.solarain.cn 文学诗词情感 http://www.suilu.com 网站建设及推广Anonymous
September 18, 2007
Last Friday, Microsoft released a new version of the SiteLock Template for ActiveX Controls . The SiteLockAnonymous
October 16, 2007
I was reading my buddy Alex Smolen's post the other day on Java Applet Security and figured I would seeAnonymous
December 14, 2007
http://blogs.msdn.com/ie/archive/2007/08/13/good-practices-for-activex-updates.aspxAnonymous
March 20, 2008
One of our goals with Internet Explorer 8 was to improve the experience of managing add-ons by bringingAnonymous
May 07, 2008
Hi, I’m Matt Crowley, Program Manager for Extensibility with Internet Explorer. The team was very excitedAnonymous
March 04, 2009
이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의Anonymous
March 16, 2009
    아래 글은 IEBlog에 올라온 IE 8 보안 관련 글 중 두번째 글을 번역한 것입니다. 현재 파트 5까지 나와있는데 시리즈로 번역할 예정입니다. 이 글 뿐