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

How Hard Could It Be

I have an idea for a new reality show; it’ll be called “How Hard Could It Be?” The show will feature everyday people approaching straightforward (but new to them) tasks, for instance, minor home repairs.

For instance, in the kickoff show, a software developer will be faced with filling a gap introduced in his front porch when a professional replaced an exterior door.

gap

To make it more interesting, we’ll have the work done on the highly-visible front porch, and we’ll have the man’s wife be pregnant to ensure a steady flow of family and friends visiting over the next few months.

The show will start with the man rubbing his chin and looking at the gap. “I know”, he’ll say, “I can fill this with concrete. I mean, ‘How hard could it be?'”

We’ll follow our character as he researches by watching assorted videos on the Internet, wherein a wide variety of workaday joes install concrete successfully in a wide variety of projects.

Confirming the ease of his project, he’ll drive over to the local home depot, grab an 80lb bag of concrete, a few stirs, a 5 gallon bucket, and some red concrete dye. That’s right, dye. The dye serves two purposes: One– to attempt to match the final result to the nearby brick and other décor. Two– so that the viewers at home (and any passers-by) can easily see all of the unintended places that the concrete ends up. To up the ante a bit, this project will begin late on Sunday morning (ensuring that only one day can be spared for the work) and we’ll film on a May day in Austin with afternoon temperatures in the mid-90s.

Reading the bag of concrete mix, he’ll scoff as he reads “Do not let concrete dry in your hair” and feel confident that this project is going to be trivial: “How hard could it be, if the package needs to warn the typical user of such things.”

As the afternoon proceeds, we’ll watch our hapless hero increasingly drenched in sweat, as he learns valuable lessons like: ‘Why you don’t want to pour concrete mix without a facemask’, and ‘Why do professionals mix concrete in wheelbarrows instead of buckets.’ A counter on the screen will track the skyrocketing obscenity count as the afternoon proceeds toward dusk.

The show will end with our red-tinted grimy hero and his very-pregnant wife on the porch looking forlornly at the final lumpy, off-color result.

She’ll look on the bright side. “It won’t look so bad after we cover it with the welcome mat.”

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.