If you use screen + irssi a lot, you’ll know that sickening feeling when “screen -r” gives you a message that there are no screens to be resume. This happens when the computer is rebooted, and you lose all your screens. To add salt to the wound, you probably had your channels in some very specific window. For example, #seneca could be windows 2 and #developers could be window 6. And you can’t quite remember what was between 2 and 6.

While I can’t solve the computer rebooting problem, I have figured out a way to make connecting back to all your channels painless.

The first thing you have to do is create a network. A network would then contain a list of channels. Here’s the syntax to create a network :
/network add -nick cesar -realname “Cesar Oliveira” -autosendcmd “/^msg nickserv identify password” mozilla
It’s pretty self-explanatory.
-autosendcmd sends a message to the server once you are connected. In my case, I identified myself to nickserv with my cryptographically strong password (The /^msg means I don’t want to see the input. That way it doesn’t open up a new query window in irssi).
The last parameter is just the name of the network, which doesn’t have to be the same name as the server your connecting to (eg. irc.mozilla.org).

Then you add channels:
/channel add -auto #seneca mozilla
/channel add -auto #firefox mozilla
…
/channel add -auto #kittens mozilla
mozilla should correspond to your network. #seneca will be window 2, #firefox will be window 3…

Finally, when you get disconnected, you can connect to the irc server :
/connect -ssl -network mozilla irc.mozilla.org

Enjoy!

I’ve been spending a few days on trying to develop a few tools for editors to use to quickly reject addons for obvious defects, such as loading remote scripts. But I wanted to get deeper into the javascript stuff mainly because it’s a) it’s harder and b) it’s where the real problems lie.

But as anyone can tell you, it’s not an easy task (going towards damn near impossible). Firstly, you can’t really use a lexical parser. Well, you can, but it won’t be dependable. Let’s take an example out of the Reviewer’s guide :

document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));

Which is sneaky way of creating a script element, though I question the competence of someone who will use this as their main line of attack (it’s practically spelled out for you). But taking this as a use case, and ignoring the fact that they can use document[cheese] instead, I wondering if parsing the javascript would make figuring this stuff out any better.

Happily, I have spidermonkey and a js shell to do any parsing I wish. But I found out some cool things that you can do in the shell, such as looking at the bytecode for an entire function using the dis() command.

This was interesting. Certainly, there are some optimizations you can do for :
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
I would be shocked if it didn’t end up spelling out :
document["createElement"]("script");

I had a few hurdles to overcome. Firstly, document is not defined in the javascript shell. Thinking it was defined in the xpcshell (owww. I was misled by some apparently unused tests and my general ignorance that xpcshell tests went into unit/ and not js/ directory) I went through the added trouble of coping dis() and related functions from js.cpp to xpcshell.cpp. Once I realized that document wasn’t defined, I made a document mock object just to see what the blasted bytecode would look like.

I was a little disappointed. This source:

var document = {
createElement : function(s) {
print("damn");
}
};

function foo() {
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
}

dis(foo);

Ended up being this bytecode :

00000:  name "document"
00003:  string "createElement"
00006:  callelem
00007:  string "s"
00010:  string "c"
00013:  add
00014:  string "r"
00017:  add
00018:  newinit 3
00020:  zero
00021:  string "i"
00024:  initelem
00025:  one
00026:  string "p"
00029:  initelem
00030:  int8 2
00032:  string "t"
00035:  initelem
00036:  endinit
00037:  callprop "join"
00040:  string ""
00043:  call 1
00046:  add
00047:  call 1
00050:  pop
00051:  stop

Source notes:
  0:     0 [   0] newline
  1:     6 [   6] pcbase   offset 6
  3:    37 [  31] xdelta
  4:    37 [   0] pcbase   offset 19
  6:    43 [   6] pcbase   offset 25
  8:    47 [   4] pcbase   offset 47

So, almost. The document["createElement"] part was correct, but the .join() wasn’t optimized. Although I wasn’t overly estatic, I knew that this was just one (somewhat lame) use case in the countless of possible others.

This is making me rethink whether lexical tools are the way to go. While they don’t give you any definitive proof that there is a possible security hole, they can still be useful. For example, if you want to use XMLHttpRequest, then you have to call it at least once in your program (even if you say var Widget = XMLHttpRequest). And at least that can bring up warning flags, or at least give editors a place to look.

I don’t think any tool can completely replace a human being. But hopefully, tools will help make the review process easier because you can start looking at high-risk areas first rather than starting from a arbitrary point and not coming across something until 10 minutes later.

I have been falling back into unhealthy sleep patterns again. Lately, I’ve been going to bed at 4 and waking up at around 13-14. I haven’t quite found the reason why. When in MV on weekends, I liked waking up earlier (ok, maybe 10 early ) because I have the rest of the day to do stuff. And during the weekdays, 8:20 wake-up times are the norm.

My mom thinks it is because I’m not working, and hence I don’t have a a reason to wake up earlier. I don’t think that is the reason. Mainly because I’ve been struggling with this even when I was in college/high school. I think the real reason is the unfortunate location of my room, and the amount of light that is getting in.

My room has a large window that lets you look out into the street. Which actually kinda sucks for privacy reasons, so I tend to have it closed (blinds + curtains). Unfortunately, the amount of natural light coming in is negligible. So even mid-day, if the lights were off you couldn’t tell if it was 10 or 14. The nice thing about the apartments is that I was on the 3rd floor, and the blinds were open enough that you could tell it was morning or afternoon. At the very least, the bright sun would wake you up if the alarm clock didn’t.

Something that actually did help when I was in college was when the lights to my room where on while I was still sleeping. I would usually get up an hour after they were on. (how do I know? My mom would call me and turn on the lights at 8, and I was usually up at 9). I wonder if I should invest in a new alarm clock or get a room where the sun can wake me up.

This has annoyed me all day. First they renew the “economic agreement” with Mozilla until 2011, and now they’re going to release their own browser. What?

Don’t they have shareholders who have a big stake ($463 right now) to gratify? That’s like Microsoft hiring Linus Torvalds to work on the Linux kernel. How do you get away with something like that? Is Google so rich that it is paying people to compete with it?

Actually, that last one is kind of funny.

This makes so little sense to me that I have to think of outrageous reasons for the announcement :

1. Starting with the least outrageous reason : Google is actually trying to expand competition in the web browser/mobile space. Though, I thought that IE/Opera/Firefox/Safari was a good mix. This isn’t gas stations we’re talking about. Competition for browser market share extends far beyond these four browsers.
2. They legalized mind altering drugs in Mountain View. (Mythical mushrooms in the Escape menu, Hippie crack at Slice)
3. They’re sending Mozilla a second hint that they want Mozilla to drop Gecko
4. Judging by some of the screenshots, this is another way to get more Google traffic. But come on? Your own browser?

Comments, additional conspiracies welcome.