> On Oct 9, 2019, at 3:06 PM, Ronald Crane via dev-security-policy > <email@example.com> wrote: > > On 10/9/2019 2:24 PM, Paul Walsh via dev-security-policy wrote: >>> On Oct 9, 2019, at 1:07 PM, Ronald Crane via dev-security-policy >>> <firstname.lastname@example.org> wrote: >>> >>> On 10/8/2019 7:16 PM, Paul Walsh via dev-security-policy wrote: >>>> [PW] Ronald, I don’t believe better detection and prevention is the answer >>>> for anti-phishing - but not trying isn’t an option, obviously. With >>>> billions of dollars being invested in this area, and with hundreds of >>>> millions changing hands through M&A every year, the problem is getting >>>> worse. Every week we read about yet another security company with >>>> anti-phishing [insert fancy words here]. It’s ain’t work’n. >>>> >>>> I believe I demonstrated in a previous message, with data and techniques, >>>> why it’s impossible for any company to detect every phishing URL or >>>> website. >>> The point isn't to detect "every" phishing URL, but to put a big dent in >>> the problem, and to keep denting 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. >> 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. Whitelist = EV certificates. No UI = Firefox Whether you or I reference EV, website identity or whitelists it all amounts to the same thing. It amounts to someone making an assertion about trust for something. As long as you trust the source you can trust the assertion. For the sake of argument let’s assume we’re talking about a decentralized system where the community decide on what’s safe. How does the browser tell users? I know you didn’t say “no UI” but you’re saying something is better than UI so I can only extrapolate that you think UI is unnecessary. > >>>> It’s impossible to properly verify the domain by looking at it - you need >>>> to carry out other checks. >>> "Impossible" is false. I would accept that "difficult for most users" is >>> true, though my view is based more on intuition than data. That doesn't >>> mean that we shouldn't make it easier to verify domains, nor does it mean >>> that we shouldn't try other tacks in addition, such as the >>> foundation-supported whitelist I proposed, and better means of >>> site-identity verification, as you have proposed. >> [PW] You’re right - it’s false. Let’s say that it’s exceptionally difficult >> for almost everyone in the world.... > OK. >>>> It’s simply not solving the problem. >>>> >>>> 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. 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. - Paul > > To return to a different phishing-related topic I mentioned earlier, does > anyone know why registrars are registering obvious phishing domains? Does > anyone know how (if?) registrars are regulated, and by whom? > > -R > > _______________________________________________ > dev-security-policy mailing list > email@example.com > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy