On Thu, 01 Jun 2006 11:14:56 +0700, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote:
>> There are software random number generators which gather entropy from >> user's input (the timing between keypresses, for example). And there are >> hardware random nubmer generators. > How "gather entropy from user's input" is related to the Math.random() as it > is declared in ECMAScript? The generic definition of Math.random() doesn't imply any side effects (but doesn't guarantee there aren't any). That's my point. > "Given a description of a program and its initial input, > determine whether the program, when executed on this input, > ever halts (completes). The alternative is that it runs forever > without halting. " Solving the termination problem is not the point here. Whether a script has side effects or not is one property, and whether it always terminates is another property. This thread is about the former. Scripts that don't terminate can be bad for security, too, but they should be dealt with by imposing an execution time limit, and this is not relevant here. >> Whether Math.random() should be considered safe for side effects free >> scripts or not is an arguable question. There is no danger in allowing >> Math.random() in CSS expression() from the security standpoint. But at the >> same time allowing Math.random() means that it's possible that the script >> returns different values each time invoked, which makes the life of the >> layout engine harder. > Even worse: if you have some third party code between Math.random() > invocations in your code then you may get the same number each time. To guarantee the same result each time is another requirement, and it's not necessary to fulfil it. In the end, right now there are no guarantees about the scripts, and wouldn't it be better if it could be guaranteed that a CSS expresssion() doesn't steal cookies at least? > The only feasible solution when you can guarantee something is to run > scripts in sandbox but this involves creation of brand new scripting VM > (memory space, set of globals, etc.) each time you need to evaluate formula. > This is the whole point of script security. I can guarantee that a script doesn't steal cookies if it's forced to be side effects free according to my definition. There's no other thing that I'm trying to guarantee by this security measure. > What is the purpose of the expression() there, btw? :) The purpose of expression(), as implemented by IE, is to allow authors to provide procedural implementation of the layout logic that the browser's layout engine lacks. A simple example would be painting odd rows of a table in one color and the even rows in another. Or highlighting cells which contain negative values. Of course, those things that can be expressed declaratively using CSS should be expressed as such, but there will always be use cases beyound the current CSS. I think that declaring alternating row colors with expression() is better than assigning them alternating classes because these classes would be just "hooks" for CSS, having no semantic value. And it plays better with dynamic tables which allow rows to be inserted and removed. I think that CSS expression() is a good thing, and I would really love it to be standardized. But as it's implemented in IE today, it's insecure. My proposal would allow to make it safe enough. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
