I’m sorry for the follow up message - I know we all get too many notifications 
already. But I forgot to add that I was the founder and CEO of Segala - the 
company referenced on the W3C website that I referred to below.

Sorry about that.


> On Oct 9, 2019, at 4:17 PM, Paul Walsh <p...@metacert.com> wrote:
>> On Oct 9, 2019, at 3:23 PM, Ryan Sleevi <r...@sleevi.com 
>> <mailto:r...@sleevi.com>> wrote:
>> On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy 
>> <dev-security-policy@lists.mozilla.org 
>> <mailto:dev-security-policy@lists.mozilla.org>> wrote:
>> I believe an alternative icon to the encryption lock would make a massive 
>> difference to combating the security threats that involve dangerous links 
>> and websites. I provided data to back up my beliefs. 
>> Here's peer-reviewed data, in top-tier venues, that shows the beliefs are 
>> unfounded:
>> https://ai.google/research/pubs/pub48199 
>> <https://ai.google/research/pubs/pub48199>
>> https://ai.google/research/pubs/pub45366 
>> <https://ai.google/research/pubs/pub45366>
> I don’t disagree with this research. But it’s the wrong research Ryan, asking 
> the wrong questions. You haven’t explained why any of my research draws the 
> wrong conclusions, but I’ll explain why Google's is fundamentally wrong. 
> Perhaps you can do the same for me when you get time. 
> 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. 
> 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/>
>> 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. 
> The research to which you refer, is from a vendor’s marketing solution. 
> Google is the vendor and Chrome is the marketing solution. This is no 
> different to MetaCert asking 85k power users. 
> We had absolutely no reason to lie to ourselves or to skew opinions for this 
> conversation. 
> We sell security services while verifying domains for free. We needed to do 
> the research to find out if we had a solution to a problem. In theory, we are 
> putting CAs out of business. And if all browsers implemented better UI for 
> website identity, it would put our flagship solution out of business. If I 
> convinced you that you are wrong and I’m right, I’d have more to lose than I 
> would to gain. Right now I’m putting industry and people’s safety ahead of my 
> shareholders. I’m completely impartial to browser vendor vs CA debates on all 
> fronts.
>> The reverse-proxy phishing technique bypasses Google’s own Safe Browser API 
>> inside their own WebView while their own users sign into Google pages while 
>> using Google’s Authenticator for 2FA. So their answer? In June 2019 they 
>> banned users from signing into Google’s pages while using mobile apps with a 
>> WebView. This tells you what you need to know about Safe Browser API - 
>> finally I have the evidence to prove that it’s an “ok” solution at best. 
>> Most security companies still think it’s great - because they’re not in 
>> possession of all the facts. 
>> While I suspect I'll regret replying to this message, since so much of it is 
>> off-topic for this discussion Forum, I do want to point out the attribution 
>> error being made with correlation versus causation. You're making a specific 
>> conclusion about why WebView-based sign-ins were banned, without any 
>> supporting data, along with factually-suspect statements that are 
>> unsupported.
> [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? 
> 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 :)
> While there are many amazingly strange weaknesses with Google’s framework 
> that make it less safe than a browser, it doesn’t mean that my conclusion is 
> wrong. If Google (or any other company) was able to detect the attack OR the 
> domain, it wouldn’t need to ban users from signing into Google websites. What 
> other reason can there be?
> You are taking everything personally. What hidden intents could I possible 
> have? I have absolutely nothing to gain by encouraging browser vendors to 
> implement better website identity solutions. I have nothing to gain by 
> telling the world that even my security products are unable to detect every 
> new phishing URI or website. What ulterior motives can I have? I’m not 
> questioning your motives or that of Google’s. I believe everyone at Google 
> and Mozilla is simply wrong about website identity, because they’re using 
> their personal opinions or they’re asking the wrong questions. 
> Is my conclusion wrong?
>> For example, this unsupported speculation conveniently ignores that, until 
>> Android 8.0 (Oreo), WebView did not participate in Safe Browsing checks, for 
>> example, 
>> https://developer.android.com/guide/webapps/managing-webview#safe-browsing 
>> <https://developer.android.com/guide/webapps/managing-webview#safe-browsing> 
>> . It also seems, mysteriously, to ignore that WebView-based sign-ins and 
>> credentials gives the hosting application full access to the user's cookies 
>> ( https://developer.android.com/reference/android/webkit/CookieManager 
>> <https://developer.android.com/reference/android/webkit/CookieManager> ). 
>> It's an interesting theory that the reason for forbidding is phishing, but 
>> conveniently ignores many facts in order to try and support it.
>> I suspect this is all the result of ignoring the stated reasons, such as 
>> https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
>> <https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html>
>>  , and instead speculating about hidden intents. I'm hoping you could 
>> provide data to support the claim being made?
>> WebAuthn-based security is something we can agree on being brilliant. 
>> Finally. However, we will not see mainstream adoption for it ever, or for a 
>> very long time. So, we need to do something to protect people for the next 5 
>> years.
>> It would be remiss not to highlight how effortless incongruous this is with 
>> the previous arguments. The discussion of phishing has, to date, been 
>> focused on "large" targets - for example, Google, Microsoft Office 365, and 
>> PayPal. This is perhaps unsurprising, as they're popular phishing targets. 
>> The adoption of WebAuthN by those three sites would, thus, correspondingly 
>> have a marked decrease in phishing.
> 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. 
>> Amazingly, there's public data to support this hypothesis, 
>> https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/
>> <https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/>
> We will absolutely see a decrease in phishing, *when* we see user adoption. 
> I’m not debating that. 
> - Paul

dev-security-policy mailing list

Reply via email to