Hacker Newsnew | comments | show | ask | jobs | submitlogin

Brian, I'm on the receiving end of security@37signals.com and @rubyonrails.org. I read your post with great dismay, to put it mildly. You're understandably pissed: we whiffed on our response to you by changing venue to Rails security without keeping you in the loop.

This is my fault. I identified it as a Rails issue and requested that you forward your findings to the Rails security team so we could investigate in concert.

Craig here at 37s narrowed down a root fix with Michael, Rails' security ombudsman, who then enlisted Manfred's help to track down and repair the root cause. What you see today is the end result of those efforts. The security process worked, but you only saw the Rails arm of it. The apparent 37signals arm of it amounted to runaround. Completely not OK.

We now have a security-only email and PGP key at http://37signals.com/security. Next time, no runaround.

There are still a couple of issues Brian brought up you haven't addressed.

The main one being the hubris of the copy on your security page. Declaring users data to be uncompromisable then justifying this by listing mostly physical restrictions to the datacenter seems to ignore rather the larger security issues for web-based applications. A firewall and latest security patches do not make one immune.

His other peeve seems to be the perceived bullshit of your support team saying they replied to his initial complaint when it appears (at least to him) that they had not, then putting the blame for this on his spamfilters.


He addressed your second point, and your first point isn't reasonable. Product "security" pages don't need to read like SEC disclosures.

Compare their security page to:

* http://www.salesforce.com/company/security.jsp

* https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/Marketing/g...

* http://www.apple.com/macosx/security/ (heh)

* http://www.webex.com/pdf/wp_security_overview.pdf

* http://www.netsuite.com/portal/infrastructure/main.shtml

Don't ask 37s to meet a standard that nobody else meets. It's just muddying the real issue, which they're clearly trying to address.

This comment, btw, isn't about 37s. It's about the singularly bad advice that web startups should have a fully-transparent conservative "security" page that talks about cross-site scripting and CSRF attacks, when their competitors have pages about "state of the art firewall security". To normal people (ie, customers), the "state of the art firewall security" people sound like they know what they're doing.


I can assure you we're looking into this entire busted chain of communications. The way this was handled (by us) was completely unacceptable. I am not a happy man this morning.

We will make this right.



Second Google result for "apple security": http://www.apple.com/support/security/


Yes, and that's a good page. Now tell me how to navigate to it on the OS X site, and note how much security marketing fluff you'll see before you ever find it.

I don't even think Apple is a bad example of the form. I think it's entirely reasonable for them to market security on their main pages, and leave the researchers to find their support page on Google. There are tens of researchers, and millions of customers.

Apple has a lot of really smart people working in security research and software security. Some of them are friends of ours. And some of those people are frustrated with Apple for any number of reasons. But none of them --- in fact, nobody I know that works in software security --- is particularly upset about http://www.apple.com/macosx/security. It is what it is.


Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact