I’m not a social networking fan, anyway, and to break my GMail, my primary email account, with something as stupid and useless as Buzz; I’m irritated. I usually wake up to 20 or more emails in my Inbox first thing in the morning. Today, I had one. Yes, one. I’ve sent numerous messages out today and I don’t know if they’re swirling about in some mail queue or if they’ve reached their destinations. Thanks Buzz. Thanks a lot.

I’m not sure that Google’s tech people realized how much bandwidth a service like this uses. It’s a lot. Just ask Twitter. It’s especially bandwidth hungry because, unlike Twitter, Buzz doesn’t limit you to 140 characters.

The insinuation that Buzz is responsible for his low email count this morning is utterly ridiculous. Does he think that Buzz has created some magical black hole in Teh Google’s intarwebz that’s sucking up his email?

Also, the whole “bandwidth” thing is beyond stupid. Yeah, I’m sure Google’s tech people (the folks behind Youtube) don’t know much about bandwidth.

“Hey man, I know you really like Foursquare, but you should check out this new site called Please Rob Me. Foursquare is actually really dangerous, cuz now it’s easy for robbers to know when you’re not at your house!”

I’m a Foursquare user, and I’ve heard variations of this from over a dozen of my friends in the past 24 hours. For the record, I think “Please Rob Me” is a really funny and creative idea, and I love that they made it. However, anyone who is legitimately giving privacy/security advice over this is being ridiculous.

First of all, most people are out of the house from 9am to 5pm. Robbers know this, and Foursquare checkins don’t change it.

Second, there’s absolutely zero indication of whether or not anyone else is home, or how soon you’ll be getting back. These are much more crucial pieces of knowledge than “a single person was not in his house at this time”.

Last, and most important, a superior technology has existed for decades: the doorbell. Run around a neighborhood ringing doorbells of houses that look like they might be vacated, and break into the ones that no one answers.

“Oh but people don’t answer their doorbell every time, so a robber might break into an occupied house!”

Right. Just like people don’t have to actually be at a place to check into it on Foursquare, and like how checking in on Foursquare doesn’t mean no one else is home. There are potential false positives with both methods (and if there weren’t, people would be getting robbed a lot more). The point is, breaking in based on doorbell-ringing is much less dangerous than doing it based on Foursquare checkins, as it’s reasonably likely that no one is home if no one answers the doorbell

In reality, privacy via anonymity has always been a pretty shaky concept. Yes, checking into Foursquare does give robbers one more tool to make their job easier, but in the face of much better tools (like the doorbell), it’s negligible. If you chose to be a Foursquare user in the first place, Please Rob Me should have no impact on your decision.

It’s not about “do more things,” it’s about “do very few things better.”

That’s why Apple wins.

My wife asked about the iPad last night (she owns a netbook right now) and now she’s drooling over one. Why? It doesn’t have “files.” It doesn’t have “windows.” She won’t have to worry about “flash drives.” And so on. She was so excited about all the things it didn’t have (and that she therefore didn’t have to worry about) that she was disappointed when I told her they weren’t in the Apple Store in Manhattan yet.

Meanwhile, the geeks are running around blasting Apple products for all the things they “don’t have” and recommending complex alternatives.

That’s why Apple is making $$$ these days. Because they’re removing 60 percent of the features and making the remaining 40 percent configuration free and so polished they make your eyes hurt.

I said similar things to people who were upset about the lack of multitasking, but this guy really hits the nail on the head.

I think too many people wanted another iPhone launch. The iPhone, if you think about it, was actually an aberration as far as Apple products go; the iPhone did more than most phones (though at that point, smartphones were less popular in general), and somehow still managed to do almost everything really well. Compare this to Apple’s launch of the iPod. The iconic response from geeks:

No wireless. Less space than a nomad. Lame.

We all know how that one turned out.

The fact of the matter is, aside from the iPhone, Apple has always released products that do less, and do it better. Us geeks may be offended by the “do less” part, but the average consumer loves it, and that’s why Apple will continue to launch into controversy and leave geeks looking foolish a couple years later.

What is attr_accessible?

In Ruby on Rails, attr_accessible allows you to specify which attributes of a model can be altered via mass-assignment (most notably by update_attributes(attrs) and new(attrs)). Any attribute names you pass as parameters will be alterable via mass-assignment, and all others won’t be.

How does mass-assignment work normally?

By default, mass-assignment methods accept a hash of attribute values, each keyed by their associated attribute’s name. If I ran the following code:

User.new({ :name => 'Harry Potter', :email => 'hp@hp.com' })

A new instance of the User model would be created, and the name and email attributes would be set accordingly. It can also be used to alter related models. For example:

User.new({
  :name => 'Albus Dumbledore',
  :is_teacher => true,
  :course_ids => [1, 2, 3] })

In addition to creating a user with the appropriate attributes, this will update the specified courses to be owned by this user(assuming a user has_many courses in our app).

How can this be abused?

Very easily. What if someone did this:

User.new({ :name => 'Draco Malfoy', :is_teacher => true })

This Draco Malfoy fellow may not actually be a teacher, but the system is none the wiser. Of course, the developer would never code this; in a real Rails app, the code is going to look like this:

User.new(params[:user])

The elements in params[:user] are taken from the POST/GET/PUT data passed along when the action was run. They’re thrown blindly into the mass-assignment, and any attributes whose names match the keys will be set.

“So what’s the big deal? Just don’t include an ‘is_teacher’ field in the web form, and the param won’t be there.” This is true for innocent users, but the malicious ones (and Draco Malfoy is definitely a malicious one) have an easy way around this. A web form is just a way to make it easy for users to pass data to your app. There are other ways. For example, if I wanted to register for the app via the command line instead of a browser, I could do it like this:

curl -d "user[name]=Harry Potter&user[email]=hp@hp.com" \
http://myapp.com/users/

This sends a request to http://myapp.com/users/ and passes data in the exact format it would’ve appeared if I’d filled out a web form that asked for a name and email address. However, I could also do this:

curl -d \
"user[name]=Draco Malfoy&user[email]=m@hp.com&user[is_teacher]=1" \
http://myapp.com/users/

Since is_teacher is an attribute name in my User model, and mass-assignment methods blindly accept whatever attributes they see, Draco Malfoy has just set himself a teacher.

Even worse, I could use this to grab courses that may not be mine.

curl -d \
"user[name]=Draco Malfoy&user[course_ids]=1&user[course_ids]=2" \
http://myapp.com/users/

Draco Malfoy has now taken courses 1 and 2 away from whoever they originally belonged to (Dumbledore, if my memory serves me) and given them to himself.

How can we prevent this?

There are a few obvious but clumsy ways. We could skip mass assignment, setting each individual attribute in our controller, but this will introduce a lot of duplicate and unnecessary code. We could explicitly pull unwanted parameters out:

params.delete(:is_teacher)
params.delete(:course_ids)

This also introduces a lot of duplicate code. If we ever add new columns that we want to restrict, or decide we want to unrestrict a column, we’re going to have to go through the create and update actions, and any others that perform mass assignment.

We could factor these out into some sort of sanitize_params method on each model. This is a better solution, but you still have to call it in every action that alters the data. It’s definitely not as good as the built-in one: attr_accessible. We can add this to the top of the User model:

attr_accessible :name, :email

This white-lists name and email; these two attributes will be accepted from a mass-assignment method, while all others will be ignored. This is by far the safest way to do it; only attributes you’ve explicitly allowed (which hopefully means you’ve thought carefully about them) can be set by mass-assignment. This way, if some intern comes along and adds a bunch of dangerous columns or relations (payment_accepted or horcruxes, for example), no one has to think about updating the sanitize methods.

What does this not do?

I saw one person say “Why would I put anything in attr_accessible? Why would I want any of my attributes to be hackable?”

Make no mistake: attr_accessible is no substitution for proper access control. If all users have write access to all other users, attr_accessible will let one user change another’s name attribute if it’s specified. Regular authentication and access control must be used to prevent users from writing to model instances that they shouldn’t be able to write to. Once this is done correctly, attr_accessible can be used to prevent a malicious user from altering data of her own that she shouldn’t be able to alter.

To be more clear, it could be considered “hacking” if a user were able to change everyone’s name to “Voldemort”. attr_accessible can’t prevent this; you need to do proper authentication with something like Authlogic. Once you’ve set your controllers up to prevent a user from even attempting to change another user’s data, you’ve prevented this “hack”.

If the user tries to change his own name to “Voldemort”, that’s totally fine. We don’t care if he does it via the web app, curl, or anything else; users are allowed to change their own name. Including :name in attr_accessible isn’t making it “hackable”, because it’s an attribute that users should be able to change.

If the user tries to change his is_teacher attribute from false to true, that’s also considered “hacking”. We don’t want to let users do this, so we exclude :is_teacher from attr_accessible to prevent it.

Are attributes excluded from attr_accessible immutable?

No. They can still be altered, just not via mass-assignment. If I exclude is_teacher from attr_accessible, and I go:

hagrid = User.first(:conditions => { :name => 'Rubeus Hagrid' })
hagrid.is_teacher = true
hagrid.save

That will work just fine. The difference is, it forces you to set the attribute explicitly, so there’s no potential of accidentally setting an attribute unexpectedly passed to mass-assignment. This way, I can allow my non-dangerous attributes to be set via mass-assignment with attr_accessible, then explicitly provide or deny control over dangerous attributes in other actions.

Eventually, I was able to piece it together after digging through the depths of the Prototype API documentation. It’s actually very simple:

document.observe('dom:loaded', function(){
	// do yo thang...
});

Wrap whatever you’re doing with that, and it won’t be run until the document is loaded.

I’m running Ruby 1.9 and Ruby on Rails 2.3.3 on Snow Leopard. I’ve been trying to install plugins (specifically, Authlogic and Carmen) for a couple days now using the following two commands (as taken from the main github pages):

script/plugin install git://github.com/binarylogic/authlogic.git
script/plugin install git://github.com/jim/carmen.git

In return, I received the following errors:

Plugin not found: ["git://github.com/binarylogic/authlogic.git"]
Plugin not found: ["git://github.com/jim/carmen.git"]

After a lot of poking around, it turns out you need to make two changes in order for this to work on Rails 2.3 or higher: change the git:// at the beginning of each URL to http://, and add a trailing slash to the end of each URL. So instead, run these:

script/plugin install http://github.com/binarylogic/authlogic.git/
script/plugin install http://github.com/jim/carmen.git/

They both worked perfectly for me, so hopefully they’ll work for you. If not, leave a comment and I’ll try to help.

Downloading and unpacking

Go to http://erlang.org/download.html and download the Source for the newest version (when I was writing this, that was R13B03. After downloading, extract it to somewhere that’s convenient to get to with the Terminal.

Configure

Open the Terminal and cd into the directory you extracted Erlang to (mine was /Users/jake/src/otp_src_R13B03 . Then run the following command:

./configure \
--prefix=/usr/local/ \
--enable-smp-support \
--enable-threads \
--enable-darwin-64bit

Note: You will probably get three errors. Read about them in the Configuration Errors section coming up.

The first three configure options are the defaults according to the README. However, I’ve had experiences where supposed defaults aren’t really the defaults when compiled on OS X, so I don’t like to take chances. --enable-darwin-64bit enables experimental support for the 64bit x86 Darwin binaries. This may not be necessary, but in general, 64-bit stuff has fewer problems on Snow Leopard, so I figured this was a good idea.

Configuration Errors

I got the following configuration errors:

jinterface    : No Java compiler found
wx            : Can not combine 64bits erlang with wxWidgets on
                MacOSX, wx will not be useable
documentation : fop is missing. The documentation can not be built.

These aren’t a problem. If you get any errors besides these, you’re in trouble. Leave a comment, and I’ll see if I can help.

Making and installing

These two commands shouldn’t give you any trouble:

make

And then, after make is done:

sudo make install

If you get any errors at either of these stages, leave a comment and I’ll try to help.

Making sure it works

Note: This canonical test is gratefully borrowed from erlang.org.

Put the following into a text file:

-module(test).
-export([fac/1]).

fac(0) -> 1;
fac(N) -> N * fac(N-1).

Save it as test.erl in a directory that’s easy to get to with the Terminal. Then, from the Terminal, cd into that directory and type erl (which, if everything worked right, should start the Erlang command-line interpreter). From the interpreter, run the following commands:

1> c(test).
{ok,test}
2> test:fac(20).
2432902008176640000
3> test:fac(40).
815915283247897734345611269596115894272000000000

Note: Lines starting with N> (where N is a number) are lines you should type (but just type the stuff coming after N>). The other lines represent output.

c(test). compiles test.erl (assuming it’s in the directory you cd‘ed into). test:fac(20). and test:fac(40). runs your factorial function.

So, that’s what worked for me. If anyone has any problems along the way, leave a comment and I’ll try to help.

So if you are trying to grow an entire industry as broadly as possible, open systems trump closed. And that is exactly what we are trying to do with the Internet. Our commitment to open systems is not altruistic. Rather it’s good business, since an open Internet creates a steady stream of innovations that attracts users and usage and grows the entire industry.

Generally, when a company professes its love for openness or charity or something similar, it does so with an airy “because we’re so nice” attitude, and must be read with a grain of salt. This paragraph (and the explanations that followed) were extremely refreshing. There are very few philanthropic claims in this letter; it explains exactly why Google sees value in openness, and how it helps their business.

I really enjoyed reading this piece, but it was this aspect that allowed it to be enjoyable. Without it, it’s just another fluff piece. With it, it becomes a powerful explanation of Google’s actions and intents.

I dreamed that I was sitting inside a table cell. I was looking up above and watching the empty cells above me get filled in one at a time. The last cell in a row would fill with some gibberish, and then the first cell in the next row would fill. The filling was getting closer and closer to me. Eventually, my cell was filled (I remember feeling very stressed at this point). I looked forward, and watched my neighbors fill. I looked under me, and watched the cells beneath me fill.

Suddenly, I was off on the sidelines, watching another table (that I was not a part of) get filled. Soon after this, the dream ended.

I can only conclude that, in my dream, I was a member of one of the cells in one of the tables of the Floyd-Warshall algorithm. Once the table I was in was filled, the algorithm incremented k and started on a new table.

I notice that I never saw a third table. Perhaps I was in table k == n - 1, and the table in front of me was the last one. Or perhaps this particular version of Floyd-Warshall was optimized (as it should be) to use O(|V^2|) space, and my table (and thus, my life) was deleted from memory after its successor was filled.

Or perhaps I just have really deep-rooted issues, and dreaming about being inside an algorithm is nature’s way of warning me that I should see someone.