I've decided to some content on my Spread Firefox Blog. Basically, I'm just going to put links to posts here about Mozilla in the blog. I'm not much of a marketing guy, so I doubt I'll have much to say directly about how to succesfully Spread Firefox. If I do, though, I'll probably post the full content there, and a link here.
As a web developer, and as a web surfer, I want the web to do more. But I want don't want that to come at the cost of locking people into an browser or operating system choice. That's why supporting a browser like Firefox is so important. Firefox is cross-platform, so you're not locked into an OS. Firefox has support for new web standards and technologies. It's doing things like increasing the visibility of syndication feeds, supporting CSS standards, and working on new extensions to HTML. Firefox helps make the web better.
To succeed, it needs market share. This creates an incentive to make web-sites standards-compliant and cross-browser compatible. So, if you agree that this is an important cause, how can you help? Join SpreadFirefox.com to find out about new initiatives to spread the usage of Firefox.
The Yahoo! Companion Toolbar for Firefox has been updated to work with Firefox 1.0 Preview Release. Plus, several bugs have been fixed, so it should be much more usable. Go download it! (That means you, Chris!).
Note, only the installation page is updated. The front page hasn't changed to show the new version. I edited the link to go straight to the installation page.
I've hacked together a theme. Basically, I just put Noia 2.0 eXtreme's tabs and scrollbars onto the default theme. I've gone through a few iterations, and am pretty happy with the decision not to style the tab bar, but just the tabs.
What I don't have is any artistic talent myself. For now, the icon for this theme is simply a cropped piece of a selected tab. The preview is a screen shot of the theme. Both of these could use some work to fit with what most themes do. Anybody want to help?
I've decided to go with the Atom format for syndication of data in the web application I develop at work. Inside the content tags, I'm placing inline XHTML (not escaped). I then wanted to use an XSLT to show the feed more nicely in the browser. Simply using <xsl:copy-of select="atom:content"> worked for Internet Explorer, but not for Mozilla Firefox. It turns out it wasn't treating the content as XHTML, so I wrapped the content inside a div: <div xmlns="http://www.w3.org/1999/xhtml">
I was having a major problem with this, and was going to post here and ask for help. But in my attempts to document what I'd been searching for already, I found what I hope will prove to be the answer. I'll find out tomorrow if it helps. Feel free to take a shortcut to the technical details.
Background information found during my hunting that you may also find interesting:
Via an e-mail from the author (assumably), I found out today about a quite good college basketball blog. If you're a college basketball fan, I suggest you check it out.
First, read Jesse Ruderman's take on the issue from last month. Then, check out my definition of the problem and the criteria for a solution.
Ok. This does solve the problems. Now, only internal dialogs can show without an address bar. Since Mozilla added security information to the address bar, we can now always see that data. And for unsecure sites, we have the full url, though that may be somewhat hidden by adding lots of text before the domain name in the url. The downsides: we usually have our navigation buttons here, which add unnecessary clutter to the UI for web-based dialogs. Plus, Firefox lets you customize your toolbars. Personally, my navigation bar is empty, I have everyting on the menu bar. So I'm no longer really protected in terms of site spoofing. Also, this still allows sites to spoof the status bar, which is the traditional location of the security information (and still one of the sources of security information in Firefox), so user's who check that instead of the address bar will be fooled into thinking they're safe.
Again, this solves the problems for the most part. Internal dialogs would be the only one's without a status bar. On secure sites, the certificate information is available, and the domain name is shown. If we simply added showing the domain name on the status bar for unsecure sites as well, then this would actually provide more anti-phishing protection than the address bar, as it would prevent the domain from being hidden by a long url. Also, the status bar is slightly smaller than the address bar, and data there can't have been moved to another toolbar. The downside: Mostly, now the address bar can be spoofed, and user's who look there for data, especially on un-secure sites, may be tricked if they ignore the status bar data.
The idea here is to replace the status bar with something that actually wraps around the untrusted chrome. This has all the benefits of the status bar approach, but it prevents address-bar spoofing to an extent, by forcing that spoofed address bar to appear inside the yellow outline. My concerns are: these mock-ups don't take into account other current status-bar data. Does that still stay on this UI? Or are we not going to entirely replace the current status bar? How would this really look for a normal, maximized full window? Also, how can we insure that the utility of the outline and such don't disappear when using different browser themes? This is already a small problem with the current UI, but I can see that outline becoming even more of a problem.
The reason there is no simple solution to this problem is because we (Mozilla) have chosen to display security information two places: the address bar and the status bar. So, unless we change that, I think Benjamin Smedberg's idea (#3) is the best way to go. I wasn't convinced when it was first brought up, and obviously I still have some concerns, but going through this process has convinced me.
So, we know what the problem is, I think. But that doesn't quite get us to what criteria we'll use to judge possible solutions.
Obviously, the first criteria is that it needs to make it possible to identify spoofing in the situations listed in the problem description. But, does it just need to possible by a computer literate user who's paying attention? Or does it need to be so obvious that anybody will notice? Does the solution need to have limited impact on the UI of current non-spoofed pages? When it comes to spoofing to get around the browser's existing anti-page-spoofing, are we only limiting our concern to "secure sites" (https://)?
Here's what I'm going to use:
Regarding #3: This really goes above and beyond the current problem, as it's an attempt to add web-site spoofing protection to non-secure sites. But the use of certificates to authenticate a site's identity is a joke on the modern internet. Many sites I do trust don't have the money for a proper certificate for every domain name that points to that content. A real site that had the web server hacked is just as untrustworthy as someone putting up a fake version. So, I'd rather we simply assume that the domain name is valid, and prevent spoofing from there. Certainly, secure sites should continue to receive the extra UI they do now, but all sites should be included in anti-phishing schemes.
The release of Firefox 1.0 Preview Release yesterday managed to make several Mozilla sites more popular, according to Bloglines. Check it out, the top 4, and 6 of the top 10. And 9 of the top 15 gaining links too.
Let's hope we can manage even better for the Firefox 1.0 Release.
Mozilla Firefox 1.0 Preview Release is out! Go get it, test it out, and report your problems so that Firefox 1.0 can be the best browser release ever!.
Also, for those who are already fans of Firefox, spread the good word. Check out Spread Firefox! for ways to help the Firefox community.
"Players ought to be there on time, period," Coughlin said. "If you are on time, you are on time. Meetings start five minutes early."
Footbal coaches live in an alternate universe, where they apparently make a lot more sense than they do in this universe.
I've decided to take this issue slowly; most people's "solutions" are already assuming a certain definition of the problem, which is rarely stated.
The problem has little to do with Mozilla's ability to display remote XUL. This just makes a convincing spoof easier, although it limits the spoof to Mozilla-based browsers, and usually to a subset of versions. Similar things can be done in IE with a lot of work on some very clever styling and javascript.
The problem is this: pieces of the "chrome" (browser interface, as opposed to web-content display) can be hidden, and then fake data put in its place that trick the user into thinking that data is part of the browser.
But what things can a user be tricked into doing by mistaking content for browser? There's no danger (security-wise) in hitting a fake back-button, right? So, here's the problems I can think of:
I'm sure there are some potential attacks I'm missing. If you know of them, add them. If I come across them, I'll update this post to include them. As I see it, the attack fall into two categories: browser-input spoofing, and browser anti-phishing circumvention. Does that cover it? Are there other types I'm missing?
A summary, as well as some proposals for Firefox UI to handle Spoofing of the Browser's User Interface.
Check out my comments there first
There's been some level of "theoretical" work on this issue, which comes down to the claims mentioned in the entry mentioned above: that it's not enough to do some kind of warning about untrusted data, you need to indicate where the line between trusted (part of the browser UI) and untrusted (web content) lies. And you need to use a box, mostly because of the status bar.
I'm not happy with solutions that involve adding UI to the browser. It's a waste of screen space for a supposed problem that is not really a problem in the wild yet. Looking forward to potential problems is great, but only if a half-way elegant solution is found.
This post has been in draft mode for a bit, so here's some commentary from someone else on the problem of these "solutions".
I intended for this to be a more complete analysis of the problem, but I want to get these thoughts out first, and then I'll come back and tackle the issue as I see it. I'm still working it out in my head, so I'm likely to end up contradicting myself a bit. Be patient.
Normal "Web Applications" consist of HTML and Javascript on the client side, and one of many types of server-side languages (I use Java/JSP). There are two problems with this. The first is the degree of interactivity on the client: there's only so much you can do with Javascript to make an HTML page feel interactive, and it's messy for even one browser, and even messier when trying to support multiple browsers. The second is the difficulty of server-client communication. An HTML based application can only consist of a series of requests and responses between the server and the client. Server-side languages try to cut down on the pain of tracking information across requests for a single client (through session variables), but that doesn't solve the pain of needing to redo the entire response for a small change caused by a request.
These problems do not occur for a rich client. A rich client can be very interactive, and can talk a direct protocol back to the server for data, and can have the rest of the logic embedded in the client. The drawbacks to the rich client are: the current ease of development of GUIs, and the ease of deployment (installing an application is a very high barrier to entry compared to a web application, and it doesn't go where the user goes).
The solution is generally proposed as a combination of the two: a "Rich Internet Application" or some other term. The prerequisites for this are: a ubiquitous client-side runtime to run the client code in (a Web Browser fills this role in a traditional Web Application), and a simple development model, especially for the GUI (HTML fills this role for the traditional Web Application).
Java Applets were one early, popular contender. Java is cross-platform, and functions as a plug-in to the web browser, which could have led to ubiquity. It used (at the time) the best development langauge available (others have caught up with, but not surpassed, Java since then, in my opinion). There are still some little games and such on the web, and some smaller interactive apps I've seen in my work environment (even one I worked on developing a little during an internship) that go this route. There are two major problems: ease of GUI design, and compatibility. Swing isn't bad for GUI design, but it's not as easy as HTML. As for compatibility, the combination of Microsoft's incompatible JVM being installed by default (which severely limited the deployment of the JRE),the poor implementation of auto-updating the installed JRE (partially due to its size), and level of incompatibility between versions has created JRE version hell, severely limiting the popularity of Applets for this kind of development. These may be able to make a new push, if techniques for XML based GUI design targeted at Swing become available.
The next major contender is Flash. It's available for multiple platforms and multiple browsers, and has a very large install base. However, since it was initially pushed almost entirely at client-side only GUI development, it caught on with users and graphic designers, but not developers. It still suffers from this stigma as a presentation only tool. It's also (from what I hear, I've never done Flash work) a bit difficult to design with as well. But Macromedia is working on pushing an XML based client-server way to do this Rich Internet Application concept, called Flex. Don't know much about it, but I should probably start trying it out.
There's also a pretty neat system that I found today, shown to me by a co-worker, that sparked this post. It works similary to Flex, I guess. It runs on a Java Application Server (for instance, Tomcat), and uses XML and Javascript for the GUI design. It's an interesting thing to take a look at.
There are also two contenders that I see, that will not be completely cross-browser, but are still up-and-coming. The first is XUL, the technology Mozilla products are based on. While Mozilla products are full client apps, XUL can be Internet deployed. This is again, an XML-based, Javascript (and CSS, which I haven't seen in other products) based GUI design system. Mozilla is cross-platform, but requires the underlying Mozilla Platform.
Alternately, there's the upcoming system by Microsoft, orginally targeted for their next-generation OS, but now to appear on XP eventually, called XAML (with Avalon relating in there somehow). This, of course, will likely only work in IE, and only on Microsoft based operating systems. But, it will have the advantage of being pre-installed on more people's desktops than any other technology over time, from a company that has better developer relationships than Macromedia.
With all these contenders, the future is really still up in the air. It'll be interesting to see how this all plays out. Anybody got their own ideas on the pros and cons of all this? Suggestions on other contenders I missed?