On Tue, Oct 29, 2019 at 6:29 PM Paul Walsh <p...@metacert.com> wrote:
> > On Oct 29, 2019, at 11:17 AM, James Burton <j...@0.me.uk> wrote: > > Hi Paul, > > I take the view that the articles on the CA Security Council website are a > form of marketing gimmick with no value whatsoever. > > > [PW] More useless feedback that only serves to insult someone trying their > best to add value. As I’ve said *over and over again*, if browser vendors > did what I recommended in the article, my own company's flagship product > would be *rendered useless*. If you call that “a form of marketing > gimmick" you should probably avoid going into marketing. > When I read the CA Security Council website around the two year mark, I found the content more directed toward the marketing end to help CAs promote expensive products such as extended validation certificates. My opinion on the matter hasn't changed. This isn't throwing insults at each other, it's about improving web security and directing people to the wrong conclusions which the CA Security Council has done is bad for the improvement of web security. > Every data point was taken from a competitor with links to their work. If > you disagree with my conclusions, say so. But throwing insults is hardly > adding value, is it? > > - Paul > > > Thank you > > Burton > > On Tue, Oct 29, 2019 at 5:55 PM Paul Walsh via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hi Nick, >> >> > On Oct 29, 2019, at 7:07 AM, Nick Lamb <n...@tlrmx.org> wrote: >> > >> > On Mon, 28 Oct 2019 16:19:30 -0700 >> > Paul Walsh via dev-security-policy >> > <dev-security-policy@lists.mozilla.org> wrote: >> >> If you believe the visual indicator has little or no value why did >> >> you add it? >> > >> > The EV indication dates back to the creation of Extended Validation, >> > and so the CA/Browser forum, which is well over a decade ago now. >> > >> > But it inherits its nature as a positive indicator from the SSL >> > padlock, which dates back to the mid-1990s when Netscape developed SSL. >> > At the time there was not yet a clear understanding that negative >> > indicators were the Right Thing™, and because Tim's toy hypermedia >> > system didn't have much security built in there was a lot of work to >> > do to get from there to here. >> > >> > Plenty of other bad ideas date back to the 1990s, such as PGP's "Web of >> > Trust". I doubt that Wayne can or should answer for bad ideas just >> > because he's now working on good ideas. >> >> [PW] I agree with your conclusion. But you’re commenting on the wrong >> thing. You snipped my message so much that my comment above is without >> context. You snipped it in a way that a reader will think I’m asking about >> the old visual indicators for identity - I’m not. I asked Wayne if he >> thinks the new Firefox visual indicator for tracking is unnecessary. >> >> I don’t want to labour my points any more. Those who disagree and took >> the time to comment, aren’t willing to exchange meaningful, constructive, >> respectful counter arguments. Those who disagree but aren’t commenting, may >> or may not care at all. And those who agree mostly show their support in >> private. I feel like this conversation is sucking up all the oxygen as a >> result. >> >> If we are all doing such a great job, attacks wouldn’t be on the rise and >> phishing wouldn’t be the number 1 problem. And we all know phishing is >> where a user falls for a deceptive website. >> >> One last time, here’s the article I wrote with many data points >> https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/ < >> https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/> >> >> I’m going to edit this article for Hackernoon, to include additional >> context about my support *for*encryption, https, padlock and free DV certs. >> I support them all, obviously. But some people assume I don’t support these >> critical elements because I pointed out the negative impact that their >> implementation is having. >> >> Thanks, >> - Paul >> >> > >> > Nick. >> >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
