From: "Geo" 

This is a multi-part message in MIME format.

------=_NextPart_000_01AA_01C6D48B.52B0A9D0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The feature you mention only allows to always approve, not always deny. =
For an admin it would be nice to always deny specific trusts.
  "Rich"  wrote in message news:45019310$1{at}w3.nls.net...
     While there is a feature for a user or admin to trust a code signer =
so that no user confirmation occurs, I never mentioned it.  I would not =
recommend this for an individual user as there are so few occasions for =
prompt to justify.

     If you can't remember who you trust or even make a decision each =
time you have a problem that has nothing to do with computers.

  Rich

    "Geo"  wrote in message
news:45014108{at}w3.nls.net...
    What happens when a vendor you trust does something like oh say =
loading the first half of WGA on your system without your approval? Is =
there a checkbox somewhere that says "never trust the bastards
again"?

    Kinda hard to remember who you trust and who you don't without a =
nice feature that helps keep track. The only thing the OS offers is to =
tell you who signed it. It doesn't allow you to mark them as untrusted.

    Geo.
      "Rich"  wrote in message news:4500ee78$1{at}w3.nls.net...
         No.  You look at the signing certificate to see if you trust =
both the signing party and the certification path.  If you do not, do = not
trust the signed entity.  If something is not signed, you don't have = even
this option.  How do you choose what to trust?

         The average Joe relies on the identity of the signing party =
alone and assumes that the certification authorities that are not =
distrusted have been vetted.

         In practice, have you ever known this to be a problem with =
signed code?  How much actual malware do you hear of that is signed?  I =
can't think of any that wasn't some PR stunt by someone that signed a =
demo which he released under his own name anyway.

      Rich


------=_NextPart_000_01AA_01C6D48B.52B0A9D0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








The feature you mention only allows to =
always=20
approve, not always deny. For an admin it would be nice to always deny = specific=20
trusts.

  "Rich" <{at}> wrote in message news:45019310$1{at}w3.nls.net...
     While
there is a feature =
for a user=20
  or admin to trust a code signer so that no user confirmation occurs, I =
never=20
  mentioned it.  I would not recommend this for an individual user =
as there=20
  are so few occasions for prompt to justify.
   
     If you
can't remember =
who you trust=20
  or even make a decision each time you have a problem that has nothing =
to do=20
  with computers.
   
  Rich
   
  

    "Geo" <georger{at}nls.net>=20">mailto:georger{at}nls.net">georger{at}nls.net>=20
    wrote in message news:45014108{at}w3.nls.net...
    What happens when a vendor you =
trust does=20
    something like oh say loading the first half of WGA on your =
system=20
    without your approval? Is there a checkbox somewhere that says =
"never trust=20
    the bastards again"?
     
    Kinda hard to remember who you =
trust and who=20
    you don't without a nice feature that helps keep track. The only =
thing the=20
    OS offers is to tell you who signed it. It doesn't allow you to mark =
them as=20
    untrusted.
     
    Geo.
    

      "Rich" <{at}> wrote in message news:4500ee78$1{at}w3.nls.net...
        
No.  You look =
at the=20
      signing certificate to see if you trust both the signing party and =
the=20
      certification path.  If you do not, do not trust the signed=20
      entity.  If something is not signed, you don't have even this =

      option.  How do you choose what to trust?
       
         The
average Joe =
relies on the=20
      identity of the signing party alone and assumes that the =
certification=20
      authorities that are not distrusted have been vetted.
       
         In
practice, have =
you ever known=20
      this to be a problem with signed code?  How much actual =
malware do=20
      you hear of that is signed?  I can't think of any that wasn't =
some PR=20
      stunt by someone that signed a demo which he released under his =
own name=20
      anyway.
       
      Rich
       
       

------=_NextPart_000_01AA_01C6D48B.52B0A9D0--

--- BBBS/NT v4.01 Flag-5