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?


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
dev-security-policy mailing list

Reply via email to