Boot2Gecko testing

Took a quick poke at the desktop builds of Mozilla’s Boot2Gecko (to become Firefox OS)…


Ehh, it’s running straight out of git, so trust nothing yet. ;)

I’ll have to poke at it more when the b2g guys are online and get it worked out so we can do things like play with a version of our Wikipedia app. :)

Firefox font rendering differences between Ubuntu, Mozilla packages?

Has anybody else encountered this? Subpixel antialiasing on text seems to be a lot more aggressive when running Mozilla’s packages of Firefox and Thunderbird than when running the Ubuntu packages:

I originally noticed it when running Mozilla’s Thunderbird 3 packages on Ubuntu 9.10, but originally chalked it up to “weird stuff from 32-bit apps sometimes acting weird”, but both the 32-bit and 64-bit Firefox 4.0b1 packages are doing it to me on Ubuntu 10.04.

Is there some difference with the bundled libraries, or some custom Ubuntu or Debian patch that changes the behavior? And can I change it??? I’m liking Firefox 4 so far but this text is just awful on my eyes.

Updated 2010-07-13: Commenter noted this bug, which looks like it may be it:

We are all dual-booters

Today’s personal computers basically run two distinct operating systems: the native host OS (Windows/Mac/Linux or iPhone/Android/etc) and the web.

Web apps have solved all kinds of problems that are still poorly handled by most native systems: apps automatically update every time you use them, they manage their own library dependencies, there’s a security sandbox that lets you run pretty much anything without concern that it’s going to eat your system (unless your browser is buggy!)

Let’s face it: most of us probably spend a lot of our time in the web, and even if they’re not doing everything that’s where a lot of action is. Some folks have used this as a sort of excuse for the extreme control some platforms exercise over software publishers – “don’t like the rules? Make a web app, you can do anything!” 

But web apps are still much more limited in some areas. Access to hardware is rare (cameras, audio recording, scanners, attached storage). Communication between apps is greatly complicated by that sandbox, and shared data on the host machine like contact lists and photo archives may be completely inaccessible without a host-specific shim. (Most impressive thing I’ve seen is a bank web site that did deposit via scanned check image, using a signed Java applet to hook into native scanner support. It only worked on Windows, alas.) Background processing is very limited, and most web apps give up on directly notifying you of new activity and just send you email, hoping you’ve got something else that’ll tell you there’s new mail.

There’s a lot of great activity going on in and around HTML5 these days that’s getting better graphics support, faster code execution, etc. But the things that really bring the web native are going to be about access to shared hardware and data resources.

Some good things have been coming in such as touch and orientation events in Mobile Safari, but there’s a long way to go. My pet peeve: I find it pretty surprising that HTML file upload controls don’t trigger something useful like the camera roll on the iPhone/iPad or the Android browser. I can’t believe nobody has thought of this, so I’ll assume for now that the various browser folks just ain’t gotten to it yet… Anybody feel like starting on patches for Android’s Browser and the mobile branch of Firefox? :)

HttpOnly cookies

Thanks to Werdna’s implementation of support, and Tim’s mass upgrade of our older PHP installations, I’ve today enabled the use of HttpOnly cookies on the Wikimedia wikis for our login session data.

“What’s that,” I hear you say, “and why do I want it?”

The HttpOnly marker on cookies tells a supporting browser that the cookie will only be used directly by the web server (sent only with the HTTP requests for each page), so it will hide the cookie from any JavaScript client code which asks for it.

This provides protection against certain kinds of security vulnerabilities — namely, XSS attacks which steal authenticated session and long-term login token cookies.

HttpOnly doesn’t fix XSS, not by a long shot, but it does reduce what an attacker can do; particularly nice when we’re soon going to start using global login cookies which will allow a unified account to continue a login session across multiple wikis on different domains.

The same origin policy prevents JavaScript on one subdomain from directly accessing another domain. Keeping the cross-domain session cookies away from compromised JavaScript will help prevent a hypothetical attack on one domain from jumping to other subdomains without the vulnerability.

Unfortunately, this marker isn’t standard; it’s an extension which Microsoft added for Internet Explorer in 6.0 SP1, but support has been slowly creeping into other browsers, finally hitting Firefox somewhere in the 2.0 patch cycle while nobody was looking.

Browsers I tested that currently support HttpOnly cookies:

  • IE/Win 6 SP1 or 7
  • Firefox or later
  • Opera 9.50 beta
  • Konqueror (3.4?)

Other browsers will still expose the cookies to JavaScript, as they always have:

  • Safari 3.1
  • Opera 9.27 (current non-Beta release)
  • Old scary browsers like IE for Mac and Netscape 4 ;)

There’s a rumor that some versions of WebTV fail altogether when the cookies are marked this way, but I have no way to confirm or deny that yet.

Update 2008-05-01: Mac IE turns out to eat HttpOnly cookies…. sometimes… when the moon is just right. :) Added a browser blacklist, so we feed Mac IE regular cookies. Other browsers are still given the benefit of the doubt.