I’ve replied for the record even though you say this is your last post on this particular thread, or to me. I’m good with that as I don’t think you care about what anything anyone says outside the browser vendor world anyway.
> On Oct 9, 2019, at 5:09 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > > On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh <p...@metacert.com > <mailto: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. [PW] Our data with 85,000 active users proves otherwise. And you’ve done nothing to counter anything I actually said. I can’t find any product screen shots that users used when researching ***new*** visual indicators for website identity. Research on EV/DV is completely meaningless as we’ve already established that browser implementation was poor at best. > > 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. Generally, I question everything that Google has to say about anything in relation to privacy and security - so there is a lack of respect in regards to motives. But that doesn’t mean I don’t read them. And it doesn’t mean I don’t have friends who work for Google. My comment about me PDF’ing something was me making fun of myself - it had nothing to do with my opinions about other people’s work. I’m not an academic. I never even went to university, so my writing skills aren’t as good as anyone who actually writes papers like the ones you referenced. What I write is based on real world use cases - not theory-based research. They are very different and both are important. > > 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/ > <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. [PW] This one in particular was reviewed in great detail by all of the W3C Semantic Web Education & Outreach participants. They reviewed and voted that it was “one of the most compelling implementations of the Semantic Web”. Segala and its work was then used as a use case for the W3C POWDER initiative, which formally replaced PICS in 2009. But it’s all very old and out of date - that was the point I was actually trying to make. https://www.w3.org/blog/SWEO/ <https://www.w3.org/blog/SWEO/> > >> 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] You’re right about my messages - but it’s because people are asking me the same questions that have already been answered - but rather than say that, I prefer to reply. If you want “peer-review” evidence please stop referencing Google and reference companies that aren’t biased and who actually have other stakeholders and users best interests in mind. Unless there were non-Google employees involved, in which case I would apologize. > > [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 > <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. Perhaps you could reference what I say, with evidence on why it’s wrong - instead of making general assertions. > > 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 > > <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/ > > <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. [PW] I have no idea what you’re saying here. Need another coffee perhaps. > > 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. [PW] More general assertions with no substance. That’s generally your thing when it comes to debating. We should just believe you because… > > 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. [PW] What are you talking about? Since April 2018 WebView has been using Safe Browser https://android-developers.googleblog.com/2018/04/protecting-webview-with-safe-browsing.html?debug=true <https://android-developers.googleblog.com/2018/04/protecting-webview-with-safe-browsing.html?debug=true> In 2019 Google says it’s unable to detect phishing attacks inside WebView. How am I shifting? > > 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. [PW] I haven’t been able to find a single data point provided by you anywhere on the internet (including publicly accessible emails and forum posts) to substantiate anything you say about website identity and visual indicators. Nothing. It’s like you’ve done zero research yourself. And you only seem to reference Google researchers. Anyway, ho hum. - Paul _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
