> On Oct 9, 2019, at 4:21 PM, Ronald Crane via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On 10/9/2019 3:17 PM, Paul Walsh wrote: >>> On Oct 9, 2019, at 3:06 PM, Ronald Crane via dev-security-policy >>> <dev-security-policy@lists.mozilla.org> wrote: >>> >>> On 10/9/2019 2:24 PM, Paul Walsh via dev-security-policy wrote: >>> it indefinitely. >>>> [PW] Here’s the kink Ronald. I agree with you. Mozilla’s decision to >>>> implement DoH is going to make everything much worse for the security >>>> world - it’s insanely bad .... >>> This is off-topic. >> [PW] I agree. But no more off-topic than URL shortening services, security >> systems for phishing detection and other aspects of this conversation. So >> let’s go back to talking about Firefox UI/UX for website identity. > > Huh? I understand the conversation to be about phishing, and URL-shortening > services are relevant to phishing. DoH is not relevant to phishing unless > it's spectacularly-incorrectly designed.
[PW] My point is this - a massive number of security solutions will become useless thanks to DoH. I don’t know if they can all be updated to work, but I know it will require a lot of work. Browser changes have a massive impact on other stakeholders who are also responsible for keeping society safe from harm while using the internet. > >>>> Incumbent security systems do help to provide a “dent” in the problem. But >>>> the dent isn’t good enough as per my previous commentary. >>>> >>>> As far as I can tell, absolutely nothing different has been tested in the >>>> past 10 years (sure, AI and other fancy words have been added, but not >>>> really helping much). Attacks and breaches are increasing, not decreasing. >>>> >>>> If Firefox had a new separate icon for website identity it would be the >>>> single biggest improvement to internet safety we’ve seen in the past 10 >>>> years - way bigger than encryption - in my opinion - I don’t have data to >>>> substantiate that particular assertion. >>> Since a foundation-supported whitelist would work without much user >>> training or intervention, I'd suspect it'd work better than any UI. But >>> that, also, is supposition. >> [PW] If you don’t have any UI, how does the whitelist work? According to >> your theory the existing system works. > > I was a little imprecise. I meant that there would be no positive indicator. > The UI would be similar to the scare-screen that FF uses to warn about cert > problems. Users wouldn't see it unless they tried to visit a site not listed > in the whitelist. Thus it would require less user training and intervention > than a positive indicator. It would not be invulnerable, of course. Phishers > would attempt to train users to ignore it. But they would do that for any > positive indicator, as well. The scare-screen has the advantage of being > in-your-face scary, so I intuit (no data to support this idea) that it'd be > more effective than any positive indicator. [PW] I love this concept Ronald. We haven’t yet launched a mobile solution designed with this in mind because we haven’t classified enough domains, sub-domains and social media accounts. We’ve verified more than the total number of EV certs on the market, but it’s still not even close enough to execute your UX recommendation. Most people would get too upset with that UX. I love it, but it’s not quite there yet. It would likely work better for enterprises as it’s a more flexible version of URI-based “Zero Trust”. It is possible to train people to look for a new indicator - in the same way you can train them to use a new feature or icon for other things. > >> Whitelist = EV certificates. > > No "=". EV certs would be one input of several. Many authentic domains > lacking EV certs are well-known and would be included in the whitelist. Any > domain already on a well-run blacklist (e.g., GSB) would *not* be included in > the whitelist. Any domain that appears to be phishing would be submitted for > verification to the appropriate contact(s) of the domain(s) that it appeared > to be phishing (e.g., "microsftpaypal.com" would get submitted to both MS and > Paypal). Pending verification, it would not be added to the whitelist. The > whole thing would be run by a well-trusted foundation (e.g., Mozilla) so > there's no need for complex reputation-based distributed review systems, > cryptotokens, etc. Yes I like all of this. My intention was to tease out, the fact that we are in agreement on more than one might have first concluded. You see, I think most people assume I’m a “CA lover” when I talk about website identity. Fact is, I think some are good, some are not good - just like any other type of company/solution. This is like a political debate. As soon as you’re in favor of one thing, you must be in favor of all things on that side of the debate. Thank you for providing me with an opportunity to say this. > >>>>>> I provided data and insight to how website identity UI can work >>>>> Please cite a specific URL of a paper showing the data on this. It should >>>>> have a description of its hypothesis, methods, and quantitative results >>>>> data. Something like that really could help push this conversation >>>>> forward. Please do not cite marketing papers like >>>>> https://www.metacertprotocol.com/assets/metacert_white_paper.pdf . >>>> [PW] I’m confused. I never cited that paper. There is zero evidence to >>>> suggest that the paper we wrote can or will success. We believe it can and >>>> will, but there’s no evidence in there. Why are you asking me not to cite >>>> something that I didn’t cite. >>>> >>>> I did however, provide a massive amount of data and referenced many >>>> companies I would consider to be a competitor of sorts. If you go through >>>> the threads you will also see company-specific data on a product but >>>> that’s not even referenced in the old white paper to which you refer. >>>> That’s not even our company website - it’s a blockchain project. >>> I'm confused. You said that "I provided data and insight to how website >>> identity UI can work" and "I did however, provide a massive amount of >>> data..." then when I asked for a paper showing the data (on the >>> effectiveness of "how [your proposed] website identity UI can work") and >>> how you got it -- so I can understand what you're proposing and what effect >>> it might have -- you seem to have told me that there's no paper to cite? >> There’s so much text/data in my previous messages that if you copied and >> pasted it into a document and then PDF’d it, you’d have a paper. > By "paper", I mean a document that (1) proposes a testable hypothesis; (2) > describes the methods its authors used to test the hypothesis; (3) describes > the results, ideally including links to raw data; and (4) summarizes the > highlights and briefly discusses any implications. Read anything in _Science_ > for specific examples. [PW] This is precisely what I provided Ronald - it sounds like you might have missed it. I’ll publish a link to where you and anyone else interested, can read just what you asked for. My dataset is massive enough to be very meaningful too. >> But I’ve never gone to that trouble. So, you can just as easily revert back >> to my email in which I wrote a lot of words. I will however be publishing a >> 5,000 word article on all of this. I will in fact PDF it so it’s in the form >> of a “paper” as I can understand why some people like that. > > OK, so no paper. Give me your address and I’ll print it and send to you :-)) - Paul > > -R > > > _______________________________________________ > 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
