Indistinguishable from Jesse

Google sometimes hides search results to ensure that search results are varied:

In order to show you the most relevant results, we have omitted some entries very similar to the 15 already displayed. If you like, you can repeat the search with the omitted results included. [foo site:squarefree.com]

or due to bad laws:

In response to a complaint we received under the Digital Millennium Copyright Act, we have removed 1 result(s) from this page. If you wish, you may read the DMCA complaint for these removed results. [scientology site:xenu.net]

Bugzilla also sometimes hides search results, to protect confidential bugs such as undisclosed security holes. Unlike Google, Bugzilla doesn't tell you that there are hidden results for your search. This caused me to worry that potential employers would think I can't count. It also makes it impossible for Peter(6) and others to tell exactly how many release blockers there are.

When Bugzilla hides search results from you, why doesn't it inform you like Google does?

Hint: while "Because nobody implemented that feature" may be technically correct, that's not the answer I'm looking for.

• 114061 - Red star default desktop icon is offending to many people.
• 222306 - Bird head of real Firebird logo in page header logo looks like a goose on fire.
• 233525 - Background of Download Manager looks like one-finger-salute.
• 246760 - New default theme looks like it was made be a 3 year old.
• 254287 - Icon for 'Switch to an alternate stylesheet' looks like a soy bean speared by a hairclip.

mozilla.org now has a security bug bounty program, which offers $500 to people who discover "critical" security holes. Meanwhile, Microsoft offers a $250,000 bounty for catching virus authors.

The problem of web sites being able to spoof browser UI was on Slashdot recently. This is a hard problem that browser vendors have known about for a long time.

The most popular solution, preventing web sites from disabling the status bar, is insufficient. Keeping the status bar always on would only keep malcious sites from spoofing https sites. In contrast, keeping the address bar always on would keep malicious sites from spoofing all web sites. Keeping the address bar always on would also be more effective at preventing web sites from spoofing native applications.

One argument for using the status bar is that it's smaller than the address bar. But it's only about 8px shorter if we use small-icons mode for pop-ups, and we can probably make it even shorter.

One suggestion was to show the hostname in the status bar. The hope is that users would then look there instead of the address bar to verify what site they're on. I don't think enough users would change their habits for this to work. It would also require cluttering the status bar in ordinary windows, which seems like a high price to pay to save 8px in pop-up windows.

Whatever we choose (address bar or status bar), we can do things to avoid breaking existing web sites. If a web site requests a 400x300 window without an address bar, we can give it a 400x334 window with an address bar. We can add a menubutton to the address toolbar in pop-up windows with menu items "Restore toolbars", "Hide address toolbar", and "Hide address toolbar in all pop-ups from https://gmail.google.com/".

Inspired by the Bible Toolbar extension for Firefox, Billistic made Pornbar. Sadly, he based his extension on the Eurekster toolbar, not the Bible Toolbar.

Update August 15: Pornbar is now listed on the Pornzilla site.

My copy of Garey and Johnson arrived the other day. I wonder if it will make good airplane reading while I'm heading to Mozilla Developer Day next week.

Firefox 1.0 Preview Release (previously Firefox 1.0 Release Candidate 1 (previously Firefox 1.0 Beta (previously Firebird 1.0 Beta (previously Phoenix 1.0 Beta)))) is planned for the second or third week of August. I'm glad the Mozilla Foundation decided to move away from using misleading "Release Candidate" names for builds that aren't release candidates.

Adam Sacarny, author of the Mozilla shell: vulnerability timeline, discusses what Mozilla can do to work around future holes in programs that register themselves as protocol handlers.