profile picture

Ryan's Ramblings

In blog form:

Security Bugs in Practice: SSRF via Request Splitting

September 10, 2018

One of the most interesting (and sometimes scary!) parts of my job at Mozilla is dealing with security bugs. We don't always ship perfect code – nobody does – but I'm privileged to work with a great team of engineers and security folks who know how to deal effectively with security issues when they arise. I'm also privileged to be able to work in the open, and I want to start taking more advantage of that to share some of my experiences.

One of the best ways to learn how to write more secure code is to get experience watching code fail in practice. With that in mind, I'm planning to write about some of the security-bug stories that I've been involved in during my time at Mozilla. Let's start with a recent one: Bug 1447452, in which some mishandling of unicode characters by the Firefox Accounts API server could have allowed an attacker to make arbitrary requests to its backend data store.


Archiving my open-source projects

February 24, 2018
[ personal ]

It's well past time that I admitted something to myself: I am no longer actively maintaining any of my personal open-source projects.

As I was staring at my inbox this morning, noticing that it was full of github issue reports and thinking "I should really make time to respond to those" and then feeling ashamed that some are now several months old, I came to a surprising realisation – it's not that I can't make time to maintain those projects these days, it's that I no longer want to. I'm not "busy with family stuff" like I've been in the habit of telling myself, and I won't "get to that sometime soon". I'm getting my software fix on the job and I'm spending my personal time on other things, and I'm surprised to find myself OK with that.


Are we Python yet?

January 28, 2015

While it was a lot of fun to see a web-based python interpreter beat my system python on a single carefully-tuned benchmark, that result obviously didn't say much about the usefulness of PyPy.js for any real-world applications. I'm keen to find out whether the web can support dynamic language interpreters for general-purpose use in a way that's truly competitive with a native environment.

Inspired by the PyPy speed center and the fine Mozilla tradition of publicly visualising performance metrics, I've been working on a benchmark suite and metrics-tracking site for PyPy.js. The initial version is finally live:

Are we Python yet?

TL;DR:  not really, not yet – but we're tracking slowly towards that goal.


An Experiment in Improving Compressiblity

July 17, 2014

Alternate title: reduce your compressed file size with this one weird trick!

One of the top items on my list for PyPy.js development is to reduce the size of the initial download – it currently weighs in at a hefty 3.1M of compressed javascript code plus another 2.4M of binary data. The big wins here are clearly going to come from just generating less code, and I have made some promising initial progress on that front. But it's also a good opportunity to experiment with some after-the-fact techniques for reducing the compressed filesize without having to change the actual generated code.

The obvious approach is to reach for a higher-performance compression algorithm, perhaps bzip2 or LZMA. But these algorithms can suffer from slow decompression speeds and are not generally supported in today's web browsers. For shipping compressed content on the web today, gzip is the only game in town.

So can we do better while staying within the confines of gzip?


PyPy.js: Now faster than CPython

May 06, 2014

OK OK, I couldn't resist that title but it probably goes a bit far. Let me try for a little more nuance:

PyPy.js: Now faster than CPython, on a single carefully-tuned benchmark, after JIT warmup.

It has been the better part of a year since I first started hacking on PyPy.js, an experiment in bringing a fast and compliant python interpreter to the web. I've been pretty quiet during that time but have certainly been keeping busy. Some of the big changes since my previous update include:

The result, while still rough in a lot of places, is nonetheless an exciting milestone: the full PyPy interpreter, compiled down to javascript and re-targeted to emit asmjs from its JIT, running the pystone benchmark faster in a browser than the native CPython interpreter runs it on bare metal.


PyPy.js Update: A Proof-of-Concept JIT

August 08, 2013

Two weeks ago I hatched a plan to port Python to the Web Platform by using Emscripten to translate PyPy into JavaScript. My hope is to produce something than can run in the browser with performance comparable to a standard Python interpreter, a hope which hinges on two key ingredients:

  • PyPy's powerful just-in-time compiler, which can optimize the hot loops of your program into efficient native code.
  • The recent work on asm.js, a low-level subset of JavaScript that can act like an efficient virtual machine in the browser.

By translating the PyPy interpreter into asm.js code, and by having its JIT backend emit specialized asm.js code at runtime, it should theoretically be possible to have an in-browser Python implementation whose hot loops perform within a factor of two of native code.

I'm excited to report a small but important milestone on the road to making this a reality.

It's certainly not a full Python interpreter, and it comes with many caveats and question-marks and todos, but I have been able to produce a simple demo interpreter, with JIT, that approaches the theoretical factor-of-two comparison to native code under some circumstances. There's a long way to go, but this seems like a very promising start.

TL;DR? Feel free to jump straight to the important graph.


PyPy.js: First Steps

July 23, 2013

I've been spending a lot of time in JavaScript land lately. It's not totally unexpected – when I first applied for a job with Mozilla, I was warned only semi-jokingly that "they hire all the best Python programmers and then force them to write JavaScript". I've no deep love or hate for it as a language, but JavaScript is pretty interesting to me as a platform, as a kind of runs-everywhere lowest-common-denominator environment that is slowly being molded and coerced into a pretty decent universal runtime. But if "the Web is the Platform", what's a stranded Pythonista to do?

Port Python to JavaScript, of course!

This has been done before in a variety of ways. Skulpt and Brython are impressive re-implementations of Python on top of JavaScript, including interactive consoles that make for a very compelling demo. Pyjamas lets you translate Python apps into JavaScript so they can be run in the browser. There are many more examples with varying degrees of success and completeness.

I don't want to down-play the phenomenal efforts behind projects like this. But personally, I'm a little wary of the re-implementation treadmill that they risk being stuck on. I'd much prefer to leverage the work that's already been done on making a fantastic Python interpreter, along with the work that's already been done on making a fantastic JavaScript runtime, and re-implement as little as possible while gluing them both together.

I've finally taken my first tentative steps down that path, by combining two amazing projects open-source projects: PyPy and Emscripten.


Exploring Security on

December 05, 2012

A few weeks ago, I was involved in discovering a security flaw in the pre-beta version of, the hosted account manager that drives Mozilla Persona. It was fixed quickly, but was not publicly disclosed until the team could conduct a full review of any potential impact. It is public now, and we're confident that no users were affected, so I wanted to share my take on the experience.


Securing Pyramid with Persona and MACAuth

October 04, 2012

Mozilla Persona went into beta release last week, and it has been very exciting to see the interest and positive press it has generated. I particularly liked the release of pyramid_persona and the accompanying article Quick authentication on pyramid with persona – it is cleaner, simpler, and more feature-full than my attempt at Pyramid/BrowserID integration from last year. Great stuff!

But there is one weak point to using Persona for authentication: it makes automated access difficult. The login flow depends heavily on javascript and assumes that authentication will involve a real live user and a full-blown web-browser. Scripting access to your site via something like requests would be tricky at best, and downright impossible in the general case.

Most of the webapps we build at Mozilla Services are meant for machines, not people, so we've had to tackle this problem head-on. We have found that a combined authentication approach works very nicely – we provide Persona for live users, and the much more automation-friendly MAC Access Authentication for machines.

In this post I'll show you how easy it can be to combine the two, using pyramid_persona and pyramid_macauth for the heavy lifting, and pyramid_multiauth to tie them both together.

read more >> is now a Persona Identity Provider

September 06, 2012

After a few days of hacking, "" now acts as an Identity Provider for the BrowserID protocol, a.k.a Mozilla Persona. This means I can now log in as on any persona-enabled website while retaining complete control over my identity. I do not have to delegate my details or my credentials to a third party, even one that I would trust as much as Mozilla.

Here's the BrowserID support document to prove it.