4 ms·

> That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative

> That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative to point out a security issue. Something like, "Cool start, but might want to point out that it's not meant for production!" would be a lot better IMHO. Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". Not sure what the end goals of Zero are. I will say I thought it was pretty evident that this was not for production (if only to the sheer amount of "magic" inside) but maybe that's just me and it should have a disclaimer to that effect.

insulfrable 8y ago
Maybe security people are getting tired of inconsiderate developers that keep shipping bazillions of insecure packages all over mission critical applications. Devs need to change their culture. This behavior is actively harming end-users through repeated data breaches.
- joshstrange 8y ago
  Do you honestly think it is developer's "inconsiderate" behavior that the root cause or even a main factor in the "repeated data breaches"?
  - insulfrable 8y ago
    Partly yes. They certainly have a professional responsibility to write applications that resist well known attacks, such as directory traversal, xss, sqli, etc. This isn't new, and not knowing how to deal with it is like a builder not knowing how to safely stand up a wall.
Kalium 8y ago
> Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". That's a great idea! It should definitely be implemented. With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion. Again, your point is both completely valid and absolutely correct. Purpose and labeling should be clear enough that no person could possibly miss them.
- joshstrange 8y ago
  > With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion. I don't think I have a good answer. I'm currently serving a little over 6 million requests a month for a service I never advertised yet some non-zero number of developers copied code from stack overflow or wrote based on my github project to hit an endpoint that was just a demo. Since it was un-authenticated and I didn't notice the traffic until much later I have no good way to shut this down without pulling the rug out from under people. Eventually I will have to but since it's not costing my anything extra really I've left it. Now I put a warning on it when I noticed the traffic but that was 3 years and 2 million requests less per month ago so... I guess yes, we, as developers, should be better about putting warnings and the like on our projects but by the same (if not greater) token, people using existing code/services bear the responsibility to vet things they use. I don't know how to fix people to vet stuff better. Hell, I don't know how to make myself do that. That said you take risks every day, you risk your live when you get behind the wheel, you risk security holes when you don't vet code you use or build upon. I've weighed the risks of driving against the rewards and found the risk acceptable. For a lot of software I use I've made the same decision. I just don't have the time and energy to vet everything for myself and timelines and other pressures at work make it equally impossible there. At what point do you say "Ehh, it's secure enough below this point"? * npm library with 1000's of dependencies? * npm library with no dependencies * npm * nodejs * OS * Hardware I honestly don't know a consistent/standardized way to handle it.
  - Kalium 8y ago
    As you so correctly and wisely point out, we take all kinds of risks every day. It's an inherent part of life. Yet we also generally accept that things that can be done in a safer way should be when reasonably possible. At this point I'm leaning towards deprecating the idea that encouragement, positivity, and documentation will lead to developers making good decisions. As you've demonstrated, it's clearly insufficient, and I suspect your experience is an outlier but far from unique. Increasingly, I think we may have to consider measures to get it right the first time. And we have to be sure our peers do too, because we're all living in the same environment and context. Otherwise, sooner or later, someone who didn't read a warning label is going to try to build a PII-handling business on Zero Server (or similar) and it's going to be a dumpster fire. I would love a world where friendly encouragement, niceness, and documentation could scaleably do this. Sadly, it's perhaps possible that that world and this one could be slightly different.

insulfrable 8y ago

Maybe security people are getting tired of inconsiderate developers that keep shipping bazillions of insecure packages all over mission critical applications. Devs need to change their culture. This behavior is actively harming end-users through repeated data breaches.

joshstrange 8y ago
Do you honestly think it is developer's "inconsiderate" behavior that the root cause or even a main factor in the "repeated data breaches"?
- insulfrable 8y ago
  Partly yes. They certainly have a professional responsibility to write applications that resist well known attacks, such as directory traversal, xss, sqli, etc. This isn't new, and not knowing how to deal with it is like a builder not knowing how to safely stand up a wall.

Kalium 8y ago

> Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". That's a great idea! It should definitely be implemented. With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion. Again, your point is both completely valid and absolutely correct. Purpose and labeling should be clear enough that no person could possibly miss them.

joshstrange 8y ago
> With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion. I don't think I have a good answer. I'm currently serving a little over 6 million requests a month for a service I never advertised yet some non-zero number of developers copied code from stack overflow or wrote based on my github project to hit an endpoint that was just a demo. Since it was un-authenticated and I didn't notice the traffic until much later I have no good way to shut this down without pulling the rug out from under people. Eventually I will have to but since it's not costing my anything extra really I've left it. Now I put a warning on it when I noticed the traffic but that was 3 years and 2 million requests less per month ago so... I guess yes, we, as developers, should be better about putting warnings and the like on our projects but by the same (if not greater) token, people using existing code/services bear the responsibility to vet things they use. I don't know how to fix people to vet stuff better. Hell, I don't know how to make myself do that. That said you take risks every day, you risk your live when you get behind the wheel, you risk security holes when you don't vet code you use or build upon. I've weighed the risks of driving against the rewards and found the risk acceptable. For a lot of software I use I've made the same decision. I just don't have the time and energy to vet everything for myself and timelines and other pressures at work make it equally impossible there. At what point do you say "Ehh, it's secure enough below this point"? * npm library with 1000's of dependencies? * npm library with no dependencies * npm * nodejs * OS * Hardware I honestly don't know a consistent/standardized way to handle it.
- Kalium 8y ago
  As you so correctly and wisely point out, we take all kinds of risks every day. It's an inherent part of life. Yet we also generally accept that things that can be done in a safer way should be when reasonably possible. At this point I'm leaning towards deprecating the idea that encouragement, positivity, and documentation will lead to developers making good decisions. As you've demonstrated, it's clearly insufficient, and I suspect your experience is an outlier but far from unique. Increasingly, I think we may have to consider measures to get it right the first time. And we have to be sure our peers do too, because we're all living in the same environment and context. Otherwise, sooner or later, someone who didn't read a warning label is going to try to build a PII-handling business on Zero Server (or similar) and it's going to be a dumpster fire. I would love a world where friendly encouragement, niceness, and documentation could scaleably do this. Sadly, it's perhaps possible that that world and this one could be slightly different.