Update: Mihai consistently defied people that told him how
long he had. It's over 3 months since he was given
several weeks,
and years since he was given months. He died on 23 April 2015.

A few days ago Mihai Șucan
went home to Romania. We're not expecting him to fix any more bugs in Firefox,
but I'd like to raise a glass of
Țuică, to the
1919 bugs that he has been involved in fixing in Firefox.

Devtools at Mozilla has only been a serious thing for a bit under 5 years.
Firebug is much older, but wasn't really a Mozilla project. We started for real
in the middle on 2010, and Mihai was one of the first people to start
helping.

The console code was initially a complete mess. Code that everyone touched
and no-one loved, born before there was momentum, when landing code was a dark
art.

I remember more than once looking at console code thinking - 'I can do the
right fix in a few weeks or the wrong fix in a few hours', and like many before
me, leaving the root problem for someone else to fix.

That someone was Mihai.

Most of the Devtools team at Mozilla is remote, so all I knew of Mihai to
start with, was his strange voice. I'm no expert on Romanian accents, but this
was different. His voice was compressed and clearly a struggle. He coughed
regularly. So we listened more carefully when he spoke and thought nothing of
it.

And Mihai continued to fix the console. Kevin Dangoor, who ran Devtools at
the time said to me once - "You know the problem with Mihai is simply feeding
him enough bugs - that's nearly a full time job!"

When video chat became a thing, I think we all noticed Mihai's hands, and
wondered how he typed, but were probably too embarrassed to ask what was up.

I'm not sure who asked first, but around the time we first all got together
in London I asked if he could travel easily, and found out the detail.

E.B. is a brutal skin condition which causes chronic blistering, and makes
everyday objects dangerous. Those with it are sometimes called butterfly
children because of their brittle skin. In Mihai's case it has left him in a
wheelchair, and having to very gently punch the keyboard to get anything
done.

E.B. makes you very vulnerable to skin cancer from the continued scarring
from the blisters. So everyday objects that wouldn't pose a risk to those with
normal skin become sharp and dangerous to people with E.B. Needless to say -
anyone with E.B. has a huge mountain to climb every single day.

When presented with the mountain that just existing presents to
EB sufferers, I think many people would be happy to just exist. But that's not
Mihai, who has made developer tools for the web a personal mission. There
aren't many things you can do when the outside is so dangerous, but Mihai found
something he could do and did it with a passion.

Mihai's illness has meant he hasn't been able to work on the console
recently, and we've probably not adjusted properly, but that's temporary.

Mihai's legacy is that there are hundreds of millions of people using a
product, Firefox, that Mihai contributed to, hundreds of thousands of
them spend a significant proportion of their time in the console that was his
responsibility. And there are billions of people using websites created by
people directly helped by Mihai's work.

In all but his darkest moments, Mihai copes without complaining. The
annoying molehills that we complain about are largely irrelevant sideshows to
Mihai, and working with him has been an honour.

If you've used Firefox Devtools, or if you've used any website where the
author might have used Devtools, or if you're impressed by what Mihai has
overcome, there's EB Research which
investigates the root causes and solutions to the problem of EB.

Mihai always wants to do more, but he needs your help with this bit:
EB Research.

(The video in this post is from a series created for
DEBRA
international by Lowe GGK. The full set of
images and
videos
is well worth a look)

The immediate context to this post is
Self-XSS
but it may have a wider context in avoiding other Internet scams.

I’d like to frame Self-XSS in terms of a human script execution engine. It’s
an interpreter - and probably not JITed, but it works with a broad and poorly
specified grammar. Not all humans have the same interpreter, but there’s enough
of a dominant language to provide a mono-culture which makes attack easy.

However not all script execution engines are created equal. Some come with
advanced scam detection routines. Some have random timeouts and many have
surprising execution errors. It’s not my intention to be derogatory, but it’s a
fact that not everyone has English skills the same.

So Self-XSS is a script that uses this script execution engine to coerce
someone to do the attacker’s bidding, probably to their own detriment. If you're
writing a scam script, you need to keep the scripts simple enough to avoid
the victims’ scam-detection, timeouts and errors.

These problems mean that we might be able to draw a graph of script
complexity vs completion rate (where ‘completion’ is a scam that succeeded).
It might look like this:

I’d like to suggest that humans are not that simple and that we shouldn’t
expect something as predictable as that.

Many (most?) of the tasks that we complete on computers can be done purely
using unconscious / heuristic / system 1 processing (in dual process)
terms. That is to say using parts of the brain that are fast, pattern-based and
non-analytical. Its less common that we need to use conscious / systematic /
system 2 processing (slow, lazy, analytical). (“Thinking, Fast and Slow” is
probably the canonical work to understand these terms in more depth)

I’d suggest that, for most people, scam detection is a system 2 operation.
So forcing use of system 2 to prevent scams might help. (Obviously this is at
odds with the “don’t make me think”
approach to good UX design - I’m obviously not arguing that bad design is a
good thing).

We don’t have a lot of data for Self-XSS. The data that I know of is:

Attack

Completion Rate

Complexity

Facebook

<10%

3 steps

Win+R [1]

<1%

5+ steps

Other attacks [2]

<1%

4+ steps

It seems reasonable that an infinitely simple script would always succeed,
and that at some point of complexity the completion rate will drop to 0. So
that something like 5 data points.

It would be fair to criticise this as ‘not much data’, which is part of the
point:

If you have more data in places where Self-XSS attacks have worked, please publish them and tell me.

If you know of research into the use of system 1 vs. system 2 in detecting scams, I’d love to hear about it.

However, given the lack of data, it seems to me that there is a surprising
drop-off in completion rate with increasing script complexity. There isn’t much
any evidence for attacks that were somewhat complex, and got some people - it
looks as though all attacks that were somewhat complex were surprisingly
unsuccessful.

So the drop-off rate might look something a bit more like this:

Which might in some small way indicate a point in script complexity where
system 2 needed to get involved, and where the analytical part of system 2 said
“Wait, am I being scammed?”

Summary: We shouldn't think of scams purely in terms of smart people not
getting scammed, and some sort of level of intelligence providing scam
protection. Perhaps for many people, scams are detected when system 2 gets
involved, and there may be ways in which we can design software to protect
people.

How does this affect browser developer tools? I believe that we have
solutions [3] to the problem that tailor the addition of complexity only to
places where people are most at risk, so 99.99% of people won't be affected.
Also the level of complexity that is being added is a low as it can be whilst
still being effective.

Notes:

[1]: Pressing Win+R on Windows systems gets you a system level command
prompt. I have no evidence that this has been used in Self-XSS attacks,
probably due to limitations in cmd.exe forced an attack script that is 5 or
more steps.

[2]: I've seen several demonstrations of Self-XSS that involve 4 or more
steps, but none that have a high completion rate.

The built-in developer tools are mostly
built in JavaScript.
So you'll need to be comfortable with using JavaScript to create applications
(rather than just tweaking pages). Obviously our tools are just for Firefox so
we can take advantage of
ES5 and
ES6
features the second they're added to Firefox so knowing about what's new would help too.

But our team is particularly about helping people understand content
(i.e. HTML and CSS) so you'll also need to understand how pages are laid out
and how to get a browser to bow to your bidding. You'll also need to be good
at creating interfaces that people want to use, and fast at learning because
there's a lot to our platform.
Knowing some C++ could be useful too.

Perfect would be if you've spent time in the trenches of web development
thinking "If only the tools would tell me X, Y and Z, I could be soooo much
better". This is your chance to make millions of people better at their
jobs.

Our team is all around the world, so you can enjoy working from home, and
you'll need to communicate well over IRC, video chat and email. But you'll
also be working on open source software that changes the lives of hundreds of
millions of users worldwide.

If you can help,
apply here,
and contact me directly (twitter or
jwalker at mozilla.com) to make sure you're in
the system, or to ask questions.

So yesterday a whole bunch of people to together to hack on some commands for
the new Developer
Tools Command Line. Thanks to everyone that took part.

This is a quick summary of the commands and hacks that we created. We've now
got to work out what to do with them. Some we'll clean up, localize, test and
ship, and some we'll do some we'll suggest putting onto AMO.

Creating commands with Scratchpad

Creating commands from a Command Directory

Find somewhere to store commands and copy this template
to a file called hello.mozcmd (or you could clone the repo which
could come in handy for submitting your commands). The filename isn't important
but it should end .mozcmd. Then tell Firefox where your directory
is with this command: pref set devtools.commands.dir <PATH-TO-DIR>.

Then refresh the commands from the command dir using cmd refresh
and try out the new command: hello.

I'm in the process of finishing off bug 724055 which will make it as
easy as is possible to create new commands, just set a pref to point to a
directory where your commands are stored in JSON (ish) files, and you're done.

In the next few days I'll update this post (Update: see here)
with a set of resources for creating commands and ideas for commands.
We'll hang out in IRC and crank away and see how many commands we can get
written in a day.

If you can spare some time, we'd love to have some help.

Update: Originally this post had a date typo and said the 27th. The real date
is the 26th.

TL;DR: We're adding a toolbar to Firefox, for developers, which includes a
command line.
It's a great place to add small tools and experimental features, and we're
making it easy to add your own commands.

The toolbar should land in Firefox 16 or 17 and will look like this:

The buttons are useful, but I'm most excited about the commands.
We can add an almost unlimited set of commands here without cluttering up the
UI, or making things slow, and we've done lots of work to make the command line
easy to use.

The challenge: It might be stretching things a little to call the command line
a 'platform', and commands 'apps', but the command line still needs commands to
be successful. There's a list of commands that we're working on for
manipulating Firefox developer tools, and we'll be expanding this list to
include system level commands too.

We're planning on a hackathon in a couple of weeks to add to the list of
commands and to check that it really as as easy as we think it is to extend.
Details soon.

If you want to try it out, it's in Nightly now, you'll need to flip the
devtools.toolbar.enable preference in about:config.

What is Self-XSS?

Dr. Evil has several options for getting his script to execute in the page of
another site. Generically we call this XSS. Self-XSS involves using
social engineering to coerce a user into manually executing JavaScript using
the location bar or developer tools.
For more, see socially-engineered XSS attacks.

How does this affect users?

Minor inconvenience of having to set a preference (one time only) to enable user JavaScript on sites using this Self-XSS protection.

I think this is a fairly clear net win: Minor, one time only, inconvenience to
a sub-set of web developers, vs. full-time protection for the many that
wouldn't recognize a self-xss attack.

Objections: This is a user problem

The goal of educating 7 billion people about what JavaScript can do is lofty,
grandiose, ambitious and utterly unattainable. There has to be another solution.

Objections: This is a Facebook problem

While it's true that allowing untrusted, unvetted, third party, dynamic content
onto your site is something to avoid, I don't think that fixing this either is
going to happen, or would fix the problem. The attack could easily forward you
to another site to see the clipboard injecting flash, before returning you to
the original site for the 'paste' step.

Objections: This is a Flash problem

While it's true that Adobe's clipboard policies are more relaxed than those of
major web browsers, we've seen people caught by instructions that ask people to
select/copy their own attack script. We think that the level of pain caused to
developers by the CSP solution is low enough that we can justify the additional
protection.