Category: Web Browsers

Posted on
by

Now that it’s live, I’ve downloaded the Google Chrome beta on my Windows box at work.  Thoughts so far:

Good:

  • Site compatibility seems to be fine so far, with a couple of minor issues (see the “Bad” section).  Mostly I’ve tested it with a couple of forum sites, LiveJournal, Slashdot, and WordPress.
  • I like the simple settings box, with “Basics,” “Minor Tweaks,” and “Under the Hood.”
  • It does feel fast.
  • Showing the URL of links in the lower left-hand corner is a perfect compromise between the spatial advantages of a permanent status bar and the extra room provided by leaving it out.
  • I like the task manager for the browser itself.  It’ll be good for developers, but it’ll also be good for users: as the comic points out, if your browser starts chewing up all available resources, you’ll be able to tell what page/plugin/program is at fault instead of just blaming the browser.

Bad:

  • Gears support doesn’t seem to work quite right.  WordPress.com doesn’t detect that it’s available.  Local WP installs with Bad Behavior can’t sync completely.  (It doesn’t send an Accept header on the request for one of the TinyMCE files, which causes Bad Bahavior to think it’s a spambot and triggers a 403.)
  • Cookie management is too simplistic.  I like to accept all cookies temporarily, but clear everything when I end my browsing session, with exceptions for sites where I want to stay logged in.  This is easy in Firefox, a little trickier in Opera, and doesn’t seem to be an option in Chrome.
  • I have seen it pause a couple of times, with as few as 5 tabs. [edit: these seem to be related to Flash content]
  • No Incomplete spell-check.
  • I keep hitting the forward-slash key to search within a page, since that’s the shortcut I’m used to in Firefox and Opera.
Debatable:
  • The UI does indeed stay out of your way.  I guess this sort of makes Chrome the Anti-Flock.
  • DNS Pre-Fetching is enabled by default.  This is different from full HTTP pre-fetching in that all it does it look up the IP addresses of the links that you might click on.  It’s not clear at what point it does this — I don’t remember seeing it mentioned in the comic, which (ironically) isn’t searchable.  I suppose it could either hit the domains of all the links on a page, or just those that would trigger HTTP pre-fetching, or even just send the query when you hover over a link (to get a split-second head start before you click). Update Sep. 17: Google has a blog post explaining pre-resolving in detail. Apparently it does check the domains for all the links on the current page.

Posted on
by

Google Chrome seems to be a multi-threaded open-source browser based on WebKit (with some code from Firefox as well), focusing on making a browser that will work well with web applications.

It’s got built-in support for the Gears API (not surprising). And, like Firefox 3, IE8, and Opera 9.5, it’ll do full-history search & auto-suggest in the location bar. Interestingly, they’ve adopted a couple of UI elements from Opera, including thumbnails of your most-visited pages when opening a new tab (like Opera’s Speed Dial, though in this case the list is automatically generated from your browsing behavior), and putting the tabs above the main toolbar — something that Opera has taken a lot of flack for.

According to the blog post, the first preview release should be out for Windows tomorrow, with Linux and Mac following.

Oddly enough, I found out about it through comics blogs (A Distant Soil, specifically), not tech blogs, because Google hired Scott McCloud (Understanding Comics) to explain what makes the browser different in comic-book form.

Posted on
by

The IEBlog recently posted about their efforts to improve reliability in Internet Explorer 8, particularly the idea of “loosely-coupled IE” (or LCIE). The short explanation is that each tab runs in its own process, so if a web page causes the browser to crash, only that tab crashes — not the whole thing. (It is a bit more complicated, but that’s the principle.) Combine that with session recovery (load with the same set of web pages, if possible with the form data you hadn’t quite finished typing in), and you massively reduce the pain of browser crashes.

I’d like to see something like this picked up by Firefox and Opera as well. They both have crash recovery already, but it still means restoring the entire session. If you have 20 tabs open, it’s great that you don’t have to hunt them down again. But it also means you have to wait for 20 pages to load simultaneously. It would be much nicer to only have to wait for one (or, if I read the IE8 article correctly, three).

Edited to add:

On a related note, I’ve run into an interesting conflict between crash recovery and WordPress’ auto-save feature. If you start a new post, WordPress will automatically save it as a draft. If the browser crashes, it will bring up the new-post page, but restore most of the form data you filled in. So the title, the text of your post, etc will all be there. But WordPress will see it as a new post, and you’ll end up with a duplicate.

This wasn’t a major problem when I encountered it — I had to reset the categories, tags, and post slug after I hit publish (since I hadn’t noticed that they’d been reset to defaults), and I just deleted the older, partial version of the post — but I can imagine if I’d uploaded an image gallery, I would have been rather annoyed, since there’s no way (that I’ve noticed) to move images from one post to another. Reuse them, sure, but not such that the gallery feature would work.

Posted on
by

Last month, eWeek reported that PayPal intends to block unsafe browsersfrom accessing their site. They’ve focused on phishing detection and support for Extended Validation SSL Certificates. So what are these features, and why does PayPal think they’re critical? And just which browsers are they likely to block?

Phishing protection has an obvious appeal for a site whose accounts are one of the biggest phishing targets on the web.  Opera 9.1 and up, Firefox 2, and Internet Explorer 7 check the websites they visit against lists of known fraudulent sites. These browsers will warn the users before they accidentally type their credentials into a bogus log-in form. While this makes no difference when a user is already on PayPal’s site, it does mean the user is less likely to get his or her password stolen, and thieves are less likely to carry out fraudulent transactions with the account.

Extended Validation or EV certificates are like normal SSL certificates: they encrypt your web activity to prevent eavesdropping. What makes them different is that EV certificates require the issuer to verify the site owner more thoroughly. Browsers with EV support will display an indication that the site has been verified, usually by turning part or all of the address bar green. This is intended to give the user greater confidence that the site is legit. EV certificates are currently supported by IE7 and development versions of Opera 9.50 and Firefox 3. (You can preview a version of Opera with EV support by downloading Opera 9.50 beta 2.)

(It’s worth noting that Opera 9.50 beta 2 is stricter about verifying EV certificates, and will not show PayPal with a green bar because it loads images and scripts from another site. More recent preview releases will, like IE7 and Firefox 3, be satisfied if the main page is EV and the resources are all protected by regular SSL.)

So which browsers might get turned away at the gate?

In a follow-up story, PayPal clarified that they have absolutely no intention of blocking current versions of any browsers, and that they would only block obsolete browsers on outdated or unsupported operating systems. So an Opera 9 user on Windows XP isn’t likely to get shut out of PayPal anytime soon. But a Windows 98 user might have cause for concern.

Browser detection is extremely tricky to get right, requiring frequent adjustments. It looks like PayPal intends to take the minimalist approach: Assume most browsers are capable of handling what you send them, and only block the problematic ones.

(Originally posted at Opera Watch as a follow-up to Blocking IE6)