Authenticode and ClickOnce

On my old IEInternals blog, I posted a fair bit about using Authenticode to sign your programs so that their origins could be identified and to avoid triggering warnings from SmartScreen. My last post on that blog before Microsoft took it away was about using a hardware token to improve security of your certificate’s private key.

Unfortunately, one topic I didn’t cover was the use of Authenticode with ClickOnce applications. Fortunately @RobinDotNet did a deep dive on this topic nearly two years ago and published her results in this two-part series:

A simple summary of these thorough posts: You should use Authenticode to sign both your app’s executable and the setup.exe bootstrapper to help ensure that your ClickOnce invocation isn’t blocked by SmartScreen. This signing is slightly trickier than it sounds because you must sign the files in the proper sequence or the ClickOnce manifest file will contain the wrong hash value. The most reliable place to invoke signcode.exe is in the AfterCompile or BeforePublish steps.

Note: Signing ClickOnce apps is especially confusing because there are so many different things to sign: the manifest, the assemblies, setup.exe, and the executable. When you specify a signing certificate in the project properties, that certificate is used to sign setup.exe (used to install dependencies if the required frameworks aren’t yet installed) and the ClickOnce manifest, but it isn’t used to sign the executable. If you tick the Sign Assembly box, you might expect this to code-sign the executable too, but this doesn’t perform Authenticode signing– it instead applies a strongname to the assemblies. Strongnames aren’t examined by SmartScreen (or much of anything else for that matter).

-Eric Lawrence

OnBeforeUnload

This was the farewell email I sent to my colleagues when I left the Microsoft’s Internet Explorer team to go work on Fiddler full time at Telerik.

Just over eight years ago, a question in an email changed my life.

At the time, I was a PM on the Office Online team, and I had mailed the “IE team” (which then consisted of a skeleton crew) to try to get help on a browser caching problem. I got an apologetic reply saying that unfortunately IE didn’t have the bandwidth to look into this quickly, but we should stay in touch. At the bottom of his signature was the line “Want to change the world? Join the new IE team today” with a link off to the Careers site.

I harrumphed and went about my day with nary another thought about it.
That night, however, I couldn’t sleep and didn’t know why. Going over the day in my head, I thought: What a pompous little recruiting signature from that IE guy. Change the world. Heh. As if.

And then I started thinking about it a bit harder. I mean, I’d used IE almost daily for half a decade, and was then spending at least 40 hours a week in the browser. IE had hundreds of millions of users, many of whom probably used it as often as I did. Firefox 1.0 was about to ship and it looked like another browser race was pending.

Where else in the world could I have as much impact? I asked myself, and the answer was pretty obvious: nowhere. And besides, if I joined the IE team, I’d get source access to WinINET and could eliminate that caching bug. :-) I submitted my application the following day.

Within the first month, I’d printed out the entire source to WinINET and found the six (!!) bugs that were preventing the Office Online image from caching correctly. My lead asked whether this meant I “was now a retention risk.” I scoffed, and showed the dozens of other bugs I’d circled in my printouts. All told, we fixed about a thousand bugs in WinINET in the IE7 timeframe, and many more since.

Over the last eight years together, we have both changed the world and responded to the changing world. We’ve kept Internet Explorer not just relevant but exciting, and in doing so kept Windows at the cutting edge of platforms. We invested heavily in security to keep our users safe, dramatically improved our standards support to embrace the modern web, and multiplied performance many times over to enable entirely new scenarios. We did amazing work with hardware acceleration and reversed the trend toward commodity, lowest-common-denominator browsing.

With Windows 8, we’re bringing the system and the web closer together again (with much better security this time). Internet Explorer 11 holds great promise to refine our revolutionary work in Windows 8 to delight hundreds of millions of users even more, across myriad form-factors. It’s an amazingly exciting time to be working on a browser, and the team is stronger and better-invested than it has ever been.

Of course, working on the IE team also changed me. I met lots of brilliant people, many of whom became good friends and one of whom became my wife. With encouragement and support, I went from writing as little as possible to delivering nearly 200 blog posts, and went from being extremely shy to relishing the opportunity to deliver presentations at conferences like MIX and the PDC. My thanks to you all!

It’s with a heart both breaking and bursting with excitement that I announce that after four major browser releases, I’m off to explore new challenges. In October, my wife and I will be moving to Austin where I’ve taken a job as a .NET developer on a small team. While my post-Microsoft impact is sure to be smaller, it will be good to flex some different muscles and take a look at our industry from a different vantage point.

I’ll be cheering IE11 on from the sidelines and I’m confident that our paths will cross again.

For my farewell party, the team brought a cake and a keg of my favorite beer (Mac and Jacks) and delivered a farewell PowerPoint slideshow. They also presented me with a violin (Fiddle) signed with well-wishes from the team, and gave Jane a pink cowgirl hat with the express intention of getting me to drink enough to allow them to take this photo: