Gervase Markham wrote: > Jean-Marc Desperrier wrote: >> You don't care *who* the owner of the cert is. What you care about is >> if he intends to use his signing cert to distribute spyware >> extensions. And his identity tells you nothing about that. > > No, but it does tell you whose door the police can go knocking on if he > logs into your online banking and steals all your money.
How effective has this approach been until now to block spam and spyware ? Is it really that difficult to identify those responsible for it, especially in the case of spamware, do you really think it's much harder to escape reliability after buying a signing certificate than to escape it when operating a large scale spam platform ? How hard and how long will it be to convince a judge take the right decision between one side's "spyware" and the other's "innovative marketing technic" ? In real life "we'll sue" simply doesn't work to deter spyware and MoFo just doesn't want to wage this fight as proven by this : http://weblogs.mozillazine.org/asa/archives/2007/03/please_get_fire.html (I mean given that you know this exist where is your action to get judicial injunctions to make it stop ?) > Except that you would need to review all the code before it was signed, > not just at the beginning, and (in the case of malicious intent) find > things the code did which the code author was intending to hide from > you. Which is impractically expensive and time-consuming. Code review is certainly impracticable, and the front of determining what should be signed is not really rosy. But I think functional review would bring more than you might believe. It's a significant barrier to entry if someone who wants to distribute a spyware extension needs first to integrate real functionalities inside it, that can convince a reviewer it's enough useful for the general public to deserve been signed (there would be documented alternatives to signing when the extension is only useful to a closed group of people). Extensions of course would not be accepted when there's already another extension that does the same, or has so few difference that it would be better to provide a patch to it. And when you say rejecting malicious extensions is impracticable, doesn't AMO already have to handle this category of problems when deciding if an extension should be accepted on the site ? > So it seems that you are suggesting that we should issue code-signing > certificates to anyone who wants them, and use revocation to pull out > the bad actors? In short yes. Just that it's not to anyone who wants them, you have the final say to who gets them, and if you experimentally find out you have to be very restrictive to avoid a bad experience for your users, then you'll just do that. > The problem with that is that because there's no strong identity, the > bad actor will just go back and get another code-signing cert from you > and repeat the process. With the functional review I suggest above, he will have first to create a different, functionally useful extension. I don't think there will be many cycles, or at least, it will the added value of leading to the creation of many good extensions :-) The point is it's not *that* difficult for the bad actors to do the same with the existing code signing commercial CAs. And in this case, the seriousness of the CAs and the effectiveness of the legal threat are your only lines of defense. Using revocation to pull out the bad actors will be a lot more difficult to make really work and be effective. Of course you can also choose to make deals to only accept a few selected commercials CA for which a highly effective revocation channel will be in place (in addition to a high quality identity review process, and only accepting requests from selected countries where the legal threat will be effective). _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
