Are We Meeting Yet?

Tracking Mozilla meetings across time is a thorny problem. People send out meeting reminder emails, but often they forget to update a URL or a date or a time, or they update it wrong due to a DST change, or they update the local time but not the UTC time, or vice versa. Wouldn’t it be awesome if there was one URL which pointed you at the next occurrence of a weekly meeting?

Enter Dirkjan Ochtman’s “Are We Meeting Yet?“.

Construct a URL like this:

Pretty obviously, the first bit is the timezone (not sure why it’s half-a-timezone), the second is the date of the first instance, the third is the time of day, the fourth says “repeat weekly”, and the fifth is the title. Visit the URL and see what sort of display you get. Note that it gives you the time of the upcoming weekly meeting even though the time directly encoded in the URL is from two weeks ago. That’s the “weekly repeat” part.

The upshot of this is that you can construct one URL for your meeting (defined in the timezone in which the meeting is fixed, which is Pacific Time for most but not all Mozilla meetings) and put it in your reminder email, and you’ll not have to change it unless the meeting time actually changes :-)

People who click the link can see the time in the timezone of definition, the time in UTC, and the time in their local timezone, all in one link. No more arguments about which form of the time is more important!

It would be nice to have a form to construct such URLs with a timezone picker, a datepicker and a timepicker. Anyone feel like coding one up? (HTML5 input controls would make such a thing easy to write, but sadly we haven’t implemented them yet :-( )

TEMPORAl Distortion

The UK’s General Communications Headquarters (GCHQ) has a system called TEMPORA. TEMPORA is the signals intelligence community’s first “full-take” Internet buffer that doesn’t care about content type and pays only marginal attention to the Human Rights Act. It snarfs everything, in a rolling buffer to allow retroactive investigation without missing a single bit. Right now the buffer can hold three days of traffic, but that’s being improved. Three days may not sound like much, but remember that that’s not metadata. “Full-take” means it doesn’t miss anything, and ingests the entirety of each circuit’s capacity. If you send a single ICMP packet 5 and it routes through the UK, we get it. If you download something and the CDN (Content Delivery Network) happens to serve from the UK, we get it. If your sick daughter’s medical records get processed at a London call center … well, you get the idea. … As a general rule, so long as you have any choice at all, you should never route through or peer with the UK under any circumstances. Their fibers are radioactive, and even the Queen’s selfies to the pool boy get logged.


Cheaper Data Centre Power

Evening out demand to match supply is a big problem in the energy industry. One way is differential pricing – charge more at peak times. Another way is energy storage, so you can supply more at peak times. One method of storage is to store the energy using compressed air. The disadvantage is that compressing the air gives off heat, and re-expanding it requires heat. Not supplying heat during re-expansion makes the storage much less efficient.

So which industry has large and fairly constant power costs it would like to reduce by buying some of that power at off-peak prices, equipment which can be placed anywhere, including where land prices are cheap, plus a lot of waste heat it doesn’t know what to do with?

Someone should come up with a gas compression power storage system for data centres.

Cost of power, ballpark: $0.06 per kWH peak (say 8am – 6pm), $0.03 off-peak
Power consumption of server: 1KW
Current cost of power per server per day: $1.02
Potential saving per server per year if all power used were priced at the off-peak price: $110

One issue is that a 5l bottle can store 500kJ of energy (0.14 kwH), so you’d need 500l per server. That’s a lot, so you may not be able to get the full saving unless you use an underground cavern rather than surface storage tanks. But if land is cheap, you could make a dent in your power bill.

Believe it or not, this post was half-written before I saw this Slashdot article.

Bugzilla API 1.3 Released

I am proud to announce the release of version 1.3 of the Bugzilla REST API. This maintenance release has a bug fix or two, and fully supports the version of Bugzilla 4.2 which has just been deployed on For smooth interaction with BMO, you should be using this version.

The installation of BzAPI 1.1 on will go away in 4 weeks, on 4th April. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla and may not work correctly. Please use either the /1.3 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

No One Considered…

Micire’s talk was an excellent example of what can happen when a device maker doesn’t lock down its device. It seems likely that no one at Google or Samsung considered the possibility of the Nexus S being used to control space robots when they built that phone. But because they didn’t lock it down, someone else did consider it—and then went out and actually made it happen.

LWN (an awesome publication; do subscribe)

Bugzilla API 1.2 Released

I am proud to announce the release of version 1.2 of the Bugzilla REST API. This maintenance release has a bug fix or two, and some features useful to the admins of Bugzillas which BzAPI is pointed at.

The installation of BzAPI 1.0 on will go away in 4 weeks, on 19th December. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla. Please use either the /1.2 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

Google Calendar, and Meetings in UTC: The ‘Rekjavik Trick’

Google Calendar is great; I’m a big fan. A little while back, it acquired timezone support for events. More recently, it acquired split timezone support (start and end in different timezones), which is awesome for flights. And there’s a drop-down list of all the countries in the world with all of their applicable timezones. Surely that must be comprehensive, right?

Well, yes and no. I attend one meeting which is scheduled in UTC. There seems to be no entry in the massive timezone list for this. If you say you are in London (GMT+00:00), then your event will obey the UK DST rules, which means it won’t actually be in UTC during the summer.

However, there is a workaround. There is one country in the world which uses UTC and no DST – Iceland. So, if you want to have a meeting whose time is set year-round in UTC, then tell Google Calendar you are holding it in Rekjavik.

(It would be nice if Google would add an explicity “UTC” option to their massive timezones list, but this will do for now.)

Website Evangelism: Mobilizing Mozilla

Mozilla has recently (re)launched Firefox for Android, and is soon to launch Firefox OS. The success of these two products is key to our mission of keeping the web open.

However, both products are mobile products, and the mobile web is currently a WebKit-focussed semi-proprietary ecosystem.

It is vital to our success that the mobile web works well on Gecko. Much research has been done into how to do this. We control only half the experience. We can alter how we render the content we are sent, but not what content we are sent. So, we can make things a bit better by unprefixing CSS and DOM properties, fixing Gecko and User Agent string spoofing, but none of them is a silver bullet. Sometimes, the problem cannot be fixed on our side. The code uses too many WebKit-isms, or assumes it’s running on an iPhone. Just like we had to in 2000, we have to make the web better by helping developers to fix it.

We have some advantages over last time round. Not everyone has a mobile-specific website. Changing User Agent sniffing code is much easier than “rewrite your site to use neither document.layers nor document.all”. We have large desktop market share, a significant brand presence, and an enormous amount of goodwill from web developers who agree with our mission. And our community is much, much bigger.

However, we need to mobilize a significant tech evangelism effort. Currently, there are a few employees working part time on this problem. They have had some significant successes already – Google, Facebook, Twitter, Youtube, Instagram – indicating that we can make a difference this way. We have tools and metrics so we can be encouraged by progress. But the web is big, the problem is very large and we need an army. My assertion is this: unless you are directly involved in the development of Firefox OS or Firefox for Android, or have managed to get a device to test it on,

Website evangelism is the most effective way you can contribute to the Mozilla mission between now and March 2013.

(Yes, tweet that.) If you have control over your own time, and you believe in the Mozilla mission, ask yourself whether what you are doing now will have as much long-term impact as time spent doing this. Then, get involved. Geeks and non-geeks alike can make a difference here. Any questions? Lawrence Mandel is your man.

Bank Details Secrecy?

In order for someone to make a direct bank transfer into your account (an increasingly common way of moving money around, even between individuals), you need to give them your account number and sort code. This information is also printed at the bottom of cheques (I write less than 5 a year these days) and on debit cards.

Question: is there anything a person of evil intent can ‘usefully’ do with just your bank account number and sort code?

Remote Access for Tech Support

Pretty much every geek has the sad job of being the tech support guy for their family and, if they aren’t nimble, their friends too. This is particularly frustrating when:

  1. they expect you to know everything about their computer when you haven’t used Windows for 10 years
  2. their computer is slow as molasses due to being loaded down with c**pware
  3. you have to do the debugging over the phone

1 and 2 I can’t help with, but 3 I can. If you are a Linux user, and want to support Windows users using a simple graphical remote access system, here’s one way to do it. (Other suggestions welcomed.) The secret is to use UVNC Single Click. However, this system is not very well documented. This is what I did:

  1. Download the “” file
  2. Hack the “helpdesk.txt” file inside it (here’s mine), and the logo files as well if you can be bothered (the result will not look particularly pretty however hard you work)
  3. Configure it with your fixed external IP or dynamic DNS, plus a non-standard high-numbered port
  4. Make sure the port you chose is open on your firewall, forwarding to 5500 on your machine
  5. Upload the zip file to UVNC’s .exe maker (the fixed username and password you need are printed on that same page; this may some sort of weird anti-spam thing)
  6. Send the result to your debug-ee (you may need to rename the .exe to .exe.dat or similar to dodge dumb mail filters)
  7. Use “ssvnc” to accept connections. Switch to “listen” mode, turn off SSL (I never got that working).
  8. Tell them to run the .exe and double-click one of the Connect options.
  9. Their desktop should appear in a window on your machine.

More “Transmittable” Short URLs

URL shortening services are very popular. They basically redirect a short URL – e.g. – to a longer URL. (And keep logs, which can be monetized, hence Twitter’s service and the requirement that tweets use it.) Most URL shortening services use the following set of characters in the unique tag: [A-Za-z0-9] – a total of 62. 6 characters is a normal number for the tag.

However, when reading such a short URL to someone, e.g. over the phone or across a conference table, a couple of problems can occur:

  • The person reading may misread; they may read “l” for “1” or “0” for “O”.
  • The person reading may under-specify, most commonly by not expressing the case

This makes reading out such short URLs a pain, as one has to make sure to specify case correctly, and to distinguish between similar-looking characters in a possibly-unfamiliar font, or in handwriting. These problems could be avoided, and URL reading would be much easier, if the set was instead [a-km-np-z0-9], and the shortener service treated a submitted tag as case-insensitive.

This would give a choice of only 34 characters. Surely that would mean the tag would have to be much longer? Actually no:

  • 62^6 = 56800235584
  • 34^6 = 1544804416
  • 34^7 = 52523350144

Short URLs could be made more transmittable at the cost of only being 1 character longer. I think some service might find that worth doing…