3 ms·

This essay reminds me of a great example from pg himself of being silenced for his views, his essay "Hijacking is Buffer Overflow" http://www.paulgraham.com/hi

This essay reminds me of a great example from pg himself of being silenced for his views, his essay "Hijacking is Buffer Overflow" http://www.paulgraham.com/hijack.html http://www.paulgraham.com/hijack.html He published this immediately after the 9/11 attacks to promote lisp as a solution for similar terrorist attacks. I don't know what the backlash was exactly but he apparently felt ashamed enough about voicing these suggestions that he de-listed the article. But he still cares enough about their insight to keep the article available as an isolated undiscoverable island of a URL. It shows that feeling a sense of shame (from public reaction) can be overridden by the power of personal conviction, even if the result is a silencing they don't agree with. I'm sure this 9/11 experience was fresh in their minds when this follow up essay was written. It's the only actual example I know of from them on this topic, it's evident it personally touched their family.

kazinator 3y ago
The essay is about a parallel between computer security (secure coding) and airplane security. It mentions Lisp as an example of a managed language. Graham observes that what is ineffective in airplane security is analogous to something he believes is ineffective in secure coding. Airplane security consists of screening what goes into the airplane. The airplane doesn't have protected domains. The payload space of the air plane (passenger area) is connected to the control space (cockpit): one can pass from one to the other. If it was impossible to get into the cockpit, then airplane security wouldn't have to rely on screening as much. Graham claims that this is like putting code and data together into the same space and then trying to validate the values, like array indices, rather than by somehow separating things so that even if an array overrun occurs, it cannot be exploitable. Graham's point is not very well made, but he's certainly not promoting Lisp as as solution for hijacking; that's just silly. Even GPT4 can tell you that. See below. Some problem's with Graham's argumentation are: - managed languages don't actually separate code spaces from data spaces. If a Lisp or Python vector could be overrun, it could go into some object where it helps the attacker divert a control flow. Managed languages actually resemble the screening of passengers at the terminal gates more than Graham observes. - hijackings aren't the only problem; making it impossible for passengers to enter the cockpit might prevent a hijacking, but not a suicidal bombing. - a bad agent boarding an airplane is not like an invalid datum. They conceal an intent that is inaccessible to screening. Browser security would be a better analogy for airplane security because your browser invites "passengers" to have can have harmful intent, in the form of remote javascript. And, indeed, browsers follow a security model which is more or less the inaccessible cockpit in Graham's article. I'd delete or revise the article if I were Graham. Appendix: Q: In the essay http://www.paulgraham.com/hijack.html http://www.paulgraham.com/hijack.html, is Paul Graham advocating Lisp as a solution for airplane hijackings? GPT4: No, Paul Graham is not advocating Lisp as a solution for airplane hijackings in his essay “Hijacking is Buffer Overflow” 1. Instead, he is using the analogy of a buffer overflow attack in computer programming to explain how hijackings occur. In a buffer overflow attack, someone gives a program much more data than it was expecting, causing it to overflow into the memory occupied by the program itself and allowing the attacker to run their own code. Similarly, in a hijacking, passengers overflow into the cockpit from the cabin, taking control of the plane 1. Graham suggests that the most reliable way to prevent hijackings is to separate the cockpit from the cabin, just as garbage-collected languages like Perl and Lisp keep code and data in separate places, making them immune from buffer overflow attacks 1. However, he is not advocating for Lisp as a solution for airplane hijackings.
cinntaile 3y ago
> He published this immediately after the 9/11 attacks to promote lisp as a solution for similar terrorist attacks. lol? No, he doesn't promote lisp as a solution to similar terrorist attacks...
bell-cot 3y ago
> ...he apparently felt ashamed enough about voicing these suggestions that he de-listed... Perhaps. Admitting that I don't know the backstory...I'd say that "he didn't want to spend even more of his life fighting the Internet Hate Machine(tm)" would be ample reason for pg to de-list the article.

kazinator 3y ago

The essay is about a parallel between computer security (secure coding) and airplane security. It mentions Lisp as an example of a managed language. Graham observes that what is ineffective in airplane security is analogous to something he believes is ineffective in secure coding. Airplane security consists of screening what goes into the airplane. The airplane doesn't have protected domains. The payload space of the air plane (passenger area) is connected to the control space (cockpit): one can pass from one to the other. If it was impossible to get into the cockpit, then airplane security wouldn't have to rely on screening as much. Graham claims that this is like putting code and data together into the same space and then trying to validate the values, like array indices, rather than by somehow separating things so that even if an array overrun occurs, it cannot be exploitable. Graham's point is not very well made, but he's certainly not promoting Lisp as as solution for hijacking; that's just silly. Even GPT4 can tell you that. See below. Some problem's with Graham's argumentation are: - managed languages don't actually separate code spaces from data spaces. If a Lisp or Python vector could be overrun, it could go into some object where it helps the attacker divert a control flow. Managed languages actually resemble the screening of passengers at the terminal gates more than Graham observes. - hijackings aren't the only problem; making it impossible for passengers to enter the cockpit might prevent a hijacking, but not a suicidal bombing. - a bad agent boarding an airplane is not like an invalid datum. They conceal an intent that is inaccessible to screening. Browser security would be a better analogy for airplane security because your browser invites "passengers" to have can have harmful intent, in the form of remote javascript. And, indeed, browsers follow a security model which is more or less the inaccessible cockpit in Graham's article. I'd delete or revise the article if I were Graham. Appendix: Q: In the essay http://www.paulgraham.com/hijack.html http://www.paulgraham.com/hijack.html, is Paul Graham advocating Lisp as a solution for airplane hijackings? GPT4: No, Paul Graham is not advocating Lisp as a solution for airplane hijackings in his essay “Hijacking is Buffer Overflow” 1. Instead, he is using the analogy of a buffer overflow attack in computer programming to explain how hijackings occur. In a buffer overflow attack, someone gives a program much more data than it was expecting, causing it to overflow into the memory occupied by the program itself and allowing the attacker to run their own code. Similarly, in a hijacking, passengers overflow into the cockpit from the cabin, taking control of the plane 1. Graham suggests that the most reliable way to prevent hijackings is to separate the cockpit from the cabin, just as garbage-collected languages like Perl and Lisp keep code and data in separate places, making them immune from buffer overflow attacks 1. However, he is not advocating for Lisp as a solution for airplane hijackings.

cinntaile 3y ago

> He published this immediately after the 9/11 attacks to promote lisp as a solution for similar terrorist attacks. lol? No, he doesn't promote lisp as a solution to similar terrorist attacks...

bell-cot 3y ago

> ...he apparently felt ashamed enough about voicing these suggestions that he de-listed... Perhaps. Admitting that I don't know the backstory...I'd say that "he didn't want to spend even more of his life fighting the Internet Hate Machine(tm)" would be ample reason for pg to de-list the article.