4 ms·

People have been focusing on the noscript tag, but I rather like the idea of something in the head that disables all javascript in body. One good idea is perhap

by joeyh 16y ago

People have been focusing on the noscript tag, but I rather like the idea of something in the head that disables all javascript in body. One good idea is perhaps better than one good idea followed by one bad idea, especially when the history is already full of so many horrible ideas that got into the spec. ;) But there's also already something in html5; the iframe sandbox attribute. Among other things it can be used to disallow scripts to run in an iframe. You can read about it here. Amusingly, they suggest it may be available for widespread use in 10 years. http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox

chime 16y ago
> One good idea is perhaps better than one good idea followed by one bad idea Haha. I'm sure both ideas have been proposed by many people over the years. I have definitely heard of (b) from many others. I haven't heard of anyone else mentioning (a) yet. I'm kinda surprised that everyone keeps arguing against (b) while saying nothing about why (a) won't work.
- joe_the_user 16y ago
  I believe that I and others have mentioned objections that would include (a). 1. Take any given browser-based security check. A server that cares about security could do it, as a last step, instead without waiting for a hypothetical browser that would do the step. Worried about scripting in the body, strip script or whatever tags off as your last step. Sure, you could do it wrong but so could the browser. This wouldn't solve client security problems but that is the client's problem - it should be the clients problem. Some of the clients running in a large site are going to be compromised and the site has to deal with that separately from its own potential use as a vector for infection. 2. Take away the sites that care about security and ... you're left with the sites that don't care about security. And with these, even if you add the browser-side security, the uncaring sites would still be there and vulnerable. Sure, this division might be a little simplistic and you could cook up an argument for script signing but it still doesn't make sense to me. Implementing security in a single reliable place, your site, seems inherently better than implementing it across multiple domains you don't control. Microsoft's signed applets were a failure back in the day as I recall. Indeed, if you need something totally secure, why not try Java applets? They've already implemented inherently secure. (Java applets were not perfectly secure but at security was in Java to begin with, so it will always be much stronger than Javascript ... but we have think why Java applets were much less sucessful than Ajax applications).

by joeyh 16y ago

chime 16y ago

> One good idea is perhaps better than one good idea followed by one bad idea Haha. I'm sure both ideas have been proposed by many people over the years. I have definitely heard of (b) from many others. I haven't heard of anyone else mentioning (a) yet. I'm kinda surprised that everyone keeps arguing against (b) while saying nothing about why (a) won't work.

joe_the_user 16y ago
I believe that I and others have mentioned objections that would include (a). 1. Take any given browser-based security check. A server that cares about security could do it, as a last step, instead without waiting for a hypothetical browser that would do the step. Worried about scripting in the body, strip script or whatever tags off as your last step. Sure, you could do it wrong but so could the browser. This wouldn't solve client security problems but that is the client's problem - it should be the clients problem. Some of the clients running in a large site are going to be compromised and the site has to deal with that separately from its own potential use as a vector for infection. 2. Take away the sites that care about security and ... you're left with the sites that don't care about security. And with these, even if you add the browser-side security, the uncaring sites would still be there and vulnerable. Sure, this division might be a little simplistic and you could cook up an argument for script signing but it still doesn't make sense to me. Implementing security in a single reliable place, your site, seems inherently better than implementing it across multiple domains you don't control. Microsoft's signed applets were a failure back in the day as I recall. Indeed, if you need something totally secure, why not try Java applets? They've already implemented inherently secure. (Java applets were not perfectly secure but at security was in Java to begin with, so it will always be much stronger than Javascript ... but we have think why Java applets were much less sucessful than Ajax applications).