[phillmv]

>The benefits Clojure brings to the table more than make up for the work in either case.

No one's saying "stop using clojure". The argument here is "build a clojure framework lots of people use".

>There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand.

You do this all the time. I mean, I understand on a high level what my computer does but I can't describe to you the exact tree balancing algorithm my filesystem uses, how my CPU performs cache invalidation and branch prediction or even how exactly the JVM works.

Computers are too complex to not rely on underlying concepts you or your team doesn't understand.

The point is, within just the context of a web developer developing a web application there is too much stuff to know to always get it right. We need to reduce the number of things people have to think about, or else we'll always miss something.

[whyme]

> The argument here is "build a clojure framework lots of people use.

The argument I am addressing is that people are deploying products with poor security because a great, all encompassing, framework does not exist. There's no excuse for doing that.

This is not about having to understand cryptography, it's about knowing when and where you need to use it and making sure it's included when you do. The issues outlined in the video are trivial.

[phillmv]

The excuse is precisely that there isn't a great, all encompassing framework.

Setting up a scenario where everyone has to get everything right all of the time is setting everyone up for a lot of heartbreak.

Having bad password management and opening everyone up to CSRF and XSS is not "trivial". They're gotchas, and looking out for gotchas is a waste of everyone's time.

[whyme]

When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. That goes for using a bad framework or lack thereof.

As I said, I'm all for having a great framework, but I would not excuse the mistakes being made here, and I'm simply saying that I believe that my products and my knowledge level benefited by not having one.

> Having bad password management and opening everyone up to CSRF and XSS is not "trivial".

I'm not suggesting everyone should need to be aware of these issues, I'm saying someone on your team should be. And if you're a team of one, be prepared to make mistakes (which will not be limited to the issues outlined here).

[phillmv]

>When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me.

Well, you should! These are mind numbing details that are best taken care of by other people. I am too concerned with building a good product to want to spend too much time going over mind numbing details.

The argument from "I become a more well rounded developer" is valid, but these should be things you learn once and then stop worrying about forever. There's a lot of magic in Rails, but it all goes away given enough time. Better abstractions are our bread and butter and we'll get nothing done if we continue to shy away from them.

[whyme]

As I said, I'm all for having a great framework.

[ryandrake]

Unfortunately, with security, you have to "get everything right all of the time" because the attacker only has to get their attack right once.

[phillmv]

I worded it unfortunately, but we're getting at the same thing.

What I mean to say is the easier it becomes for everyone to get everything right all of the time the more likely it is to occur.

Expecting everyone to individually know and understand every single gotcha is unrealistic compared to distributing the work load across a framework.