4 ms·

I don’t know if we have comparable life experience. I have seen more shitty code than high quality code in my life. It’s hard for me to empathize with anyone

I don’t know if we have comparable life experience. I have seen more shitty code than high quality code in my life. It’s hard for me to empathize with anyone who thinks startup code is going to generally meet some decent quality bar. People like Brian acton and Jan Korum exist, but they are the exception. If you always expect people to write good code, you will be fucking disappointed. The only solution that scales is having adequate speed bumps and guard rails that prevent people from pushing code till after it’s been properly tested. And just because it’s in a git log doesn’t mean it gets pushed to production. This article reminds me that journalists only make money when they squeeze your amygdala. Reading content from ars is the equivalent of an intellectual jump scare. Add 127.0.0.1 arstechnica.com to your resolv.conf file for mental health. Fuck off ars

deleted 6y ago
[deleted]
mrzimmerman 6y ago
Right, but the point is that either Gab had normal, reasonable safeguards in place (for the reasons you point out) and their CTO bypassed them creating a very serious security hole, or they didn’t have the safeguards in the first place meaning their internal processes are poorly set up and controlled. What’s important here is that the CTO is ultimately responsible for the failure either way. That’s the point of the article and it’s why the article is valid (even if you don’t like it for some reason): the engineering buck stops at the CTO, especially so if they personally create a bug that exfiltrates all of the company user data, regardless of how they managed to screw it up.
lawnchair_larry 6y ago
Brian Acton and Jan Koum weren’t exceptions either. WhatsApp had some hilariously bad vulnerabilities. Like no authentication on their APIs and trusting the client. https://www.mathyvanhoef.com/2012/05/whatsapp-considered-insecure.html https://www.mathyvanhoef.com/2012/05/whatsapp-considered-ins... https://www.mathyvanhoef.com/2012/07/whatsapp-follow-up-unauthenticated.html https://www.mathyvanhoef.com/2012/07/whatsapp-follow-up-unau...
- DaniloDias 6y ago
  Hah! Too great. Ok, so no good code in startups.
- rjzzleep 6y ago
  To be fair, Rails has a lot more baked in base security than erlang did. Yes Rails had it's fair share of vulnerabilities. I remember there was a major eval issue in some deserializer code, but things such as sql injections or using POST over query strings is just basic knowledge almost every mediocre+ rails dev knows. They picked erlang for their scalability, but as a result had to write a lot of other things from scratch. WhatsApp is still an interesting engineering case study.
  - quetzthecoatl 6y ago
    it's not a rails vulnerability though. This would happen irrespective of the language/framework if the developer decide to forego basic sanity checks. This would have been prevented with basic input validations (in any of the layers before it hit model, and model itself), or the organization did basic security testing.
    - rjzzleep 6y ago
      You miss the point. If you use rails provided primitives it absolutely wouldn't happen. So it's fair to categorize this as a rookie coding mistake. The author took code that had these security primitives baked in the framework and REMOVED them, replacing it with insecure custom sql, which in turn led to the vulnerability.

deleted 6y ago

[deleted]

mrzimmerman 6y ago

Right, but the point is that either Gab had normal, reasonable safeguards in place (for the reasons you point out) and their CTO bypassed them creating a very serious security hole, or they didn’t have the safeguards in the first place meaning their internal processes are poorly set up and controlled. What’s important here is that the CTO is ultimately responsible for the failure either way. That’s the point of the article and it’s why the article is valid (even if you don’t like it for some reason): the engineering buck stops at the CTO, especially so if they personally create a bug that exfiltrates all of the company user data, regardless of how they managed to screw it up.

lawnchair_larry 6y ago

Brian Acton and Jan Koum weren’t exceptions either. WhatsApp had some hilariously bad vulnerabilities. Like no authentication on their APIs and trusting the client. https://www.mathyvanhoef.com/2012/05/whatsapp-considered-insecure.html https://www.mathyvanhoef.com/2012/05/whatsapp-considered-ins... https://www.mathyvanhoef.com/2012/07/whatsapp-follow-up-unauthenticated.html https://www.mathyvanhoef.com/2012/07/whatsapp-follow-up-unau...

DaniloDias 6y ago
Hah! Too great. Ok, so no good code in startups.
rjzzleep 6y ago
To be fair, Rails has a lot more baked in base security than erlang did. Yes Rails had it's fair share of vulnerabilities. I remember there was a major eval issue in some deserializer code, but things such as sql injections or using POST over query strings is just basic knowledge almost every mediocre+ rails dev knows. They picked erlang for their scalability, but as a result had to write a lot of other things from scratch. WhatsApp is still an interesting engineering case study.
- quetzthecoatl 6y ago
  it's not a rails vulnerability though. This would happen irrespective of the language/framework if the developer decide to forego basic sanity checks. This would have been prevented with basic input validations (in any of the layers before it hit model, and model itself), or the organization did basic security testing.
  - rjzzleep 6y ago
    You miss the point. If you use rails provided primitives it absolutely wouldn't happen. So it's fair to categorize this as a rookie coding mistake. The author took code that had these security primitives baked in the framework and REMOVED them, replacing it with insecure custom sql, which in turn led to the vulnerability.