There are a lot of places that we were seeing users drop off the radar when trying to install. Through a combination of logging analytics and user studies we figured out what the main problems were and designed this flow to solve them.
(See my post from last week for more context on why we built this: https://news.ycombinator.com/item?id=8168792)
>>
Instead, we created a custom version of the signing tools which complied with the Authenticode spec (for Windows) while letting us safely modify content for each binary. Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec.
>>
Can you offer some more info on this topic in a follow-up post?
Inside the Authenticode signature, there is an area for unauthenticated attributes (e.g., if you timestamped your executable, the timestamp (PKCS#9) is stored as an unauthenticated attribute,
http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-u...). These attributes are not verified by Windows Authenticode when the executable is run. So if you can add a new unauthenticated attribute into the signature, you can make any change we want to that attribute without invalidate the signature.
In order to inject an unauthenticated attribute to the signature, you may want to use osslsigncode for signing (instead of MS signtool).
