

37Signals "just says no" to feature request: "please fix that security flaw" - tptacek
http://www.matasano.com/log/1067/web-20-redux/

======
Harkins
I've gotten that "Soft No" from 37signals, too. I was reporting a bug in the
BaseCamp example API and was told that maybe we just had different views of
how the API should be designed. I guess I was the only one in the conversation
with the view that it should return data instead of raise exceptions and crap
out. I no longer use BaseCamp.

------
avner
I find 37signals pretty stubborn when it comes to listening to its users, in
general.

-just my 2 cents

~~~
jasonfried
We listen to everyone and 9 out of 10 things we add to our products start out
as customer requests. We encourage feedback everywhere we can and interact
with our customers as often as we can -- often by posting comments on their
own blogs.

But, we also get thousands of requests a year so we can't do everything
everyone wants. Many of these requests conflict with one another, and many of
them just aren't a good fit for our products (adding Gantt charts to Basecamp,
for example). The good ones, however, often make it into the products
eventually. Sometimes exactly as requested, sometimes in a different form, but
customer requests are almost always the seeds of improvement.

It is our job to be editors and museum curators. We have to decide what makes
it and what doesn't for the benefit of the overall product and the overall
customer base. No combination of yes or no is going to satisfy everyone, so we
have to work on behalf of the majority.

Every company with millions of users has to say no more than they say yes,
we're just honest and up front about it about it. We don't want to set false
expectations or promise things we won't be able to deliver.

While this policy may rub some people the wrong way, we think it's the right
policy. And seeing that 94%+ of our customers would recommend Basecamp to a
friend or colleague, I think we're on the right track.
<http://basecamphq.com/survey>

~~~
goodkarma
The issue here is not about adding new features, but fixing bugs and security
issues.

Perhaps the 94% are not tech savvy enough to identify these problems?

Incidentally, I've read that specific example of adding Gantt charts to
Basecamp before: [http://www.37signals.com/svn/posts/1050-ask-37signals-how-
do...](http://www.37signals.com/svn/posts/1050-ask-37signals-how-do-you-say-
no)

------
akd
Just post the vulnerability to a forum 14 days after notifying the company.

~~~
jrockway
14 days after? Just disclose the vulnerability to bugtraq and be done with it.
Whether the company follows up or not is up to them.

~~~
tptacek
So you think the right plan is to punish the end-users and hope the vendor
notices? Do you read Bugtraq? It's a mess.

This strategy works better. Several thousand people have already read Dave's
article. We don't have to worry at all about the "wrong people" getting
details and messing with other users. This seems like a win-win.

------
andreyf
Did he not mention the flaw, or did I miss it? If he didn't, I'd say this
article is linkbait.

The bug is probably something really trivial that affects a small portion of
users in an insignificant way. The secrecy about specifics on the author's
part seems to be just to spare him embarrassment at this point.

~~~
gizmo
I'm guessing it's this:

<http://forum.37signals.com/basecamp/forums/5/topics/3155>

Suppose we're both basecamp users. It may be possible for me to steal your
session by giving you a link to a shared calendar or something with malicious
javascript. Or I can steal the login cookie of one of the admins by luring
them to my website with a support request.

I don't think permitting XSS is a good idea in a shared environment.

~~~
andreyf
You can steal cookies with XSS?

~~~
gizmo
In some situations. See:

<http://jehiah.cz/archive/xss-stealing-cookies-101>

~~~
andreyf
document.cookie, wow... Guess you learn something new every day. For those
interested, this has a good explanation:

<http://www.quirksmode.org/js/cookies.html>

------
throttle
I'm gonna go against the grain on this one and call it karma whoring. Here's
the formula:

1) Pick a company that has been the source of recent controversy.

2) Find a silly security flaw in one of their products that you can make sound
serious with a bit of sensationalism. This should be easy to do, because most
web apps have a few silly security holes.

3) Inform the company, and when they inevitably assign the silly flaw a low
priority, write an inflammatory blog post and submit it to major news
aggregators (e.g. news.yc)

~~~
tptacek
I'm going to go exactly with the grain of all my previous comments here and
call you full of it.

Did you read the post? We reported this _over a year ago_. We notified them
_repeatedly_. We withheld the name of the vendor for over a year as a
courtesy. They started with a "soft no", and, when Dave checked in a few
months later, they simply ignored our email.

Also: 37Signals has nothing to do with the recent Ruby "controversy" (where by
controversy, you mean "someone found security vulnerabilities in it, and some
blogger freaked out about it"). 37Signals doesn't produce Ruby; an Open Source
team does.

The issue here is that one of 37Signals signature philosophies is "just say
no" and be true to your own vision of your product when users request things
you don't want to do. Fine. But there's a slippery slope to that logic, and
you need to be careful not to fall down it. Some requests that you don't want
to do, especially when they come from paying customers, can't be blown off.

------
swombat
Security flaws are bugs. They should be prioritised along with the rest.

~~~
tptacek
That's what 37Signals has done. They've simply put it at the bottom of their
list, behind adjusting the pixel alignment of their sidebars.

~~~
jrockway
And yet they're still making plenty of money. Security would be taken
seriously if users gave a damn. But they don't.

~~~
tptacek
Depends on who you're talking about. An XSS vulnerability in a web app will
get you shelved at a Fortune 500 company. When new apps get deployed on
customer DMZs, third party audits happen. When they find vulnerabilities, you
spin dot releases. On a typical 4/2 dev/qa dev team, in the _hopelessly
optimistic_ case where you can turn a QA'd dot release in 2 weeks, you just
lost $37,500.

------
tptacek
It's _really_ not a major flaw. But, I mean, come on.

------
goodkarma
Even if it is not a "major" bug, why has it taken more than a year to fix?
Unless 37signals does not consider it to be significant?

~~~
raganwald
"Unless 37signals does not consider it to be significant?"

That's the real disconnect here. It isn't that responding to secuity
vulnerabilities needs a unique process, it's that the author considers this
issue significant and 37Signals does not.

~~~
tptacek
I doubt --- kind of a lot, actually --- that any actual developer there even
saw our report.

[Edit] On second thought, this is a dumb thing to say, and I retract it. I
have no idea if anyone's seen it, which is itself a problem. If I was going to
assign a cause to this, it's that the cost of fixing this particular bug may
exceed the perceived risk of the vulnerability.

