Monday, August 18, 2014

Firefox OS is a developer's best friend

Up until recently I wasn't able to appreciate the full potential of a Firefox OS phone. I only looked at it as a consumer product, a cheap way for people in developing countries to get access to the internet. I had never considered its potential as a tool for hackers and developers.

So here is my use case: I own 2 prepaid SIMs for which I regularly run over my internet quota. Vodafone has a promotion where it offers you 2Mb for every call you give or receive, that is over one minute long. The problem is, I don't really talk for more than 20 minutes each month. So, as the bright engineer that I am, I've come up with a plan. Since I have unlimited calls between my two prepaid SIMs, why not have them call each other, and farm some megabytes.

Here is where Firefox OS comes in. It's insanely easy for me to script together some code that would call a number, wait for 60 seconds, end the call and call again.

function start() {
    navigator.mozTelephony.dial('07XXXXXXXX'); // Call the phone number
    setTimeout(stop, 63*1000); // Stop the call in 63 seconds

function stop() {
    navigator.mozTelephony.calls[0].hangUp(); // Hang up
    setTimeout(start, 3*1000); // Call back again in another 3 seconds


I just opened the App Manager, and pasted the code into the Usage app console. Then I left it running for about one night, and got around 1.5 Gb of traffic. (The max I can get is 2.5 Gb) Pretty nice, right? One of the problems in this setup, is that I needed to download an app on my Android phone, to answer incoming calls automatically. I went with AutoAnswer, but wasn't really happy with the permission settings the app required. This is another way Firefox OS kicks Android's app. It has a way better permissions system, where each app asks for each permission, and can still function if you don't allow it.

So there it is. With less than 10 lines of code, I was able to make use of the phone's capabilities in a very cool way. That was way easier and much more fun than anything I could do with my Raspberry Pi. Soon, with the launch of a device that costs around 25$, it will be even cheaper than a RPi. And I can only imagine what I could do with the the available camera and wireless capabilities.

Saturday, August 2, 2014

Captive Portal detection in Firefox

I haven't posted something on the blog in a while, so I thought I'd post something about my current work at Mozilla.

I'm currently working on better captive portal detection in Firefox. You might correctly point out that there is no such detection at the moment. The feature does exist, but it's only enabled on Firefox OS. My job going forward will be to port this functionality over to Firefox, and to implement several enhancements.

My first step was to gather all of the bugs and relevant info into a wiki page. The good news is that most of the groundwork is already there. The design for this feature has already been done (incidentally, by another Valentin working at Mozilla), and my job is to implement the capabilities that Necko needs to provide to other components.

In order to test captive portal, I needed to set up one for myself - working at my local McDonald's is not an option :) Fortunately, this feature is part of the Tomato firmware which is also available for my Asus N10U router. Yay!

Next up, making captive portal detection available to desktop Firefox. The feature is implemented in captivedetect.js. The basic idea is that it tries to load a page from a predefined URL, and check the response against an expected value. If the values differ, or if we get a redirect, the odds are that we are inside a captive portal.

On FirefoxOS the captive portal detection is used in the NetworkManager, which is a Gonk service which isn't going to be of much use on desktop. So I just stuck a captive portal request inside nsIOService, to see if it works. After finding and fixing a couple of typos in captivedetect.js (How can you not love JavaScript for this?), it turns out that this works pretty well. I was able to observe notifications whenever the browser got a captive portal page and when the user logged in to that page, and was able to access any page on the web. So really
good news.

Going forward, I need to figure out how the captive portal fits with the rest of Necko, what I need for the UI, how do we handle secure connections, and many other issues. Also, Tomato doesn't seem to hijack secure connections, as other captive portals do, but I'm going to figure this out when I get to it.