I was honestly surprised when I got asked to edit this for the ACM, but couldn't say no to Achievement Unlocked: Journal Publication. Content-wise it is virtually identical to the blog post I did after Diaspora patched the issues I reported to them. The tone got radically altered from my Internet voice to my academic voice, which is rather rusty, so I apologize if it reads poorly.
Thanks for the CACM link; that's how I found it, actually, but I'm a subscriber so I only had the "subscribers-only" link (which is very nicely formatted.)
In any event: congratulations on the CACM publication-- that's a quite impressive academic credential, if those things matter to you.
It scratches one thing off the bucket list, and many members of my family who expected me to go get a PhD will be tickled by it. In terms of actual utility, it is highly unlikely I'll ever have a CV again, but it makes a nice thing to have for e.g. visa applications. "Published in a prestigious academic journal" matters more to the Ministry of Justice than "has a whole lot of HN karma."
Now all I need is to find someone to cite it in Japanese...
Personally, there are a lot of things I value more highly than their actual utility, but then again, I'm fairly close to entering a PhD program in Buddhist Philosophy, so I'm pretty well acquainted with the notion.
Good article, the only place I disagree is with this:
> * For example, Rails could default to mass assignment being available in development environments, but disabled in production environments (which are, typically, the ones that are accessible by malicious users).*
That is a really bad idea. All it would do is create broken code in production that could not be debugged in development mode.
"This is easy to do: simply call ActiveRecord::Base.attr_accessible(nil) in an initializer, and all Rails models will automatically have mass assignment disabled until they have it explicitly enabled by attr_accessible."
I may be way wrong here, but: didn't this particular suggestion come from an HN comment? I seem to remember when there was a flurry of Diaspora articles, that a comment mentioned this as a good example of Ruby monkey patching, and one of my "heroes" (so, patio11, or maybe tpatacek?) acknowledged it as a simple and beautiful solution.
Hmm... off to see if I can find what I'm thinking of.
edit: oh, ha! Found the link: http://news.ycombinator.com/item?id=1718422 . I was sort of right, sort of wrong. It was an HN comment, but it was actually patio11's own comment to tpatacek, who thought it was a great idea!
The approach has been around for a years (see my comment in that thread, for example), but very few of us use it.
The thing you'll run into with that approach is that no authors of gems and plugins that include AR models declare attributes as accessible, effectively assuming that mass assignment is enabled and resulting in the gem/plugin not saving properly. I've had to fork and submit patches for every hugely popular gem with AR models I've used, so it appears practically no one else follows this approach in production apps.
I strongly suspect that leaving all attributes mass assignable on all models other than generated user models is extremely common in Rails apps and it's very likely that this vulnerability is ubiquitous.
Yep, this indeed caused some "fun" issues with Appointment Reminder. Off the top of my head, it broke DelayedJob and one other gem that I am forgetting.
Edited to add: Now I remember. The second gem was actually A/Bingo (a plugin). I fixed this back in January.
It has a threadsafe mode. It is disabled by default and to my knowledge hardly anyone uses it because you would need to audit all your dependencies to make sure they were threadsafe as well.
So, what the "thread-safe mode" does is enable threads in Rails. (i.e. one thread per request.) To my knowledge, it does not switch out thread-unsafe code for thread-safe code.
Moreover, it's irrelevant. As I mentioned, this is unrelated to why Rails apps are typically run as multiple processes.
As with Twitter, I don't think Rails, nor Ruby, is the issue. Whatever you do with a framework, or a language, is mostly your fault. Ruby on Rails can only be as good as the people use it are, and while I realise the Rails aggressive marketing gives people the impression that RoR is a bullet-proof solution, it isn't, and shouldn't be blamed if a developer doesn't understand the tools he's using.
We all seem very happy to complain about Diaspora, but where are the people patching it and/or offering a replacement project with the same, highly desired goals?
This is an old article. Most issues were already fixed. Many issues, bytheway, were known and simply TODO's.
Wether it is a good idea to publish an alpha with demo that contains many known -TODO- security holes and -issues is another idea. But it is unfair to start calling Diaspora "a failure" or "an amateurish piece of xxx" (not my words, but heard them said after this article) because of not-yet-implemented security features (such as authorisation).
By now, the entire Diaspora is/was rewritten in My/PostgreSQL, most of mentioned issues are already dealt with, or are under contstruction.
I don't think it's unfair at all. Security and privacy were, after all, Diaspora's raison d'etre. And, as we all know (and Diaspora demonstrated, yet again) security is not something that can be bolted on afterwards, but has to be baked in from the start; otherwise you are looking at a rewrite.
"Amateurish failure" pretty much nails it, if you ask me, and if the Diaspora guys were working for me, I'd be showing them the door as quickly as I could manage it. That may sound harsh, but it's the voice of hard-earned experience.
> Security and privacy were, after all, Diaspora's raison d'etre.
The irony of its all is that Facebook's privacy issues has nothing to do with open/closed source. They can open they're entire source-tree tomorrow, it wouldn't make them more privacy-oriented than now. It's not how they collect the information or how they store it, but what they do with it and with whom they share it.
>"Amateurish failure" pretty much nails it
I think part of the problem here is, as much as those guys have good intention, the whole affair was ill-handled from the start. From the get-go, asking for money before showing any effort made me sceptical of the whole affair. The amount of exposure and money they got, without anything even resembling code, or implementation details was absurd.
And then, what they initially came up with could've been done by a few software devs working on their free time, and was riddled by security issues. My advice to those guys is to use the money and hire some good programmers, which is what most startup guys do.
None of the problems he outlined were a result of getting Diaspora out the door faster, but simply basic ignorance of security issues. attr_accessible, adding a current_user. to db queries and so on doesn't take any time at all, and should be in muscle memory for any seasoned Rails developer.
If they can't deal with beginner level stuff, how well do you think they will do with much harder problems like XSS?
Edit: Actually I really want to drive this point home: you wouldn't write a TODO for any of these things because it would take you as long to write the TODO as it would take to fix them.
It was not my impression, from speaking with the developers, that I was wasting their time by informing them of things they already knew.
Regardless, the purpose of publishing this isn't to grind Diaspora's nose in it. It is to help someone -- profs, students, or (scarily) someone who gets paid for this -- avoid shipping software in this state in the future.
The initial release contained every amateurish security hole in the book. The errors were the sort of one might see in a WordPress plugin written by someone with three months PHP experience. I wouldn't call those a 'TODO' since I can't even write a basic PHP or Django page without doing the basics like sanitizing going towards the database or making sure the user owns a photo before deleting it. The fact that the Diaspora team didn't do any of that shows that they had precious little experience. Not sure why anyone would want to build upon something written by absolute amateurs - in the past, that is how the world ended up with WordPress and PHP.
One thing that always bugged me about the criticism of the Diaspora release was that people criticize it like it is production software when they clearly stated it was a "pre-alpha developer preview". Who cares if they didn't have security checks? They could have been just waiting till later to add them all in.
I know when I build I like getting the scaffold/mvp up as quickly as possible ignoring security because hey, this thing isn't out in the wild, and do my due diligence on security after I am happy with the prototype.
It was getting deployed as a production service in many places, so it was effectively "out in the wild". Labeling something a "pre-alpha developer preview" does not remove the responsibility of protecting users' data.
I think of this as similar to error handling/reporting. If you don't build in a mechanism from the beginning, it's going to be so much more difficult to do it later.
I was honestly surprised when I got asked to edit this for the ACM, but couldn't say no to Achievement Unlocked: Journal Publication. Content-wise it is virtually identical to the blog post I did after Diaspora patched the issues I reported to them. The tone got radically altered from my Internet voice to my academic voice, which is rather rusty, so I apologize if it reads poorly.