-----Original Message----- From: David B Harris [mailto:dbharris@eelf.ddts.net] > Or, hey, a different on-screen representation? Something like, I dunno, > "http://user:pass@site/"; being turned into "http://site/ (user: user, > password: pass)"? IMO, even this doesn't go far enough. We need to eliminate the use of URLs as authenticators entirely. Sites are popping up all over the place with *legitimate* hostnames confusingly similar to real ones. Getting tricky with URL encoding is only part of the problem. Users need to start *expecting* to see an SSL- or TLS-validated identity before they trust that they're seeing content from someone they think they are. You wouldn't walk into a store front with "Micro Soft" scrawled in crayon and reasonably expect to receive legitimate Microsoft products in return for your cash, but this is what people are falling victim to every day on the web. Every non-authenticated web page needs to be treated as unauthenticated, and browsers should make this clear up front. Users need to understand that when they are interacting with a web page at "example.com", they're only PROBABLY interacting with the "example.com" Internet domain. Instead, they believe they ARE interacting (in a trustworthy fashion) with "Example Widgets", even though there's no trusted relationship between "Example Widgets" and example.com they can see, other than example.com saying they are. Eliminate a user's dependence upon the URL as an authenticator (and a search engine, for that matter, guessing "www.<search term>.com"), and you eliminate the bulk of the problem here. People can do all of the stupid encoding tricks they want at that point and it won't matter, since the URL becomes almost entirely a machine-usable piece of data anyway, and the computer isn't easily deceived by such tricks. David
