Tag: IE

Posted on
by

Q: What happens when you break up/fire your web browser-developing group with years of experience, and later hire an outside firm to build your next product?

A: Netscape 8.

IEBlog has an amazing report—which I’ve just verified. Netscape 8.0.1 disables IE’s XML rendering. So if you try to load an XML document—say, an XSLT-styled RSS feed like the feed for this blog—using Internet Explorer or Netscape 8 with IE’s engine, you’ll see either a blank page or an unloaded-image icon.

Apparently every time Netscape 8 runs, it trashes a registry entry that defines how IE displays XML. At this point the only way to fix it is to uninstall Netscape 8 and delete that entry (directions at the above link).

This raises two questions:

  1. Why does Netscape 8 alter an Internet Explorer registry setting?
  2. Why can Netscape 8 alter an Internet Explorer registry setting?

I’ve said it before (though possibly not here), but Mozilla is much better off now that AOL isn’t calling the shots.

Update June 20: Netscape 8.0.2 fixes this problem.

Posted on
by

Some potentially nasty browser security vulnerabilities found this weekend in Mozilla and in Safari. Both involve software update mechanisms. The Firefox one tricks the browser into thinking it’s installing from a trusted update site (the maintainers of updates.mozilla.org and addons.mozilla.org—the only trusted sites by default—have made some changes on their server to prevent the exploit from working). The Safari one takes advantage of the Macintosh tradition of automatically opening archives. This one just happens to unzip itself into the location where Dashboard stores its widgets.

IEBlog has weighed in with a balanced (i.e. non-fanboyish) comment on just who “us” vs. “them” should mean: responsible developers & security researchers vs. the malicious ones. It won’t happen—people are too hunkered down in their own trenches—and even with Mozilla, Opera and Apple collaborating on specs, I don’t expect to see much in the way of collaboration on security except in the actual open-source world. (Even then, I suspect there’s too much rivalry between Gecko and KHTML developers to do much collaboration.) Continue reading →

Posted on
by

Sometimes you want to know exactly what software people (or bots) are using to view your website. Sometimes all you want to know is which rendering engine’s quirks you need to cater to. To that end, I have here the ultra-simple browser detection algorithm. Just check the User-Agent string for each of the following words, in order:

  1. Opera — they spoof IE by default, so check here first. If they ever change this to something else, you’ll be glad you started here.
  2. KHTML — this will catch Safari, Omniweb and Konqueror. They mention Gecko, so if you need to treat them differently, check for KHTML first.
  3. Gecko — this will catch Mozilla, Firefox, Camino, Netscape 6+, etc.
  4. MSIE — this should Internet Explorer and anything else that uses its engine.
  5. bot, spider, crawler, or compatible — filter out robots and anything unknown.
  6. Mozilla — just about everyone uses Mozilla in their UA string these days, but the rules above should filter most of them out and leave only old-school Netscape.

Of course, Mozilla, Opera and Safari have put much more effort than IE into following the standards, so most of the time you can write your code using the spec and just build in work-arounds. The way I look at it, there are three main categories:

  1. Standards-compliant(ish) browsers: Gecko, Opera, KHTML
  2. MSIE
  3. Everything else

I write for group 1, work-around for group 2 (and sometimes other browsers in group 1), and figure that group 3 (with the exception of Netscape 4, which has a tendency to do things like make links unclickable or hide entire chunks of the page if it doesn’t like your CSS) should at least be able to figure out how the text and graphics break down. It may not look perfect in randombrowser, but it should at least be comprehensible.

Posted on
by

Talk about convoluted. Someone has developed a Java applet that will use one browser to install spyware on another. The applet runs in any browser using the Sun Java Runtime Environment—Firefox, Opera, Mozilla, etc.—and if it can convince you to run the installer, it will install spyware on Internet Explorer. And since you can’t remove Internet Explorer from Windows (you can hide it, but it’s always there…waiting), just using an alternative browser isn’t enough to protect you.

Of course, the obvious solution here is don’t let it install anything. That’s what the Java sandbox is for, after all: applets run in their own little world and can’t touch the rest of your system unless you let them (or they find a hole in the sandbox, which is why you need to keep Java up to date—just like everything else).

Time to emphasize the fact that while Firefox is still safer than IE, it’s not a magic bullet. There is no magic bullet. You can minimize risk, but never eliminate it.

(via SANS Internet Storm Center)

Posted on
by

I installed the just-released Netscape 8 Beta. It imported most of my settings from Firefox, including bookmarks, cookies and even history. One of the first things I always check with a new browser is how it identifies itself, which in this case is as Firefox 0.9.6. (Presumably they’ll get on this by the time the final version is out.)

First impressions: importing was clean and worked well. UI is a bit freaky, as things are spread all over the place—like the main menu, which is in the upper right and in line with the title bar instead of where the menus are on every other Windows application. The multiple toolbars seem confusing at first (it took a while to dig up my bookmark bar, for instance). Then I looked at the site trust/rendering choices, the big exciting feature of this release. And I’m not impressed. Or rather I am, but not favorably.

The current tab shows a shield icon indicating the trust level of the site: Green if it’s been verified by a “Netscape Security Partner,” yellow if not, and I would presume red if it’s a known phishing/virus/etc. site. There’s also an icon indicating the trust level: a check mark if it’s trusted, an ellipsis for “not sure” and an exclamation point for not trusted. Unverified sites are, by default, in the “not sure” category. So far this makes sense.

Clicking on the shield icon opens a site controls dialog box enabling you to choose to what extent you trust the website, and below that, whether to display the site using the Mozilla Netscape or Internet Explorer engine: Continue reading →