View source for Software Update:Signing

'''''XPInstall Entry Points''''':

''1.Unsigned XPI over HTTP (or other insecure channel).''
		
This is the general case today.  An unsigned XPI is hosted on some website; the user either clicks on it or Install.Trigger is called.  	

''2.Signed XPI over HTTP (or other insecure channel).''

This is a specific and uncommon case existing today in which the XPI is code signed.  A signed XPI is hosted on some website; the user either clicks on it or Install.Trigger is called.  In this case, we can determine exactly who signed this install and verify that it has not been modified since that signing.

''3.Unsigned XPI over HTTPS to trusted organization.''

This case is similar to Case 1, however we know two things.  First we know that the XPI has been downloaded securely over SSL from some organization. Second, we know “somehow�? that the user “trusts�? the organization.  It may be argued that if you trust the organization and you know that the XPI came from that organization, you should be able to treat it as “less scary�?.

''4.Unsigned XPI over HTTPS to untrusted organization.''

This is the case in which the user or the application doesn't trust the organization hosting the XPI.  What should we do here?  

''5.Signed XPI over HTTPS to trusted organization.''

Plenty of information here:  we know it was signed, we know it was downloaded over SSL, and we know it is a trusted organization.

''6.Signed XPI over HTTPS to untrusted organization.''

This is similar to Case 2, but we have HTTPS information.

''7.Unsigned XPI, local invocation.''

What do we do when we have a user double-click, drag and drop, or otherwise invoke an XPI outside of a transport?  This case, may be a duplicate of Case 1.

''8.Signed XPI, local invocation.''

May be a duplicate of case 2.