

Weapons of Mass Assignment: Patio11 on Diaspora  - michael_dorfman
http://queue.acm.org/detail.cfm?id=1964843

======
patio11
Oh, I had forgotten about this. It is also getting published in Communications
of the ACM in Mayish I think. (Yep, here we go:
[http://cacm.acm.org/magazines/2011/5/107701-weapons-of-
mass-...](http://cacm.acm.org/magazines/2011/5/107701-weapons-of-mass-
assignment/fulltext) . You want that one, the formatting is better.)

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.

~~~
michael_dorfman
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.

~~~
patio11
Thanks.

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...

~~~
michael_dorfman
Now _there's_ a startup idea: citation arbitrage.

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.

~~~
sethg
Classic Usenet joke: a parody of the old-fashioned “MAKE MONEY FAST” email
chain letter.

<http://www.netfunny.com/rhf/jokes/94q1/maketenure.html>

------
dasil003
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.

------
losvedir
_"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!

~~~
carbon8
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.

~~~
patio11
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.

~~~
carbon8
Yeah, DJ is actually the only one I'm still using via a fork
([https://github.com/alphabetum/delayed_job/commit/9637a4418ad...](https://github.com/alphabetum/delayed_job/commit/9637a4418ad19a0e0cd96ae50811bf4d096bc054)).
I haven't had time to put the change in a topic branch and do a pull request.

------
tyler
"Since Rails is not threadsafe, typically several processes will run in
parallel on a machine, behind a threaded Web server such as Apache or nginx."

This is incorrect. Rails 3 (and 2.3) are thread-safe. They typically run in
multiple processes because of Ruby's GIL.

~~~
JonnieCache
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.

~~~
tyler
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.

~~~
erez
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.

------
sabat
FWIW, there's a gem for Rails that is intended to solve a related problem
(multitenant applications) -- could conceivably be used to assist with the
authorization problem as well. [http://blog.codecrate.com/2011/03/multitenant-
locking-down-y...](http://blog.codecrate.com/2011/03/multitenant-locking-down-
your-app-and.html)

------
misuba
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?

~~~
michaelchisari
Hello, there!

<http://opensource.appleseedproject.org>

------
berkes
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.

~~~
michael_dorfman
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.

~~~
erez
> 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.

------
mrchess
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.

~~~
michaelfairley
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.

