Earlier quoted context omitted.
I agree that this experiment isn't demonstrating a perfect mitigation, but it's important to appreciate that it's currently vastly easier for a phisher to permute paths and subdomain components than it is to create a convincing ETLD+1. There are various reasons for this, including less text for a phisher to work with and registration requirements for ETLD+1 domains (which means they can't be iterated and dumped as qu…
What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857 The issue isn't users recognizing path, it's the domain. It's also that they aren't taking special care while logging in. Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on…
The team may choose to do something like that in the end. That's really the point of experimenting with different approaches; they use them to get feedback, run user studies, and get a sense of what works best.
> Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page.
That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.