In case it's helpful to others, I thought I'd mention a few more resources. I may even keep this list updated. If I don't, you can always browse my full list of JavaScript links.

Eloquent JavaScript

This is the interactive tutorial I mentioned in my original post.

JavaScript: The Good Parts

This is the book I mentioned in my original post. Everyone recommends it.

JavaScript for PHP Developers

Very fortuitously, I was asked to review a new book by Stoyan Stefanov shortly after I began learning JavaScript. I loved it. Stoyan wrote an article for PHP Advent called JavaScript for PHP Developers. Read that, and if you like it, order the book.

PHP Functions in JS

This is a fantastic list of PHP functions implemented in JavaScript. If you want to see how you would do something in JavaScript, this is a good place to start.

JavaScript Patterns

Several people have recommended that I read this book, also by Stoyan Stefanov.

3 Ways to Define a JavaScript Class

After I learned there are no classes in JavaScript, I found this great post by Stoyan explaining the issue in great detail.

Learn JavaScript

This is a great list of JavaScript resources maintained by Mozilla.

JavaScript Garden

A really good collection of documentation about the most quirky parts of the JavaScript programming language. Recommended by Robert Huzzey.

JSLint

As an unapologetic pedant, I love anything that enforces rigor, especially when I'm in unfmiliar territory. Just as you might rely on the W3C Validator to make sure your HTML is valid, JSLint is a great tool for checking your JavaScript.

Learning Advanced JavaScript

An interactive tutorial from John Resig that's a good step up from the basics.

Crockford on JavaScript

I have not watched these yet, but everyone says Douglas Crockford is a great teacher. This is a nice compilation of videos, transcripts, and photos from his acclaimed series of lectures on the history of JavaScript, its features, and its use.

Introducing Scratchpad

An introduction to Firefox's web developer tool called Scratchpad. The browser is the best place to experiment with JavaScript, especially once you get past learning the basic syntax.

Essential JavaScript Design Patterns For Beginners

This looks like a good list of common JavaScript design patterns, complete with explanations and examples. Probably best used as a reference. I started to read it from start to finish, but that gets boring pretty quickly.

The Complete jQuery Tutorial

This has been recommended to me as a great place to start learning jQuery, the popular JavaScript library.

That's my list. What did I miss?

It's still a conference, too, and although I never did recap last year's conference like I wanted to, I did collect a bunch of posts, photos, and videos on Gimme Bar. Also, Nate Bolt and Captain & the Fox collaborated on a really cool video that captures the spirit of it. I love it. Check it out:

If you were there last year, you might like to know that Joel Rose launched New Classrooms, Tony Fadell launched Nest, and Todd Park was named the new CTO of the United States. Pretty cool stuff.

We've settled on the dates for this year's conference. October 10th, 11th, and 12th. We're planning some other events to take place the same week, so although we're keeping the conference just as small as last year, there are going to be other reasons to be in Brooklyn that week. We've also ordered some good weather, and we're gonna keep our fingers crossed all summer, so it should be a great time to be in Brooklyn. Really hope to see you there.

The big announcement today is something we're calling Summer Camp. It's our attempt to provide some early funding and guidance to designer-developer teams. For all the details, see Tina's blog post or the Summer Camp site. We've answered some frequently asked questions that haven't even been asked yet. Yeah.

This is a pretty big deal for us, and we've got a lot of people to thank. Thanks to MailChimp, Hoefler & Frere-Jones, Engine Yard, and Etsy for being so eager to support us. (If you're interested in sponsoring, please get in touch.) Thanks to Eli Rousso, FFFunction, and Nate Abele for helping us with the new site. Last but not least, thanks to our incredible advisors for their support and vote of confidence. And, of course, thanks to everyone who's attended Brooklyn Beta and helped make it something special. We really appreciate it.

• Codename: Svbtle by Dustin Curtis
• Codename: Obtvse

Before I make my small point, let me give you the quick synopsis. Briefly, Dustin Curtis made his own blogging platform, opened it up to a few friends, and blogged about it. Someone else submitted it to Hacker News, and that's where the story takes a turn.

The Hacker News community quickly attacked Dustin's persona (he describes himself as a superhero) and the exclusivity of his blogging platform. I don't have a strong opinion about these criticisms, but I do believe them to be knee-jerk reactions based upon the false premise that Dustin was seeking the amount of attention he received.

This is what I object to.

Dustin made something and blogged about it. There's nothing wrong with that, and as someone who loves blogs, it's exactly what I want people like Dustin to do. The only difference is that someone submitted his post to Hacker News, and it got a lot of attention. The mistake the Hacker News community routinely makes is to assume the author of whatever they read is making a big deal about something.

As I've said before, I really like the way Trent describes blogs:

There's something sacred about reading a blog post on someone else's site. It's like visiting a friend's house for a quick meal 'round the breakfast table. It's personal — you're in their space, and the environment is uniquely suited for idea exchange and uninterrupted conversation. In many ways, we should be treating our blogs like our breakfast tables. Be welcoming & gracious when you host, and kind & respectful when visiting.

No matter how popular someone's blog is, or how popular a particular post is, it's still their blog. It's their breakfast table.

Let's all try to remember that the next time we pay them a visit.

As time passed, commitment waned. When I noticed it was almost that time of year again, I decided this was a tradition worth keeping, so here I am. I'm using this opportunity to renew my commitment to blog more, and hopefully this year's Ideas of March can provide an opportunity to let everyone know blogs are still alive and well. And appreciated.

If you'd like to participate, here's how:

• Write a post called Ideas of March.
• Write about why you like blogs.
• If you don't already blog regularly, pledge to blog more the rest of the month.
• Share your thoughts on Twitter with the #ideasofmarch hashtag.

I hope you'll join us, and if you do, please leave a comment. (Comments are great, too!)

A GitHub user exploited a security vulnerability in the public key update form in order to add his public key to the rails organization. He was then able to push a new file to the project as a demonstration of this vulnerability.

As soon as we detected the attack we expunged the unauthorized key and suspended the user.

My confidence in the clarity of GitHub's side of the story dissipated when I read one of the comments:

You didn't really "detect" anything. You were informed. It also wasn't an attack.

Not only did the "attacker" not do any actual damage, but he was continually ignored.

The "attacker" in question is Egor Homakov (his account has been reinstated), and he did in fact disclose the vulnerability a few days before he demonstrated it. There are a few facts worth noting up front:

• This was not a public key security vulnerability as the title of GitHub's post suggests.
• Egor is not a native English speaker, which might have made the potential impact of his discovery difficult to appreciate.
• He was not actually ignored, but he was pretty firmly dismissed (citing a prior discussion).

Telling someone they're wrong only fuels their desire to prove they're right. It's not a huge surprise that Egor's next step was to demonstrate the vulnerability.

I'd like to explain the vulnerability, but rather than show you any code, I want you to understand the nuts and bolts, because it's extraordinarily simple. If you have a GitHub account, you can manage your SSH keys. The form to add a new key looks something like this (edited for clarity):

<form method="post" action="/account/public_keys">
  <input type="hidden" value="412e11d5317627e48a4b0615c84b9a8f" name="authenticity_token" />
  <dl>
    <dt>Title</dt>
    <dd><input type="text" name="public_key[title]" /></dd>
    <dt>Key</dt>
    <dd><textarea name="public_key[key]" /></dd>
  </dl>
  <input type="submit">Add key</input>
</form>

All Egor did was modify his own form to add the following:

<input type="hidden" name="public_key[user_id]" value="4223" />

The user_id of the Rails project is 4223, so that's why he chose it. (He believes this is a Rails issue, and it's hard to argue that.) By sending along this user_id, his public key was added to another account. Yikes!

For those of you more familiar with PHP, imagine a feature like register_globals, but instead of injecting arbitrary form data into the global namespace, it injects arbitrary form data into the database. It might as well be called opt-in SQL injection, but even that's being too generous, because this is much easier to exploit than an SQL injection vulnerability.

Egor points out that this vulnerability is unique to Rails:

Only Rails app have this kind of bug.

Wanting to better understand why Rails refuses to fix this, I looked into mass assignment, the feature in question, and found a post from last year:

If you're using Rails and you want to be secure, you should be protecting against mass assignment. Basically, without declaring attr_accessible or attr_protected, malicious users can set any column value in your database, including foreign keys and secure data.

While it's unfair to expect Rails to prevent mistakes, this does seem like a clear case where it promotes insecurity. As one person commented:

Rails is all about conventions. Broken by default is not a good convention.

Yehuda Katz has proposed a solution that people seem to like. Here's hoping this event can help raise the bar for what's expected of a framework. When Zend Framework was first announced, I made a wishlist, because I think frameworks are perfectly suited to help developers write more secure code. Rails is no exception.

If you're interested in reading more about this, here are some links:

Mass assignment vulnerability - how to force dev. define attr_accesible?

The GitHub issue where Egor first discloses the vulnerability.

wow how come I commit in master? O_o

Egor's commit to Rails, demonstrating the vulnerability.

Responsible Disclosure Policy

GitHub's followup post that mentions their new responsible diclosure policy.

"Egor, stop hacking GH"

Egor's original post, describing vaguely what he has been able to do and citing the fact that he feels ignored.

i'm disappoint, github

Egor's second post, where he proclaims his love for GitHub and disappointment with their response, suspending his account.

How-To

Egor's final post, revealing the details of the exploit.

Comment by Max Bernstein

References an email conversation with Egor, where Egor claims that he emailed GitHub about the vulnerability and received no response.

How Homakov hacked GitHub & the line of code that could have prevented it

Gist from Peter Nixey that explains a single line of code that can prevent this vulnerability in your own Rails apps.

My quick fix is to use Twitter instead, but their hashbang URLs make it difficult to link directly to anything. Thankfully, if you want to search for tweets that mention something simple like brooklynbeta, you can use an ordinary URL like this:

http://twitter.com/search/brooklynbeta

No hashbang. It just works. Nice! Maybe this will be easy after all. Let's try a search for a URL:

http://twitter.com/search/http://twitter.com/

Account suspended? That's weird. While this error message isn't very helpful (maybe @search is the account that was suspended), the fault in this case is ours. We're using a query that has special characters, but we didn't bother to URL encode it. Our bad. Let's try that again:

http://twitter.com/search/http%3A%2F%2Ftwitter.com%2F

The page doesn't exist? But, we're doing the right thing now! Okay, fine, maybe we have to use the hashbang URL after all:

http://twitter.com/#!/search/http%3A%2F%2Ftwitter.com%2F

Hooray! Well, almost. If this works for you, I recommend going to your Twitter settings and checking the box to always use HTTPS. Once you've done this, you'll be told the page doesn't exist. It seems that Twitter is decoding the query when it redirects. Maybe we can just URL encode it twice to compensate for Twitter's decoding?

http://twitter.com/#!/search/http%253A%252F%252Ftwitter.com%252F

Hooray! But wait, what if we don't check the box to always use HTTPS? We won't get redirected, so Twitter won't decode our query. We'll actually be searching for http%3A%2F%2Ftwitter.com%2F instead of http://twitter.com/. What can we do? We can do this:

https://twitter.com/#!/search/http%3A%2F%2Ftwitter.com%2F

Because Twitter doesn't redirect HTTPS to HTTP, this avoids the redirect, regardless of the user's settings. Hooray?

There is a lesson here. URLs are underrated. Making it extremely easy and obvious for users to link to your content should be a priority. Let's try our best to remember this, even when it seems difficult to push the Web forward without abandoning its past.