futtta's blog

I’ve always enjoyed riding the Firefox-bandwagon and that hasn’t changed, even though Google Chrome seems to be the browser of choice amongst the cool kids nowadays. And if only because I’m a faithful guy, I’ve been running Firefox Mobile ever since I bought a Samsung Galaxy SII as well. Sure it doesn’t do Flash, but I’m not that Flash-inclined anyway.

Now, I haven’t met too many people that use Firefox Mobile and indeed when reading about mobile browsers, Firefox is rarely if ever mentioned. But what if I told you that Firefox Mobile is by far the best browser on mobile when taking performance, features and security into consideration?

I won’t beat around the bush, here’s the pretty objective data.

Some remarks:

• the hardware is pretty comparable; all dual-core CPU’s and plenty of RAM.
• higher is better, except for Sunspider which measures time (in microseconds).
• I’ve got no screenshot or URL of the google v8 test results on my phone, but I’ll be glad to reproduce.
• sunspider and v8 are javascript performance benchmarks.
• html5test is an indication for support of “modern” browser features (html5, css3 and much more).
• the features of the browser GUI arent’t measured byhtml5test, but I’m pretty pleased with Firefox Mobile in that respect as well; great tabbed browsing, plugins (including noscript!), sync-ing of all relevant data between desktops & mobile, …
• I added Opera Mobile and Dolphin HD to the list. Opera’s not too shabby but not a winner either?

And last but not least; as Firefox Mobile isn’t native and since it’s on the same (crazy) rapid release cycle as the desktop-version, I consider it to be a lot more secure when compared to the slow evolving, rarely updated native browsers in Android and iOS.

My advice; if you’re an Android-user and you’ve got a recent handset or tablet, you really should consider switching to Firefox Mobile. It’s the best mobile browser no-one is using! Except for you?

After almost a year of tinkering with my Donottrack-plugin for WordPress, I’ve requested it to be hosted in the WordPress repositories and uploaded version 0.1.0. So if you’re using Donottrack on your blog, or if you activated this “bonus feature” of WP YouTube Lyte, I propose you give WP DoNotTrack a try and let me know what gives here in the comments or via the contact form?

From the readme:

WP DoNotTrack stops plugins and themes from adding 3rd party tracking code to your blog to protect your visitor’s privacy. WP DoNotTrack uses (a slightly modified) version of jQuery AOP to catch and inspect elements that are about to be added to the DOM and renders these harmless if the black- or whitelist says so.

The current version is blacklist-based and stops tracking by media6degrees and quantserve. This can easily be changed in the javascript though. Future versions will include a WordPress admin-page to change these settings.

After having NoScript disable the Facebook Like widget a couple of weeks ago, I felt really bad for Mark Zuckerberg who must have been feeling singled out by my actions. If only to make all widgets equal and as I don’t use them anyway, I’ve now told NoScript (only available in Firefox) to also block the Google+ and Twitter widgets with the following ABE User ruleset (under NoScript Advanced options):

# also stop google+ widget
Site plus.google.com
Accept from plus.google.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)


# and twitter
Site platform.twitter.com
Accept from twitter.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

Although web security is something I like to dabble in, I can’t honestly say it always is on the top of my mind. Up until an hour ago, access to the vast amount of information that Google manages for me (including access to my Google Android account) was protected by nothing but a password. A rather strong password for that matter, but it wasn’t entirely random and it has been the same for quite some time now.

As access to important online services such as Google should ideally not only rely on just a password (session hijacking anyone?), I activated Google 2-step authentication. What this means is that access to Google (Mail, Docs, …) is now also limited to authenticated devices. If I try to access Google from another computer, I’ll have to authenticate the device using an SMS-challenge or a code generated by the Google Authenticator application on my Android-phone.

If you’re still unsure about what 2-step authentication entails, here’s a brief intro-video from Google:

So yeah, you can have my password now. Theoretically. If you really insist. But even if I do decide to give it to you, you still won’t be able to access my account. How’s that for peace of mind? And now off to Facebook security settings, to enable login notifications & approvals.

While tinkering with JavaScript at work for a performance-optimization, we encountered an annoying cookie-related problem. We wanted to check if a certain name/value was present in the cookie and not do “complicated and unneeded backend stuff” if it was not. But that didn’t always work, because in some browsers the cookie had the secure flag set and the JS-check was done while in HTTP.

It took some time, digging and soul-searching, but it turned out to work fine for all but me. The reason: NoScript! My favorite Firefox Addon has, so I learned, “Automatic Secure Cookie Management” as a countermeasure against HTTPS cookie hijacking (by setting cookies “secure” if they’re set in HTTPS and if they contain something resembling a session-id?). And that feature indeed can break stuff.

So if you’re using NoScript and you’re running into weird cookie-related problems: try with “Automatic Secure Cookie Management” turned off, or add the site you’re on as an exception and you might be good to go.

Well, I guess that, for those who read my previous post about SSL/TLS error messages on Mac OS X browsers, it’s abundantly clear that I don’t really know SSL/ TLS and the way browsers handle the certificates. But hey, I blog to learn from my mistakes and Philip and Peter helped me understand a bit about TLS with their useful comments.

The summary for TLS-dummies like me:

• According to the TLS spec the server should not only provide it’s own certificate, but also any intermediate certificate between it’s own & the CA’s root
• Browsers (or the OS’es key stores that some browsers depend upon) don’t ship with any intermediate certificate, but can and in some cases will store (cache) them when they come across them. In Firefox, cached intermediate certificates are listed as being part of the “software security device”, whereas root certificates are in the “builtin object token”.

All in all, this means that whenever you’re implementing TLS (or SSL, if you’re old-fashioned) you have  to configure your webserver to provide all intermediate certificates in a “chainfile” as (for example) per Apache’s SSLCertificateChainFile directive.

So you know about SSL (or rather TLS) and you prefer things secure, so you request and pay for an officially signed certificate and configure your Apache to use it. The next days you’re feeling very Kevin Mitnicky, until some nitwit on Twitter trashes you for the ugly error-message he sees when trying to visit your supposedly “secure” site that is. What’s up with that?

Well, chances are that your disgruntled visitor was using a browser you didn’t test on, like Chrome on Mac for example? Because there is a small issue you have to take into account when “doing https”; both Chrome and Safari (but not Firefox) on Mac use OS X’s keychain, which does not have some of the intermediate certificates needed to establish the trust relationship between your signed certificate and the certificate authority’s root certificate.

As you can’t expect Apple to add intermediate certificates to their keychain by default (which Firefox does a pretty good job though) and you can’t ask all your OS X users to add the intermediate certificate by hand either,  you’ll have to solve this yourself. A good thing Apache can help you in that department with it’s SSLCertificateChainFile directive, which

sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of the server certificate and can range up to the root CA certificate.

If there’s only one intermediate certificate missing between your’s and the CA’s, you can export it in good old Firefox (as a pem-file), place it in the same directory as the actual certificate and use SSLCertificateChainFile to tell Apache where to find it and that should solve the nasty errors those Twittering Mac-heads get.