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.

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 
[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.

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.

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.
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.


dev-security-policy mailing list

Reply via email to