9 ms·

This is a good point, but I feel that discouraging this type of approach is not the way to go. I apologise in advance for ranting... I hope this is not too off

This is a good point, but I feel that discouraging this type of approach is not the way to go. I apologise in advance for ranting... I hope this is not too off-topic, but instead a "zoom out" on the issue. This touches on something deep and wrong about how we use computers these days. Computers are really good at being computers, and the amplification of intellectual capabilities they afford is tremendous, but this is reserved for a limited few that were persistent enough and learned enough to rediscover the raw computer buried underneath, and what it can do. For example, I dream of a world where everything communicates through s-expressions, all code is data and all data is code. Everything understandable all the way down. Imagine what people from all fields could create with this level of plug-ability and inter-operability. We had a whiff of that with the web so far, but it could be so much more powerful, so much simpler, so much more elegant. All the computer science is there, it's just a social problem. I understand the security issues, but surely limiting the potential of computers is not the solution. There has to be a better way.

judk 13y ago
When my conputer has the potential to erase my bank account, I want to limit its potential.
seabee 13y ago
In a world where users will willingly enter malicious code into their computers if they believe it will do something they want[1], can there really be a better way? [1] https://www.facebook.com/selfxss https://www.facebook.com/selfxss
- hdevalence 13y ago
  This seems like exactly the problem the parent post is complaining about, though: the people in the limited group the parent talks about aren't the people being tricked by selfxss, it's the people who don't have the technical knowledge to understand what the developer console does and why pasting in random JS might be a bad idea. So the phenomenon of selfxss reinforces the point.
- davb 13y ago
  Perhaps modern operating systems (or hardware?) need two modes - "Safe mode", where everything is sanitised, checked, limited and Secure Boot-style verified, and "Open mode" where it's not; where experts and enthusiasts can work without limit and without DRM.
  - Seeless 13y ago
    That only adds an extra step to the social engineering process.
    - deleted 13y ago
      [deleted]
  - kalleboo 13y ago
    Safe mode is called iOS
- Crito 13y ago
  When it comes right down to it, you can't fully protect people from themselves. Even in 'meat space', which the general population is presumably experienced with, people talk others into doing things that they should not all the time. Anything from social engineering to bog-standard scam artists masquerading as door-to-door salesmen.
  - Someone 13y ago
    But in 'meat space', it is way harder and more expensive to do evil against large numbers of people. For example, phishing as done electronically (throw a very, very wide net, and hope) doesn't make economical sense if one had to do it manually. Also, if, for example, cars and airplanes and banks and nuclear submarines would accept executable code as input, some people would do damage on a gargantuan scale. Clearly, being liberal in what you accept must end somewhere. I argue that it should end very, very soon. Even innocuous things such as "let's allow everybody to read the subject of everyone's mail messages", if available at scale and cheaply, would entice criminal behavior, for example by those mining them for information that you are away from home. Does anybody know how RMS thinks about passwords nowadays?
    - Crito 13y ago
      I'm not saying that scams in "cyberspace" don't present a greater threat than scams in "meatspace". I'm just pointing out that if you cannot protect people from themselves in "meatspace", then doing it in "cyberspace" is futile. You can fight it and cut back on it, but you will never actually win that fight. Technological problems to what is ultimately a sociological problem only go so far, and we should be careful to not obsess over them to a fault.
      - Someone 13y ago
        And yet, in "meatspace", chainsaws come with more safety mechanisms than butter knives because the damage they can do is so much larger. Yes, we can't win that fight; people will die from chainsaw accidents, but I disagree that we shouldn't be more vigilant about chainsaws than about butter knives.
saraid216 13y ago
You're discouraging it in the wrong place. Learning to swim is not done by throwing a kid in the deep end of a pool. Learning to code is not done by encouraging bad security practices.
- wtallis 13y ago
  On the other hand, taking the easy way out when this kind of security problem comes up leads to having a machine that's just an appliance and not a computer. If you've closed every local code execution vulnerability, you've probably rendered your system completely non-programmable and erected a monumental barrier to learning how to hack.
haberman 13y ago
Lack of Turing-completeness can be a feature. Take PDF vs PostScript. The latter is Turing-complete and therefore you cannot jump to an arbitrary page or even know how many pages the document has without running the entire thing first. By limiting expressiveness you also gain static analysis and predictability. It's not about limiting the potential of computers, it's about designing systems that strike the right balance between the power given to the payload and the guarantees offered to the container/receiver. For example, it is only because JSON is flat data and not executable that web pages can reasonably call JSON APIs from third parties. There really is no "better way" -- if JSON was executable then calling such an API would literally be giving it full control of your app and of the user's computer.
- eurleif 13y ago
  >There really is no "better way" -- if JSON was executable then calling such an API would literally be giving it full control of your app and of the user's computer. Of course there's a "better way": running the code in a sandbox. You could do so using js.js[1], for example. (Of course, replacing a JSON API with sandboxed JS code is likely to be a bad idea. But it is possible.) [1] https://sns.cs.princeton.edu/2012/04/javascript-in-javascript-js-js-sandboxing-third-party-scripts/ https://sns.cs.princeton.edu/2012/04/javascript-in-javascrip...
  - haberman 13y ago
    You're right inasmuch as I shouldn't have implied that unsandboxed interpretation is the only option. But my larger point still stands; the fundamental tradeoff is still "power of the payload" vs "guarantees to the container." Even in the case of sandboxed execution, the container loses two important guarantees compared with non-executable data formats like JSON: 1. I can know a priori roughly how much CPU I will spend evaluating this payload. 2. I can know that the payload halts. This is why, for example, the D language in DTrace is intentionally not Turing-complete.
    - eurleif 13y ago
      If excess CPU/non-halting behavior is the issue, you could run the code with a timeout.
deleted 13y ago
[deleted]

judk 13y ago

When my conputer has the potential to erase my bank account, I want to limit its potential.

seabee 13y ago

In a world where users will willingly enter malicious code into their computers if they believe it will do something they want[1], can there really be a better way? [1] https://www.facebook.com/selfxss https://www.facebook.com/selfxss

hdevalence 13y ago
This seems like exactly the problem the parent post is complaining about, though: the people in the limited group the parent talks about aren't the people being tricked by selfxss, it's the people who don't have the technical knowledge to understand what the developer console does and why pasting in random JS might be a bad idea. So the phenomenon of selfxss reinforces the point.
davb 13y ago
Perhaps modern operating systems (or hardware?) need two modes - "Safe mode", where everything is sanitised, checked, limited and Secure Boot-style verified, and "Open mode" where it's not; where experts and enthusiasts can work without limit and without DRM.
- Seeless 13y ago
  That only adds an extra step to the social engineering process.
  - deleted 13y ago
    [deleted]
- kalleboo 13y ago
  Safe mode is called iOS
Crito 13y ago
When it comes right down to it, you can't fully protect people from themselves. Even in 'meat space', which the general population is presumably experienced with, people talk others into doing things that they should not all the time. Anything from social engineering to bog-standard scam artists masquerading as door-to-door salesmen.
- Someone 13y ago
  But in 'meat space', it is way harder and more expensive to do evil against large numbers of people. For example, phishing as done electronically (throw a very, very wide net, and hope) doesn't make economical sense if one had to do it manually. Also, if, for example, cars and airplanes and banks and nuclear submarines would accept executable code as input, some people would do damage on a gargantuan scale. Clearly, being liberal in what you accept must end somewhere. I argue that it should end very, very soon. Even innocuous things such as "let's allow everybody to read the subject of everyone's mail messages", if available at scale and cheaply, would entice criminal behavior, for example by those mining them for information that you are away from home. Does anybody know how RMS thinks about passwords nowadays?
  - Crito 13y ago
    I'm not saying that scams in "cyberspace" don't present a greater threat than scams in "meatspace". I'm just pointing out that if you cannot protect people from themselves in "meatspace", then doing it in "cyberspace" is futile. You can fight it and cut back on it, but you will never actually win that fight. Technological problems to what is ultimately a sociological problem only go so far, and we should be careful to not obsess over them to a fault.
    - Someone 13y ago
      And yet, in "meatspace", chainsaws come with more safety mechanisms than butter knives because the damage they can do is so much larger. Yes, we can't win that fight; people will die from chainsaw accidents, but I disagree that we shouldn't be more vigilant about chainsaws than about butter knives.

saraid216 13y ago

You're discouraging it in the wrong place. Learning to swim is not done by throwing a kid in the deep end of a pool. Learning to code is not done by encouraging bad security practices.

wtallis 13y ago
On the other hand, taking the easy way out when this kind of security problem comes up leads to having a machine that's just an appliance and not a computer. If you've closed every local code execution vulnerability, you've probably rendered your system completely non-programmable and erected a monumental barrier to learning how to hack.

haberman 13y ago

Lack of Turing-completeness can be a feature. Take PDF vs PostScript. The latter is Turing-complete and therefore you cannot jump to an arbitrary page or even know how many pages the document has without running the entire thing first. By limiting expressiveness you also gain static analysis and predictability. It's not about limiting the potential of computers, it's about designing systems that strike the right balance between the power given to the payload and the guarantees offered to the container/receiver. For example, it is only because JSON is flat data and not executable that web pages can reasonably call JSON APIs from third parties. There really is no "better way" -- if JSON was executable then calling such an API would literally be giving it full control of your app and of the user's computer.

eurleif 13y ago
>There really is no "better way" -- if JSON was executable then calling such an API would literally be giving it full control of your app and of the user's computer. Of course there's a "better way": running the code in a sandbox. You could do so using js.js[1], for example. (Of course, replacing a JSON API with sandboxed JS code is likely to be a bad idea. But it is possible.) [1] https://sns.cs.princeton.edu/2012/04/javascript-in-javascript-js-js-sandboxing-third-party-scripts/ https://sns.cs.princeton.edu/2012/04/javascript-in-javascrip...
- haberman 13y ago
  You're right inasmuch as I shouldn't have implied that unsandboxed interpretation is the only option. But my larger point still stands; the fundamental tradeoff is still "power of the payload" vs "guarantees to the container." Even in the case of sandboxed execution, the container loses two important guarantees compared with non-executable data formats like JSON: 1. I can know a priori roughly how much CPU I will spend evaluating this payload. 2. I can know that the payload halts. This is why, for example, the D language in DTrace is intentionally not Turing-complete.
  - eurleif 13y ago
    If excess CPU/non-halting behavior is the issue, you could run the code with a timeout.

deleted 13y ago

[deleted]