Some People Can't Read URLs. Commentary on the recent “facebook login” incident from Jono at Mozilla Labs. I’d guess that most people can’t read URLs, and it worries me more than any other aspect of today’s web. If you want to stay safe from phishing and other forms of online fraud you need at least a basic understanding of a bewildering array of technologies—URLs, paths, domains, subdomains, ports, DNS, SSL as well as fundamental concepts like browsers, web sites and web servers. Misunderstand any of those concepts and you’ll be an easy target for even the most basic phishing attempts. It almost makes me uncomfortable encouraging regular people to use the web because I know they’ll be at massive risk to online fraud.
Sign in with 
OpenID
Maybe we should put together a URL-awareness campaign?
Suw - 2nd March 2010 10:24 - #
Yep, that's exactly what's needed. Just as Google made an animated cartoon to explain to people what a browser is, we could do with something really simple that explains what a URL is, what the Address Bar is for, and why people should keep their eyes on it. Because the vast majority just never look at it.
One option would be to put together a "staying safe online" course with open source materials, then encouraging geeks to volunteer to present it at their local libraries, schools and community centers. Pretty massive undertaking though.
Well, you don't need to fully understand every aspect of the URL. The essential part is identifying which bit of the URL is the domain name. And in my opinion that's not something we should be expected to do with our human brains, when it's a parsing task that's ideally suited for the computer.
The address bar in IE 8 looks like this:
http://feedmechocolate.com/stuff/ie8-domain-highli ght.png
This doesn't solve every problem (in particular, we still need to re-educate people to not just ignore that incomprehensible line of text they're used to having up there), but it goes a long way towards making the solution accessible.
Like Schneier says, security is a skill and the rest are tools. No technology can stop people from writing their password on a sticky note near the PC (or bleeding privacy to Facebook for that matter).
I think "understanding URLs" should be one of *many* issues a "net survival 101" kit should cover (not pidgin+OTR like we used to think).
Not sure who would read it anyway :(
I think it's worse—most people don't even notice URIs. Somewhat colloquial, but everyone who types a URI into Google certainly doesn't understand what a URI is, and I'd suspect many of them don't notice that it ends up in the URL bar. Google means they don't need to think about it.
That would suggest that URI awareness may not actually help, although if it doesn't it's really not clear what can, since there's nothing else that isn't entirely under the control of the site that can identify or differentiate different providers.
URLs aren't comprehensible because they're not consistent. If all we ever did was show the domain name, people would (largely) "get it".
We worry about the usability of remote controls for televisions; most of the time, a remote control is 10 digits plus an on/off switch. Why is it okay that we demand that users learn how to use URLs?
I've made this argument a lot lately, and fundamentally that users don't understand URLs is the motivation for Webfinger. Otherwise, we could just use URLs to personally identify people.
But people don't understand URLs, and no amount of training will ever make them understand. URLs are comprised of seven abstract concepts: scheme, userinfo, host, port, path, query, and fragment. Even if we say we can safely teach people only about domain, port, path, and query we still have to teach them that they can (usually) ignore the scheme, userinfo, and fragment.
URLs are great identifiers for machines, and they're an incredibly flexible and powerful tool for addressing content. URLs are basically the most complicated abstract concept that people are likely to encounter in their days; more complicated than bank routing numbers, more complicated than phone numbers, more complicated than postal addresses, more complicated than PIN codes, more complicated than driving in a foreign bloody country.
We complain about how banks screw up security using PIN codes, but if more and more commerce is moving online, isn't it our responsibility to devise secure, understandable approaches?
Blaine Cook - 2nd March 2010 17:42 - #
Some of this could probably be made somewhat easier if the browser visually emphasized the domain in the address bar and hushed down the rest.
Blaine: you're right, but that doesn't address my core question: how can users avoid online fraud if they don't understand URLs? How can we help protect them?
Simon: given processes like asking for usernames/passwords everywhere, sites asking for credit card numbers, etc, I'm not sure that we can so long as the security is pinned on using HTTPS (and thus requiring users to understand URLs).
I'd like to imagine a world where browsers helped enforce login security, by limiting logins wherever possible to trusted OpenID providers (for example).
The OpenID community needs to give up on URLs as identifiers. "Webfinger" (which is really just a pseudonym for "developers doing their jobs" imho) provides a pretty clear way forward; delegated email-addressed based logins provide a simple (for the user), universal approach to login that give us as security professionals a simple message to offer to users "Never give your password to anyone except your email provider."
Web developers in general need to stop aiming for OpenID-only, but push for permissive login approaches; support OpenID, Facebook Auth, Twitter Auth (i.e., OAuth-login/"RelMeAuth"), Microsoft LiveID, etc. and do discovery against email addresses to minimize the amount that users have to remember.
The ultimate goal of all this is to minimize the frequency with which users have to enter their passwords. Basically, the opposite of Verified by Visa - whereas VbV asks for a password EVERY time something happens, actually secure systems use transparent-to-the-user token systems (e.g., GMail, which almost never asks for your password, but is much more secure than VbV).
If we can reduce the number of times and places that users have to enter confidential details, we can offer much simpler stories and much more powerful tools to help them choose when it's okay to enter those details.
Blaine Cook - 3rd March 2010 02:29 - #
As part of the solution, I've been using Rapport, as supplied to me by NatWest bank in the UK.
It basically stores the certificate for a website, and gives me a visual indication if the certificate supplied in the same.
I know it does some other stuff, but that is the main feature that adds value for me. That and screenshot blocking.
Mark Swannie - 3rd March 2010 03:54 - #
I suspect, tangentially, that the new "omnibox" habit browser manufacturers have of letting people type anything they want into a location box and still resolving it (e.g "facebook login" typed into a location bar on Chrome or Firefox takes you to the ReadWriteWeb article) doesn't help. It just muddies the waters of awareness: "but I was looking at the address bar already!".
The trouble is, the numbers are not in your favour. User behaviour not to bother learning about these things is in fact entirely rational.
Read the paper linked from here:
http://weblogs.mozillazine.org/gerv/archives/2009/ 11/password_rules.html
From the abstract:
"If users spent even a minute a day reading URLs to avoid phishing, the cost (in terms of user time) would be two orders of magnitude greater than all phishing losses."
Bottom line: it's not worth a user's time to learn about this stuff.
Gerv
I don't know the answer, but I know that part of the problem is big, random hashes at the end of URLs. URLs need to be relatively short and hierarchical, so that users (myself included!) can understand what they are getting into.
I think part of that also is using optional Apache functionality that makes file extensions unnecessary. There's no reason why the end user needs to see them, so we need to start working without it. Maybe move to more POST-oriented browsing and less GET-oriented browsing. I know that breaks the back button, but Seaside (Smalltalk web framework) already breaks it. An in-page back button might be an acceptable compromise.
But it also means that we need to stop telling people to "click this link" in e-mail messages to activate accounts or reset passwords. I'm always trying to tell central IT at work not to send "click here to change your password" messages, but instead to tell the user to use the desktop shortcuts we create for that purpose. (I'm field IT, a different thing entirely.)
We can't warn against clicking links and then tell them to click the link. Nor can we warn against inputting excessive private information on a site, and then require them to do just that.
Most importantly, I think, is to get rid of the "what was your cat's grandmother's uncle's name" type questions. When every site asks them, it just exposes more information when any site is penetrated, making it easier to impersonate that user on every other site.
As for avoiding phishing, the important thing is the potential damage to the individual's privacy, reputation, and finances. When a relative suffered an identity theft a several years ago, I learned that ten years is not long enough to completely recover one's credit and reputation. It is well worth taking extra measures like URL-scanning to prevent that pain.
I agree that we need to teach web users about the address box and what the URL in that box means.
W^L+ - 3rd March 2010 23:52 - #