A child's mind (being free from such tiresome constraints as "not technically
possible", "probably a bit dangerous" and "that'll be lots of hard work") is an
excellent source of ideas and enthusiasm. I've seen many examples of this in
recent years. One such example provided the starting point for this year's
Mozfest adventure:

Child: "Next year, we should bring a robot."

Me: "A robot?"

Child: "A robot. With a camera. And a loudspeaker. That way it can ask
people to help it with the lifts." (lift is britspeak for elevator)

What?

I wrote a tool
for generating hash-sources to make it easier to apply CSP
to your static content.

Why?

CSP can be tricky to deploy, especially for sites that make use of inline
scripts and styles. Also, sometimes people go to the effort of applying CSP to
their web applications but forget to apply a CSP to static content on their
websites; this can negate the benefit of CSP work done elsewhere (XSS on the
same origin as you means you're XSSed whether you're using CSP or not).

How?

The tool works by parsing documents using html5lib
and generating hash-source values for script and style elements, as
required.

What?

Most people would agree that cheap 3D Printers are fun and exciting but there is
a commonly held view that they're not really suitable for making useful things.
We've been working on a robotics project that goes some way beyond most objects
I've seen people print.

Why?

We wanted to build a robot lawnmower. It didn't take us too long to figure
out you can't just go and buy parts for robot lawnmowers so we decided to
build a 3D Printer (more on that another time) and make some.

You can also enable this by default with a build option that we'll cover in
a bit.

2) Use the Firefox Developer tools to debug the main process:

The above works for all applications on the device... but what if you want
to get to bits of the actual runtime? Well you can do this too. Follow the
same steps as above, but this time use Firefox with the
devtools.chrome.enabled pref set to true.

Connect to your device (using the App Manager) and on the Device screen,
you'll see a "DEBUG MAIN PROCESS" button; click that and you can debug
JSMs, run privileged JS in the scratchpad, accidentally destroy your device,
etc.

3) Some convenient defaults

Running through the first time use setup every time you push a new version
of gaia to a device can be a drag, and having to configure wifi, and setting
the device to debug certified apps... and turn off the lockscreen, etc.

Setting some options when you build gaia saves many of these steps. E.g:

DEVICE_DEBUG=1NOFTU=1makereset-gaia

will keep your wifi settings, enable debugging of certified apps, disable the
lockscreen, remove the prompt to accept debugger connections and turn off the
first time use screen.

4) Use a proxy to inspect and manipulate HTTP / HTTPS traffic

Tools like Burp and ZAP
have features which are useful if you're making or breaking stuff for the web.
There's an MDN document describing one way of doing that here
- but there's another way (yes, I'm going to update that article); Plug-n-Hack
providers (like Burp, ZAP and some others) provide manifests containing
information on how clients should configure themselves, including root
certificates to install for TLS termination, etc.

This, combined with the 'debug main process' feature of the devtools, allows
you to install your proxy's root cert onto your device by running some code
from a scratchpad.

You can then connect to your proxy in one of two ways:

You can pull the default prefs from your device, change them to add the relevant proxy prefs, put them back.

Or, you could configure your tool to proxy HTTP and HTTPS transparently
then set up iptables on your device to point to your proxy. E.g, to make
HTTPS traffic go through your proxy tool:

But, if you find yourself doing this lots, there's a way that's even more
conveient; set up a testing LAN where all traffic is proxied by default.
This way, you can turn proxying on and off just by changing which wireless
LAN you're connected to.