3 ms·

> 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 hav

by 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 chime 16y ago

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).