Brooklyn Beta is becoming more than a conference.
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.
I just read a post by Daniel Howells about these two stories on Hacker News:
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.
I love blogs. A year ago today, I tried to start a sort of blogging revival. To my great surprise and delight, it kinda worked. For a while, I could find really interesting stuff to read every day by just browsing through my planet or #ideasofmarch on Twitter. It was great.
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!)
Hacker News exploded yesterday with news of GitHub being hacked. Wanting to know what all the fuss was about, I began with GitHub's side of the story:
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" />
<dd><input type="text" name="public_key[title]" /></dd>
<dd><textarea name="public_key[key]" /></dd>
<input type="submit">Add key</input>
authenticity_token is almost certainly an anti-CSRF token, so it doesn't complicate this exploit at all.
All Egor did was modify his own form to add the following:
<input type="hidden" name="public_key[user_id]" value="4223" />
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_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.
- 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.
Thanks to reader Steve Gricci, I have learned that BackTweets no longer exists, presumably because BackType was acquired by Twitter. (Regardless, why let the domain expire?) Until today, I have been using BackTweets for the "tweets" link at the top of each post, so anyone who clicked it recently was greeted by a parked Go Daddy page instead of seeing all tweets related to a particular post. Yikes!
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:
No hashbang. It just works. Nice! Maybe this will be easy after all. Let's try a search for a URL:
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:
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:
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?
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:
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.