On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh <p...@metacert.com> wrote: > We can all agree that almost no user knows the difference between a site > with a DV cert and a site with an EV cert. I personally came to that > conclusion years ago. I wanted data, so I asked more than 3,000 people. > Almost everyone assumed the padlock represents identity/safety. >
If you read the research linked, you'll find it specifically addresses this, and points to the fact that positive security indicators lead to inaccurate conclusions like this, whether EV or DV, and thus important to remove them to assure folks do not make attribution errors. Since the you later glibly joke about taking your e-mails as a post and publishing as a PDF and calling it peer reviewed, I think it's reasonable to conclude you didn't actually read the links, nor look at the publication venues, or that you don't recognize and/or respect them as leading scientific and academic conferences at the forefront of the space and industry you participate in. > I can cite research for search annotation through a browser add-on (2007). > It was formally endorsed by the W3C Semantic Web Education and Outreach > Program as one of the most compelling implementations of the Semantic Web. > But it’s out of date and doesn’t answer the right questions. But here it is > https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ > Thanks. This helps confirm that it was not peer reviewed research, but a marketing case study, completed in 2007. > Do you have any peer-reviewed data to support your beliefs? It seemed like > the only data shared was from vendors marketing solutions in this space, > although perhaps it was overlooked. > > > [PW] Perhaps you did overlook it - hard to say as you didn’t reply to the > thread that contained the data. > Apologies, the volume of the mail you write, versus the new data provided, makes it difficult. Since I must have missed it, it might be useful to provide specific links to your message, or better yet, specific links to the data that has undergone the similar level of scientific rigor and well-respected peer-review. > [PW] Why haven’t you provided any insight to suggest why I’m wrong, > instead of asserting that I haven’t provided evidence to back up my > assertions? > https://twitter.com/krelnik/status/472046082135162881 If you review the links provided, you will see that the claims made in your prior e-mail are directly, and easily, contradicted, as being both factually false and ahistorical. The assertion that WebView-based logins were disabled (in 2016) were because of failures in the SafeBrowsing API (not implemented until March 2017) is so easily disproved as factually false and ahistorical that it beggars belief that I have to refute it. > But because you asked so nicely: > > The following was published by Jonathan Skelker, Product Manager, Account > Security Google April 2019 > > “[snip]… one form of phishing, known as “man in the middle > <https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/>” > (MITM), is hard to detect when an embedded browser framework (e.g., Chromium > Embedded Framework <https://bitbucket.org/chromiumembedded/cef> - CEF) or > another automation platform is being used for authentication. MITM > intercepts the communications between a user and Google in real-time to > gather the user’s credentials (including the second factor in some cases) > and sign in. Because we can’t differentiate between a legitimate sign in > and a MITM attack on these platforms, we will be blocking sign-ins from > embedded browser frameworks starting in June. This is similar to the > restriction > on webview > <https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html> > sign-ins > announced in April 2016. > > > https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html > > I must extrapolate that if Google is unable to detect these attacks inside > apps that use the Chromium embedded framework, it means it is unable to > detect the same attacks inside desktop and mobile versions of Chrome. I > don’t think any company can - I’m not pointing the finger at Google - I’m > pointing it at the problem and lack of solutions to the problem globally. > > Separately, I wrote about the potential threats of WebView / frameworks > that display web content inside apps in April 2015, so I’m very much aware > of everything you say > https://developer.metacert.com/blog/how-webview-has-weakened-the-tcb-of-the-web-infrastructure/ > In > fact, it took people like me to bring these problems to the attention of > their makers. While I didn’t turn this into a paper, it was referenced by > senior security researchers at some big firms. Perhaps I should PDF it and > you can call it a peer-reviewed paper :) > Again, I have to refer to the tweet. The suggestion that you must extrapolate that a third-party fork is equivalent to a browser is another example of a conclusions being jumped to over the the uncrossable chasm of inconvenient things like "truth" and "reality", as is the conflation of MITM and phishing. There's a remarkably profound irony in that, when coupled with the earlier remarks excoriating that everyone should be able to have secure connections to their desired origin, free of network-based MITM. While this will be my last post to this thread, because I can see there's unlikely to be any productive to discuss further with you, I do want to highlight how, again, and subtlely, you've both shifted your claim to appear reasonable, even though you're claiming something now entirely different from a few messages ago, while asserting it's the same claim. Anyone who reads through these messages can see the shift: That the claim was that SafeBrowsing doesn't work because WebView disabled logins due to phishing, then ignoring that WebView did not implement SafeBrowsing checks at the time and there were instead application-level security concerns, and asserting that because a third-party fork had sign-ins disabled due to potential MITM, one can conclude the same about both upstream and about phishing detection, despite the same post highlighting.... application-level security concerns. Comparing apples-to-orangutangs, while asserting all are completely hoopty froods, is... well, it's not a reasonable discussion, by any means, and unlikely to be productive. It's unfortunate that you shift to ad hominem attacks later on, and so that's not worth bearing down on nor continuing. That's a classic sign of abuse, which combined with the present sealioning that has happened on this and the other thread, is a perfect reason to walk away. > Your last comment isn’t correct. So I’ll fix it, "The adoption of WebAuthN > by those three sites *and all of their end-users/customers* would, thus, > correspondingly have a marked decrease in phishing." > > I’d love nothing more than for every website to support WebAuthN and for > every consumer to adopt it. I have absolutely nothing negative to say about > it. I’m commenting on my personal opinion on how likely it is to see mass > adoption in the very near future. > Thanks for confirming that we have viable technical solutions, that user education is, at best, a short-term solution, and one with a demonstrated lack of success in achieving the goals desired or being respectful of individuals. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
