<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Preventing browser UI spoofing</title>
	<atom:link href="http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/</link>
	<description>Jesse Ruderman on Firefox, security, and more</description>
	<pubDate>Tue, 07 Oct 2008 16:44:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Bram</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-698</link>
		<dc:creator>Bram</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-698</guid>
		<description>The strange thing with showing an address bar is that you suggest navigating in that window while the site opening the pop-up wants to discourage that. Actually surfing in that window would be quite annoying if it's none resizable and doesn't have all toolbars

If your purpose is just to show the current address, and some "Restore toolbars" button you could actually create a new kind of toolbar (pop-up bar?) which has more or less the same height as the statusbar and just some address label instead of a full-blown address bar.</description>
		<content:encoded><![CDATA[<p>The strange thing with showing an address bar is that you suggest navigating in that window while the site opening the pop-up wants to discourage that. Actually surfing in that window would be quite annoying if it&#8217;s none resizable and doesn&#8217;t have all toolbars</p>
<p>If your purpose is just to show the current address, and some &#8220;Restore toolbars&#8221; button you could actually create a new kind of toolbar (pop-up bar?) which has more or less the same height as the statusbar and just some address label instead of a full-blown address bar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mathieu Pellerin</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-699</link>
		<dc:creator>Mathieu Pellerin</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-699</guid>
		<description>I dont think making the statusbar permanent is the best solution (I think it can be very useful to remove the statusbar for the good looking of it)

imo, the solution should be placed in the _titlebar_ simply because the titlebar is something that the web doesnt play with (except of course giving it a different name)

so

a) there's a titlebar icon change to indicate that this window is missing the statusbar (or any other part: menu, toolbar)

b) (my favorite :) and original) you add a button next to the system buttons to unhide/hide the statusbar and/or any other missing parts removed by the javascript call ...

I would vote for the solution B for two reasons
 - it's visualy more obvious to see an added system button rather than a slightly changed titlebar icon
 - it adds the possibility to the user to get their toolbar,menubar,statusbar back (something I often wanted when I was using a window without menubar)

dont make the statusbar permanent, that's not the right solution (especialy if somebody simply dont like statusbar and disable it all the time :) )</description>
		<content:encoded><![CDATA[<p>I dont think making the statusbar permanent is the best solution (I think it can be very useful to remove the statusbar for the good looking of it)</p>
<p>imo, the solution should be placed in the _titlebar_ simply because the titlebar is something that the web doesnt play with (except of course giving it a different name)</p>
<p>so</p>
<p>a) there&#8217;s a titlebar icon change to indicate that this window is missing the statusbar (or any other part: menu, toolbar)</p>
<p>b) (my favorite :) and original) you add a button next to the system buttons to unhide/hide the statusbar and/or any other missing parts removed by the javascript call &#8230;</p>
<p>I would vote for the solution B for two reasons<br />
 - it&#8217;s visualy more obvious to see an added system button rather than a slightly changed titlebar icon<br />
 - it adds the possibility to the user to get their toolbar,menubar,statusbar back (something I often wanted when I was using a window without menubar)</p>
<p>dont make the statusbar permanent, that&#8217;s not the right solution (especialy if somebody simply dont like statusbar and disable it all the time :) )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mark</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-700</link>
		<dc:creator>mark</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-700</guid>
		<description>The status bar is the least useful real estate on the screen. I don't know if any one had done usability tests on the status bar, but my experience is that it is very unnatural for users to look at that area of the screen. I'm sure that even if there were two status bar displayed I would not have noticed it.

IMHO the basic problem is that a site should not be given any ability to change the GUI of the browser. Why is it assumed that when I surf a site, I give it an automatic permission to manipulate my GUI?. This the same as giving sites a permision to set my home site, and the solution should be the same, ask the user if he permits it per a specific site, then store this as prefference for the future.</description>
		<content:encoded><![CDATA[<p>The status bar is the least useful real estate on the screen. I don&#8217;t know if any one had done usability tests on the status bar, but my experience is that it is very unnatural for users to look at that area of the screen. I&#8217;m sure that even if there were two status bar displayed I would not have noticed it.</p>
<p>IMHO the basic problem is that a site should not be given any ability to change the GUI of the browser. Why is it assumed that when I surf a site, I give it an automatic permission to manipulate my GUI?. This the same as giving sites a permision to set my home site, and the solution should be the same, ask the user if he permits it per a specific site, then store this as prefference for the future.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-701</link>
		<dc:creator>Justin</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-701</guid>
		<description>Why not simply put a (bright red, striped, something) border around any XUL-based GUI retrieved from a remote location?  Even if the GUI is opened in a new fullscreen window, the border will be there to let the user know it's not locally generated.  It'd also be fairly inconspicuous in comparison to requiring the status bar/menu bar/toolbar be visible 100% of the time, while still informing the user of what was happening.</description>
		<content:encoded><![CDATA[<p>Why not simply put a (bright red, striped, something) border around any XUL-based GUI retrieved from a remote location?  Even if the GUI is opened in a new fullscreen window, the border will be there to let the user know it&#8217;s not locally generated.  It&#8217;d also be fairly inconspicuous in comparison to requiring the status bar/menu bar/toolbar be visible 100% of the time, while still informing the user of what was happening.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: i5mast</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-702</link>
		<dc:creator>i5mast</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-702</guid>
		<description>how about checking the form submission. is it possible to determine whether it is being submitted from a spoofed window?</description>
		<content:encoded><![CDATA[<p>how about checking the form submission. is it possible to determine whether it is being submitted from a spoofed window?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Ruderman</title>
		<link>http://www.squarefree.com/2004/08/01/preventing-browser-ui-spoofing/#comment-703</link>
		<dc:creator>Jesse Ruderman</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.squarefree.com/test/wp15/wordpress/?p=169#comment-703</guid>
		<description>Bram (#1): Web sites have no business creating non-resizable windows (bug 177838), so that part of your argument doesn't work.  Other than that, your idea is reasonable.

Mathieu (#2): I don't know about you, but I rarely look at the title bar.  That said, I think we should do what you describe in addition to preventing web sites from hiding the address bar.  Then if someone chooses "Hide address toolbar in all pop-ups from https://gmail.google.com/", they'll still have something they can look at.

Justin (#4): You can spoof the browser UI just as effectively with HTML+JS as you can with XUL.  That's why I didn't mention XUL in my post.</description>
		<content:encoded><![CDATA[<p>Bram (#1): Web sites have no business creating non-resizable windows (bug 177838), so that part of your argument doesn&#8217;t work.  Other than that, your idea is reasonable.</p>
<p>Mathieu (#2): I don&#8217;t know about you, but I rarely look at the title bar.  That said, I think we should do what you describe in addition to preventing web sites from hiding the address bar.  Then if someone chooses &#8220;Hide address toolbar in all pop-ups from <a href="https://gmail.google.com/" rel="nofollow">https://gmail.google.com/</a>&#8220;, they&#8217;ll still have something they can look at.</p>
<p>Justin (#4): You can spoof the browser UI just as effectively with HTML+JS as you can with XUL.  That&#8217;s why I didn&#8217;t mention XUL in my post.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
