The developer who started the Witness web app has had to bow out of the project. Are there any other Djangonauts/Pythonistas out there who would like to finish the building of something relatively small, self-contained and useful to Mozilla? Here’s a description of the project:

“Witness” will be a web app which provides proof that person A has agreed to legal document X.

There are loads of applications for this:

• Proof that a Mozilla contributor has agreed to our Committer’s Agreement
• Proof that someone has agreed to the IPR policy necessary for contributing to a standards body mailing list
• Proof that someone has agreed to a trademark licence

These things can be done without an app, but it’s dull and tedious for the person doing the paperwork. Much better to get a computer to do it.

It would involve, among other things, playing with Persona/BrowserID. If you are interested, drop me a line and I’ll point you at the code.

This discussion came up in mozilla.dev.identity – how do you make a decent password strength meter? Now it could be that someone’s already done this (links?), but I’ve never been embarrassed about reinventing the wheel, so here are my thoughts.

IMO, most password strength indicators suck. They give a fixed bonus for adding punctuation or numbers or upper-case letters, and you can’t have a strong password until you have several of those categories. Therefore, to take random examples, a lot of them think “correct horse battery staple” is a worse password than “Tr0ub4dor&3″.

Inspired by xkcd, here’s a straw-man proposal for a Unicode password strength meter which avoids some of the obvious flaws, while still not being overly-complex to implement. Note that this is about strength (resistance to brute force attacks), not about memorability or anything else.

1. Classify every code point by its Unicode script. (The data needed for this is not large, as most scripts are in contiguous ranges.)
2. For each script used, take the number of commonly-used characters (this would be a predefined lookup table), and add the values together to make an “entropy” value, which is a rough proxy for the size of the character space from which the password’s characters were taken. So e.g. an Arabic numeral is 10, an unaccented Latin letter is 26, an uppercase Latin letter is 26, a Chinese character would be about 20,000.
3. Multiply the entropy by the password length in characters.
4. Make sure it’s over a certain threshold, which can vary depending on the application. You might use 300 for web forum membership login, and 1000 for a bank. One could develop recommendations.

e.g.

“Tr0ub4dor&3″:

  26 (lower-case Latin letter)
+ 26 (upper-case Latin letter)
+ 10 (Arabic numeral)
+ 15 (simple punctuation)
= 77

77 * 11 = 847

“correct horse battery staple”:

  26 (lower-case Latin letter)
+ 15 (simple punctuation)
= 41

41 * 28 = 1148

Now, the flaw of this proposal is that the measure assumes all the password characters are independently chosen. Perhaps the way to solve that is to add or multiply a bonus for “script transitions” – letters to punctuation, one alphabet to another alphabet, etc. Because words, the most common case where successive characters are not independent of each other, are most often all one script.

“Tr0ub4dor&3″ has 7 such transitions, “correct horse battery staple” has 6. But “intelligentsia”, while being long, has none.

Thoughts?

MediaWiki’s Help page, at least on the Mozilla Wiki, is far too complex. One of the first topics it covers is the occasional need to do a dummy edit to refresh the internal database caches. I suggest this is unlikely to be uppermost in the mind of most people visiting that page. How to do a link is on the 5th page down on my large monitor, and how to emphasize text is on the 8th page.

Here’s Help:Me, a much simpler page which attempts to show the most important things by example. Do let me know what you think.

Browser Buster, the stress-testing page for Firefox Mobile I mentioned a week or two ago is now an add-on.

You can stress-test Firefox Mobile by visiting http://bit.ly/LH7Kmc , installing the add-on, opening 3 tabs on any web page and then leaving your phone running. Make sure you are on WiFi, and plugged in to power.

Geeky Details

Unfortunately, the Jetpack API for Firefox Mobile is not all there yet, and so I’ve had to implement it in a rather unusual way, using PageMod rather than the Tabs API. The add-on inserts a bit of JS into every page loaded telling it to redirect to a new random URL after 7 seconds.

So this version is not vulnerable to frame-busting scripts, but it is vulnerable to onload modal popups (“Hey! We have an Android app!”) and to pages failing to load entirely. Still, it seems to have better uptime than the iframe-based version. Once the Tabs API is implemented for Jetpack on Firefox Mobile, I can revise it again to be even more robust. It could also now be changed to interact with the page more – clicking links, changing the DOM etc. A good project for someone who sees potential here and wants to take this further.

Top tip: have it running in 3 tabs at once, and keep the tab dropdown open. The thumbnails don’t update (Boo!) but the page titles do, so you can see if it’s got stuck on a page, e.g. “Problem loading page”.

You can enable and disable it via about:addons. Note that because of the way I’ve had to implement it, it makes normal browsing pretty much unusable (“stop redirecting me to random pages!”), so you’ll want to disable it when not testing.

Firefox Mobile’s stability seems to have improved recently; I’ve not seen any crashes with Nightly all morning.

I’ve heard it would be helpful to the Fennec Native team if they had more crash data. So I’ve written the world’s simplest random website loader. Load it up on your phone or tablet and just let it go. It loads a new random page every 10 seconds. Glance at it every 10 minutes and submit any crashes that appear, or hit “Back” if a frame-busting script broke it. You can test Fennec while doing something else! :-)

I’ve been running it on my phone and tablet for an hour and a half, and submitted 2 tablet crashes (one Flash, one in libdvm).

Of course, it may not produce a high crash volume because it doesn’t interact with the page. Ideally, it would be an add-on, so frame-busting wouldn’t affect it, it could dismiss pop-ups, follow links, crash reports would have the correct URL, and perhaps it could even auto-submit crash reports and restart itself. Suggestions for better tools to use would be most welcome.

This interactive essay teaches about system design using a “ladder of abstraction” paradigm. Two things about it are notable.

The first is the fact that his interactive teaching simulations are built using the web platform, and that’s awesome.

The second is the point he makes in the first appendix:

If a language requires a “compile” or “refresh” to show the results of a change, it even denies us interactive control. Some languages are marketed as “sketchbooks”, but a real sketching environment would, at the very least, offer basic interactive adjustment … .

Perhaps someday this will change. Perhaps IDE makers will focus on dynamic exploration instead of static analysis, rich visualization instead of line debugging. Perhaps language theorists will stop messing around with arrows and dependent types, and start inventing languages suitable for interactive development and discovery.

Until that glorious day, it is our sad but unavoidable responsibility as system designers to build our own tools.

When creating, real-time feedback is key. The interpreted nature of JavaScript, HTML and CSS means we are in a great place to build creative systems which work like this for the web platform. Some of our developer tools already built into Firefox, and things like Hackasaurus, are there or moving this way.