faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
cool
by bangert on Monday 21/Nov/2005, @17:36
|
nice initiative on the SSL front.
about the phishing prevention i am not so sure. we should come up with a better solution to the identity verification problem and if that requires better technology _that_ should be supported.
fx. could banks sign our keys and when going to a site a small notification would tell me: this is your bank! if thats missing, then i know its not my bank...
another problem is the location field: half (if not more) of the people surfing the net, don't have a clue what is going on in there. now how do we make that more simple?
anyway, trying to blacklist or whitelist stuff is really not a smart way to do this. also, this problem is not new and exists in the same way in the real world: credit fraud, fake notes, weird guys ringing your door bell trying to sell stuff etc.
the reason why phishing (on the internet) is so attractive are:
- easy to do
- difficult to track
- clueless users
AFAICT the proposed solution does not solve any of these problems... the way i see it, it gets even worse, because "now we can feel safe again"!
... and i don't feel confident about sending each and every URL i visit to some server for authorization (even if it is only SSL).
in conclusion i would claim that the clueless user is the biggest problem here and i tend to agree that technology should be simple enough for the clueless user also... but he has do to his part as well. so lets educate those guys... |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: cool
by Stephen Leaf on Monday 21/Nov/2005, @19:56
|
http://www.microsoft.com/mscorp/safety/technologies/antiphishing/vision.mspx
This was in a comment in the msdn blog concerning MS's Anti-Phishing plug-in.
|
[
Reply To This | View ]
|
Re: cool
by Stephen Leaf on Tuesday 22/Nov/2005, @09:56
|
http://www.microsoft.com/mscorp/safety/technologies/antiphishing/vision.mspx
This was in a comment in the msdn blog concerning MS's Anti-Phishing plug-in.
|
[
Reply To This | View ]
|
The location field; a vestige from the early days!
by Herman Robak on Wednesday 23/Nov/2005, @00:17
|
"another problem is the location field: half (if not more) of the people surfing the net, don't have a clue what is going on in there. now how do we make that more simple?"
I am glad you mentioned this. Raw URLs would not have gotten a prominent display in the GUI, had the WWW been developed with the general public in mind. URLs were just the kind of notation that nuclear phycisists would find user friendly! ;-)
After 15 years, the URLs have become established, and the editable address field is something the users expect. No browser vendor would dare changing it drastically in one go. But I think drastic change is called for.
A URL consists 4-5 logical items:
1) The scheme/protocol, e.g. http:// (mostly optional, http being default)
2) The domain name
3) The port number (optional)
4) The path/filename
5) The query strings (optional)
The protocol could be replaced by an icon. The domain and the port number could be considered one unit. The path and the query strings are somewhat dependant on each other; commonly the query strings are an optinal appendage to the path.
Displaying all these as one continuous, unformatted text string is not a good example of usability.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early days!
by Matt on Wednesday 23/Nov/2005, @00:49
|
Actually this sounds like a really good idea. We could even hide the query completely, so that it is all displayed more clearly. Then have a button linked to a popup with all the queries editable.
I am liking this idea the more I think about it.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early days!
by Herman Robak on Wednesday 23/Nov/2005, @01:34
|
If the address field was read-only, changing the display to something more readable and structured would be trivial.
However, it is editable. The users expect to be able to paste raw URLs into it, and to edit those URLs freely. Because of this, any change is likely to upset a lot of users.
If the address field accepts a full URL with query strings as input, yet hide the query strings when the links are accessed by clicking them, then it breaks the "principle of least surprise". How could one make it clearer to the user what is going on? Press Tab to switch from raw to formatted URL? (too power-user-ish, IMHO)
|
[
Reply To This | View ]
|
Lets all sing the University of MN fight song now
by bluGill on Wednesday 23/Nov/2005, @07:05
|
Remember Gopher? It died about 1995, but in the early 90s it was more popular than WWW, and growing faster. One major limitation is it didn't have a URL. Every site gave directions in the following form:
goto the UofMN main gopher (which all clients had programed in)->all the servers in the world->North America->state->Company main page->link->link->text file. (Gopher did not support graphical pages like the web did).
URLs may not be perfect, but that was one large advantage of the web - you could give someone a (complex) URL and they would get right to their site.
Maintaining the UofMN main gopher site cost so much money that they started to charge for use of gopher, and killed the whole thing off.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by Stefan Wagner on Wednesday 23/Nov/2005, @07:07
|
I disagree completly!
I paste about 100 URLs per day and splitting them into 5 fields would be annoying.
How often do you keep anything fix but the protocol?
...but the port?
...but the path-and-file?
Sometimes you may only change the query-string, but who does this by hand?
If it is build as optional feature (splitted URL vs. classical URL), and the user is free to choose: Well, I can agree.
People would learn more easily how to read an URL, and might switch to the more usable feature (classical) later on.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by Herman Robak on Wednesday 23/Nov/2005, @07:45
|
I am not sure whether _editing_ the URLs in a 5-part form would be preferrable. But I think it is worth considering.
As for copying and pasting: there are context menus for page addresses and link URLs. I think a raw/formatted toggle is called for, to not disrupt the workflow of those who rely on raw, editable URLs in the address field. Changing it over night with no way back is way too disruptive.
bluGill: Sure, we shall forever be able to pass URLs around in one piece. Just like we can pass around files of HTML edited in Notepad. They just won't appear verbatim in modern clients, like HTML is not shown like a bunch of tags in monospaced font to most users. Old-timers will complain during the transition, because they think the URL widgets are more convoluted than plain raw URLs.
It's time to expect a richer representation of URLs than we are used to today! For example, a URL widget could contain the anchor text. Of course, the anchor text is not always helpful, like the WAI-defying "here" or "next". But would it hurt to make such accessibility failures stand out more?
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by Matt on Wednesday 23/Nov/2005, @20:44
|
Yeah your right, you do need a way to toggle off and on the "formatted URL" and you also need a quick way to copy a link. But both of those features can be implemented along side the formatted features.
I guess one of the reasons why I really like this idea is because in many cases the URL ends up having so many different query strings that they become completely unreadable and quite useless at a glance. Being able to quickly see the site name and path gives an indication of the sites structure. Which I think can be useful for navigation.
Matt
|
[
Reply To This | View ]
|
query strings being replaced with long paths
by Herman Robak on Thursday 24/Nov/2005, @00:04
|
Keep in mind that some CMSses "cheats" with their URLs to make them look like static content URLs:
From
http://www.some-cms.tld/cms-app.cgi?topic=foo&article=bar
To
http://www.some-cms.tld/cms-app/foo/bar
The latter is shorter and cleaner. And if the CMS is clever enough, it can provide all the proper directives (ETag, Last-Modified, Content-Length...) of a proper static document (brace yourselves for some weird bugs...)
This can be used to make the URLs more opaque, too. Instead of a lot of semi-readable parameters, you get one or two really long numbers, or random strings. You don't know how much of the URL is the path to the web application and where the input parameters to the web app start. Systematic digging for articles or vunlerabilities becomes harder that way.
Hence, the path and the query string are not separate entities.
|
[
Reply To This | View ]
|
Re: The location field; a vestige from the early d
by jameth on Friday 25/Nov/2005, @21:11
|
I've suggested before and will suggest again that syntax highlighting be added to the address bar. It's not too hard to have some highlighting of key portions of the text (protocol, separator marks, query entries, whatever) and doesn't completely break proper usage of the location bar (pasting paths and hand-typing addresses). Also, it might make it easier for new users to learn what that stuff actually means.
Of course, I suggested that first over a year ago, so I expect nobody is gonna rush to implement it now.
|
[
Reply To This | View ]
|
Usability versus phishability
by Herman Robak on Thursday 24/Nov/2005, @00:36
|
The original posting was about user interfaces to maintain security. In such a context, "usability" gets a different meaning. The usual meaning is along the lines of "whatever makes the user happy, empowered, productive, faster, and is easy to learn".
Usable security features have another primary goal: Keep the user out of harm's way. Making sure that the program follows the user's _reflected_ intent. That often means deliberately slowing down the user, so that there is indeed time to reflect. It also means telling the user about perils that the user may know little or nothing about, yet avoid crying wolf too often.
In this context, the address bar has a flawed design. It is quite evident that it fails to keep the majority of users out of harm's way. The address bar does not ensure that the browser follows the user's real intent. All the successful phishing scams serve as proof of that.
The web is about serious stuff now. People buy expensive stuff and manage bank accounts with it. Yet they are totally oblivious of the underlying architecture. Which is OK! You don't need to know the building structure of a house to use it safely. Opening and closing doors is not supposed to have fatal side effects. Web browsers and web applications need to be the same way, so users can trust their gut feeling without getting burned again and again.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
