Re Location bar Proposal 1.2
John Bird
are:
1 - How easy it is to spoof a site, who not looking at the location bar
would have thought they were at Mozilla etc?
2 - This pop-up domain name also will be easy to spoof, in the same way this
web site does it, as the popup is in the page area which is essentially
under the control of the web site.
Apart from fatal flaw that it is a good idea, but I reckon it needs to be
done on a part of the screen the web site absolutely has no control over,
and that has to be something basic and unalterable in the design of the
browser, that is cannot be altered off by any settable option either, other
than maybe to be turned off. That way anyone seeing such a domain name
pop-up knows for certain it HAS come from the browser and not the web site
or anything else.
At present the status bar does show the URL of a link as the mouse hovers on
it, otherwise it shows the page load status, or "Done". Maybe it could also
show rather than "done" once a site is loaded - which is pretty useless, it
could instead say
"Loaded https://www.mybank.com/login" for example,
Some other thoughts relevant to how typing in the location bar works:
3 - have you considered how many users either by accident or deliberately
type a search term into the URL bar
Eg "Firefox Download" as they know from experience that this may bring up a
Google search for instance. A lot of people I know also get confused all
the time about typing a search term in the URL bar when they are on the
Google page....that is they do not realise the cursor is in the wrong place.
4 - Autocompletion.
I am putting together some ideas, and maybe some mock screenshots of how the
autocompletion ought to work. I reckon, as an option that when one starts
typing in the URL bar, it should not only match from the history, but also
as an option from booknarks. That raises the option about whether the
search should be on the bookmark URL, or the Bookmark page title, or both
(which I would favour). And.....also it should search the open tabs, as I
reckon for lots of people like me the page is already open in another
tab......
At the moment finding a previously viewed web page can be done in too many
different ways.......
If its in the history you get autocompletion hints.
If you press (Windows) CTRL+B you get a side-bar search box for bookmarks,
but no bookmark folders shown
If you press (Windows) Alt+B you get a list of bookmarks and bookmark
folders and no search box.....
There is no way of searching open tabs at present.
Maybe these could all be added - as an option - to the autocompletion.
History first, then matches from open tabs, then from bookmarks....simple
but elegant. My only wonder is the delays as bookmarks are searched?
In such a case the autocompletion list could have some little icon at the
left hand end of it saying where its from,
One icon or symbol for history, another for other tabs, another for
bookmarks,.....
Whether it is a good idea to lump all this functionality together into the
location bar is a good debate, but certainly there needs to be a more
universal way of searching history and bookmarks and other tabs than
currently....
John
Mardak
> 2 - This pop-up domain name also will be easy to spoof, in the same way this
> web site does it, as the popup is in the page area which is essentially
> under the control of the web site.
Hey hey hey. You can't expect me to put my ideas on the webpage demo
that only an extension/Firefox would be able to do. ;) If I could,
that would defeat the purpose of the idea for something-a-phishing-
site-can't-do.
Here's a quick example of what my suggestion might look like.
Gervase Markham
> Here's a quick example of what my suggestion might look like.
>
> http://ed.agadak.net/firefox/locationbar/lines.png
If that were present for any significant area of time, it would be the
wrong side of the line between useful and irritating. And if it were
present for a short time, a) people might miss it, and b) the phisher
could follow it up with a fake one, which looked fairly like the real
one. If the actual key security bits of the UI are the lines overlaying
the chrome and the small grey highlight in the URL bar (i.e. the
non-fakeable bits), then having the other parts be the big noticeable
bits is counter-productive.
Gerv
Mardak
> If the actual key security bits of the UI are the lines overlaying
> the chrome and the small grey highlight in the URL bar (i.e. the
> non-fakeable bits), then having the other parts be the big noticeable
> bits is counter-productive.
The key security bits actually quite different.
It's training the user to look at the domain of the location bar in
the first place.
Some users are currently only focusing on the content area of the
page. If you can get them to look at the important information, that's
a good step. The lines are to guide the user's attention to the
location bar.
Instead of doing lines, moving the banner around does an even better
job at drawing attention. I was trying to decide how to move/resize
the banner. 1) Start it in the page and move it into the location bar
or 2) Start at the location bar and move out.
The difference.. Is the user going to remember where the banner went
or where it came from? And the answer is likely to be the former as
the latter draws attention *away* from the location bar.
A slight twist/addition is that a lock icon in the banner can moves
separately towards the lock icon in the location bar. Same thing for
EV info. For example, phishing sites can put their own lock icon in a
fake banner, but copying the "move towards the location bar" and
uhh... there's no lock icon in the location bar. Something fishy is
going on!
The important aspect of all this is to cue the user to realize
"something might be wrong," and with the implicit training of the UI
design, they'll know where to look.
Ed
Greg Campbell
> but copying the "move towards the location bar" and uhh... there's no
> lock icon in the location bar. Something fishy is going on!
>
> The important aspect of all this is to cue the user to realize
> "something might be wrong," and with the implicit training of the UI
> design, they'll know where to look.
I really hate to sound like I'm belittling users, but I think you're
overestimating (by some margin) the astuteness of the users this sort of
UI is trying to target.
You essentially have 2 groups: (1) those who will look at the UI and
figure out if it's phishy, and (2) those who won't (usually because they
not only don't understand, but consider the time it would take to learn
to understand too daunting).
I really don't think any amount of whiz-bang animation, flashing, etc.
is going to pull many (if any) folks out of group 2. And furthermore, it
will probably annoy many users in group 1.
Let's focus on trying to make the location bar more useful and helpful
for the folks in group 1.
And if you happen to have friends or relatives in group 2, do them a
favor and try to teach them to be a member of group 1. That sort of
personal attention and guidance is much more likely to help than
anything the browser UI can do.
Greg
Tony Mechelynck
[...]
> A slight twist/addition is that a lock icon in the banner can moves
> separately towards the lock icon in the location bar. Same thing for
> EV info. For example, phishing sites can put their own lock icon in a
> fake banner, but copying the "move towards the location bar" and
> uhh... there's no lock icon in the location bar. Something fishy is
> going on!
>
> The important aspect of all this is to cue the user to realize
> "something might be wrong," and with the implicit training of the UI
> design, they'll know where to look.
>
> Ed
>
Maybe display a large dead fish in icky greenish, yellowish and whitish colors
somewhere on the toolbars? Maybe on a red (danger) background? Meaning
"Uhrrghr... something fishy going on..."
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
104. When people ask about the Presidential Election you ask "Which country?"
Gervase Markham
> It's training the user to look at the domain of the location bar in
> the first place.
Right. But what's actually going to happen is that they will read the
big thing in their face, not the little thing not in their face.
If you want them to look at the location bar, why not just put a big
upward-pointing arrow in the content area? That way, if a phisher fakes
the arrow, it does him harm, not good.
I still think that's a bad idea, but it's more consistent with your
principles :-)
Gerv
Nelson Bolyard
> On Mar 12, 2:26 am, "Mardak" <edi...@gmail.com> wrote:
>> Here's a quick example of what my suggestion might look like.
>
On my machine, when the text gets done shrinking down to fit in the
address bar, it isn't registered properly with the text already there.
It's off by a few pixels. Consequently, the two copies of the text
superimposed together are illegible. But I imagine this problem is
solvable.
I think this whole idea has merit PROVIDED (if and only if) the
chrome at the top of the window (including the address bar) is made
non-optional. Otherwise a phisher can simply spoof it, and probably
make it look better, too. :)
The motion really draws the eye to itself, and over time should train
users to look at the location bar, I think. I like that.
Tony Mechelynck
> Mardak wrote:
>> On Mar 12, 2:26 am, "Mardak" <edi...@gmail.com> wrote:
>>> Here's a quick example of what my suggestion might look like.
>> http://ed.agadak.net/firefox/locationbar/resizenmove.html
>
> On my machine, when the text gets done shrinking down to fit in the
> address bar, it isn't registered properly with the text already there.
> It's off by a few pixels. Consequently, the two copies of the text
> superimposed together are illegible. But I imagine this problem is
> solvable.
>
> I think this whole idea has merit PROVIDED (if and only if) the
> chrome at the top of the window (including the address bar) is made
> non-optional. Otherwise a phisher can simply spoof it, and probably
> make it look better, too. :)
I don't see why. Let's say some user decides not to display the Navigation
Toolbar (which includes the address bar), or even relegates the address bar to
the reserve of non-displayed customizable elements. Then any web page trying
to spoof part of that non-displayed chrome immediately betrays itself as phony.
Remember: code in a webpage's HTML or CSS can touch only the content area, not
the chrome area, with the possible exception of popups, and (a) that exception
can be disabled; (b) drawing a popup usually takes a noticeable fraction of a
second.
>
> The motion really draws the eye to itself, and over time should train
> users to look at the location bar, I think. I like that.
Best regards,
Tony.
--
User n.:
A programmer who will believe anything you tell him.
Mardak
wrote:
> Mardak wrote:
> >http://ed.agadak.net/firefox/locationbar/resizenmove.html
>
> It's off by a few pixels.
Would you happen to be using trunk builds? I actually didn't do much
testing on trunk, but your comment got me looking around to see why it
would be off by a few pixels. Things line up perfectly for me on XP,
OS X Firefox 2.0.0.2, but they are shifted on a nightly build.
I do have to say that the performance is *much* better on the trunk
than 2.0.0.2, especially with actual content behind the banner such as
on..
http://ed.agadak.net/firefox/locationbar/domain.5.html
On trunk, the banner moves smoothly no matter what's below, but it
does leave some crud from time to time.
I suppose that's good news seeing that this would probably be targeted
for Firefox 3.
Ed
FoxWolfie Galen
> On Mar 18, 8:45 pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.com>
> wrote:
> > Mardak wrote:
> > >http://ed.agadak.net/firefox/locationbar/resizenmove.html
> >
> > It's off by a few pixels.
>
> Would you happen to be using trunk builds? I actually didn't do much
> testing on trunk, but your comment got me looking around to see why it
> would be off by a few pixels. Things line up perfectly for me on XP,
> OS X Firefox 2.0.0.2, but they are shifted on a nightly build.
I just tried it with my release version of Firefox:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.2) Gecko/2007021917
Firefox/2.0.0.2
When the text is done shrinking, it ends up about half a line above the
text in the address bar. It appears to be seven pixels too high when it is
done.
I can see potential for more problems if this were to shrink to my actual
address bar, instead of the one provided in the content area. The text in
my real address bar is not using the same font as that used in the content
example, nor is it the same size. I have my userChrome modified to make
sure my address bar text is large enough to read, as I have low vision.
Mine is about 15 percent larger than normal. Will this be smart enough to
shrink to the same font, size and position that any particular user might
be using?
> http://ed.agadak.net/firefox/locationbar/domain.5.html
This one also lands several pixels above the address bar text for me.
I just went over to an XP machine, and it is a little different there. With
Win 98se, it is off by about seven pixels in the end. On XP Home, it is
only off by about two pixels. Both systems end up with the shrinking text
higher on the screen than the target text. Both systems are using the same
version of Firefox, with the profile from one copied from one system to the
other, so they should ideally perform the same. They are also both running
at 1024x768, if that helps. The only difference is that the offset of the
shrunken text and the target text ends up greater on one system versus the
other. The video cards and drivers are different on the two systems.
I hope this is helpful.
--
FoxWolfie
Mardak
wrote:
> Nelson Bolyard wrote:
> > I think this whole idea has merit PROVIDED (if and only if) the
> > chrome at the top of the window (including the address bar) is made
> > non-optional.
>
> Toolbar (which includes the address bar), or even relegates the address bar to
> the reserve of non-displayed customizable elements. Then any web page trying
> to spoof part of that non-displayed chrome immediately betrays itself as phony.
The problem is the user isn't trying to hide the navigation toolbar on
purpose. The popup can choose if the toolbars are displayed. The way
this phishing example works is a popup is opened with no toolbar in
the chrome and in the content of the page, a fake toolbar is shown.
That's why Nelson is suggesting the location bar is made non-optional.
At least make it non-optional for new windows. Users who choose not to
have a location bar will always "not have a location bar". Users who
choose to have it (by default) will always see it unless s/he
explicitly removes it.
Ed
Mardak
> Will this be smart enough to shrink to the same font, size and position
> that any particular user might be using?
The code already does that, but I've updated it so you can explicitly
set the font family and size.
http://ed.agadak.net/firefox/locationbar/resizenmove.html
I originally tested things on 2.0.0.2 for XP and OS X and tweaked the
equations around until the text lined up perfectly, but from the
reports so far, it seems like it still varies. Getting it to work on
various platforms (and OS theme/styles) and firefox builds will be
tricky, but hopefully there's a better way to do things than what I'm
currently doing with offsetTop/Width/etc.
This prospective extension will target Gran Paradiso/Firefox 3 which
has 1) better performance with the new layout engine, 2) support for
finding TLDs so the banner can correctly highlight TLD+1. But there's
some potential problems such as chrome not being able to be placed
over content, fewer supported OSes and things are still getting
changed around.
Ed
Nelson Bolyard
> On Mar 18, 8:45 pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.com>
> wrote:
>> Mardak wrote:
>>> http://ed.agadak.net/firefox/locationbar/resizenmove.html
>> It's off by a few pixels.
>
> Would you happen to be using trunk builds?
Yes.
(I replied to this a few days ago, but my reply has yet to show up.)
It's as if the font used for the zoomed characters has characters
that are 1 pixel wider than the font used for the non-zoomed pixels,
so the result has a point where the characters match pretty well, but
to the left and right of that point, the registration of the characters
gets worse and worse.
I'll try to email you a small screen clip of the problem.
Mardak
wrote:
> I'll try to email you a small screen clip of the problem.
Did that email get lost as well? ;) It might just be something
specific to that html demo that I put on my site.
I actually have an implemented "extension" that is working on both OS
X and XP. The trouble is I'm not sure how to distribute it for people
to use because it requires a few patches that are not checked in in
addition to my own modifications.
Right now I have a 20061122 trunk build that has bug 130078 [1]
applied which allows chrome over content. With that build, I modified
browser.xul with the patch from bug 313190 [2] for easier stacking
elements over the browser. Some reason the OS X version didn't have an
effective TLD list, so I grabbed one from bug 342314 [3].
My own changes involved adding a new style and script reference to
browser.xul as well as a few elements for the domain display. The
script listens for new tabs and url changes and finds the TLD + 1 of
the URL and displays a banner that moves towards the location bar to
overlap the text then fades away.
Here's some pictures of it in action..
http://ed.agadak.net/firefox/locationbar/project_proposal/
Ed
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=130078
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=313190
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=342314
Nelson Bolyard
> On Mar 24, 3:27 pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.com>
> wrote:
>> I'll try to email you a small screen clip of the problem.
>
> Did that email get lost as well? ;) It might just be something
> specific to that html demo that I put on my site.
I sent it to you again. Did you get it?