On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy < 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/pub45366 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. > 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. 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 . 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 ). 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 , 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. Amazingly, there's public data to support this hypothesis, https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
