<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>elihu</author><text>Think about web browsers.  We&amp;#x27;re not really that worried about people running malicious web browsers.  It&amp;#x27;s potentially a problem, but as long as people know not to run software that some random spammer sends them in an email then it&amp;#x27;s easy to avoid.&lt;p&gt;On the other hand what computer security people worry about a lot is that the web browsers made by reputable organizations and teams of competent programmers nevertheless contain security flaws that can be exploited by a maliciously-written website to cause those browsers to do unexpected and dangerous things.&lt;p&gt;Many of those security flaws in otherwise well-regarded software are due to memory management errors that just aren&amp;#x27;t present in safer languages, or they&amp;#x27;re due to type errors that wouldn&amp;#x27;t be present in more type-safe languages.&lt;p&gt;There are some implementation bugs that could be present in any language no matter how many safety features it has, but many security bugs aren&amp;#x27;t due to, say, an incorrectly specified algorithm, they&amp;#x27;re due to the programmer asking the computer to do something that&amp;#x27;s literally nonsense, like asking for the fourth element of a list that only has three elements, or recording that someone&amp;#x27;s age is apricot.  Programming languages with powerful nonsense filters can remove a lot of those kinds of security bugs.  (And powerful type systems often give programmers mechanisms to tell the compiler more about the program so that it can filter out more kinds of nonsense than it would otherwise.)</text><parent_chain><item><author>bee_rider</author><text>But the presence of a better language to write innocent programs in wouldn&amp;#x27;t protect the innocent programs from malicious programs written in C and assembly...</text></item><item><author>woodruffw</author><text>They&amp;#x27;re aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!</text></item><item><author>bee_rider</author><text>You are the security engineer, so you certainly know better than me, but aren&amp;#x27;t those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn&amp;#x27;t allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?</text></item><item><author>clysm</author><text>&amp;gt; any safety checks put into the competing language will have a runtime cost, which often is unacceptable.&lt;p&gt;And what is the runtime cost of all the mitigations put in place &lt;i&gt;because we don&amp;#x27;t use a memory safe language&lt;/i&gt;? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level mitigations.&lt;p&gt;I suppose I should thank the C language for job security as a security engineer.</text></item></parent_chain></comment><story><title>The case against a C alternative</title><url>https://c3.handmade.network/blog/p/8486-the_case_against_a_c_alternative</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>woodruffw</author><text>I don&amp;#x27;t understand this response. Nothing really stops that, regardless of implementation language. It&amp;#x27;s why we have an entire bodged and mostly ineffective AV industry, as well as a slightly less bodged and partially effective endpoint monitoring&amp;#x2F;detection industry.&lt;p&gt;Runtime mitigations exist to mitigate &lt;i&gt;some&lt;/i&gt; of the latent risk associated with programming in unsafe programming languages. We use them because they&amp;#x27;re our best known approach to continuing to use those languages without letting script kiddies own us like it&amp;#x27;s 1993.</text><parent_chain><item><author>bee_rider</author><text>But the presence of a better language to write innocent programs in wouldn&amp;#x27;t protect the innocent programs from malicious programs written in C and assembly...</text></item><item><author>woodruffw</author><text>They&amp;#x27;re aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!</text></item><item><author>bee_rider</author><text>You are the security engineer, so you certainly know better than me, but aren&amp;#x27;t those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn&amp;#x27;t allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?</text></item><item><author>clysm</author><text>&amp;gt; any safety checks put into the competing language will have a runtime cost, which often is unacceptable.&lt;p&gt;And what is the runtime cost of all the mitigations put in place &lt;i&gt;because we don&amp;#x27;t use a memory safe language&lt;/i&gt;? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level mitigations.&lt;p&gt;I suppose I should thank the C language for job security as a security engineer.</text></item></parent_chain></comment><story><title>The case against a C alternative</title><url>https://c3.handmade.network/blog/p/8486-the_case_against_a_c_alternative</url></story>