![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
leynosI was reading Slashdot there (as one does), and someone hit the nail bang on the head:
That sums up the mental objection I'd always had in the back of my mind to Javascript, Office macros, etc. In my mind, the web, documents, etc, had always had the privilege 644 or whatever. I.e., read, but not execute. And consequently, I found it objectionable that these documents were executing code without my authority. I was losing control over my own computer.
Of course, times have changed, and Office now asks you by default if you want to execute scripts from a non-trusted source. Web browser developers are wising up to the dangers of allowing all and sundry to execute code on your system, and for those still in doubt, add-ons like noscript exist for further granular control.
But it seems to be that no one really grokked the problem with all this. A document that generates a display should not need the kind of functionality that allows a virus to be written in VB script, or a PDF file to execute arbitrary code, or phisher to obsfucate their page source using an encryption algorithm implemented in Javascript.
I'm not saying that such functionality shouldn't exist (Google Mail et al are wonderful things). I just feel that a distinction should be made between documents which need only be readable to be used, and documents which must be "executed" in order to function. And where execution is required, the user must be given advance notice of what the code does.
Java does this already, as does .NET. I appreciate that these are heavy weight systems, and are not always appropriate for document scripting (although, I'm hoping Silverlight/Moonlight will do a good job of arguing for the latter). For other lighter-weight circumstances, I feel there needs to be more attention (beyond what is already in place) given to managing and advising of what code does.
Just because the (in this case) .odt file is set to "------r--" doesn't mean that it doesn't contain scripts that OpenOffice.org is going to ignore just based on the file permissions.
That sums up the mental objection I'd always had in the back of my mind to Javascript, Office macros, etc. In my mind, the web, documents, etc, had always had the privilege 644 or whatever. I.e., read, but not execute. And consequently, I found it objectionable that these documents were executing code without my authority. I was losing control over my own computer.
Of course, times have changed, and Office now asks you by default if you want to execute scripts from a non-trusted source. Web browser developers are wising up to the dangers of allowing all and sundry to execute code on your system, and for those still in doubt, add-ons like noscript exist for further granular control.
But it seems to be that no one really grokked the problem with all this. A document that generates a display should not need the kind of functionality that allows a virus to be written in VB script, or a PDF file to execute arbitrary code, or phisher to obsfucate their page source using an encryption algorithm implemented in Javascript.
I'm not saying that such functionality shouldn't exist (Google Mail et al are wonderful things). I just feel that a distinction should be made between documents which need only be readable to be used, and documents which must be "executed" in order to function. And where execution is required, the user must be given advance notice of what the code does.
Java does this already, as does .NET. I appreciate that these are heavy weight systems, and are not always appropriate for document scripting (although, I'm hoping Silverlight/Moonlight will do a good job of arguing for the latter). For other lighter-weight circumstances, I feel there needs to be more attention (beyond what is already in place) given to managing and advising of what code does.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-11-22 03:09 pm (UTC)I think that there's a lot of eagerness to build Turing-complete functionality into systems that really don't require it. JavaScript is a case in point. Yeah, you get the occasional game programmed in JavaScript, but the vast majority of its uses are presentational — highlighting page elements, populating list boxes, collapsing and revealing divs, etc.. JavaScript is incredibly overpowered compared to what it is most often used for.
This is one of the reasons why the introduction of CSS was so good. Instead of having to execute code to change the presentation of your links when you hover over them, you simply declare a :hover pseudo-class, and the browser does the work. A lot cleaner, and a lot safer.
...which is why I'm unsure of some of the more recent developments in the world of CSS: namely counters, content and the like. So we're giving it variables, and output. How far are we going to go with this, and are enough people paying attention?