----- Original Message -----
From: "Alexey Feldgendler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 31, 2006 11:03 PM
Subject: Re: [whatwg] Side effects free scripts
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.
Math.random() in the way it is defined (without parameters) simply *cannot
work
without side effects*. By design. If ECMA Spec. says otherwise it is an
error in the spec.
This is the whole point. Dixi. Dot. Tochka.
"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.
Reformulate it as:
"Given a description of a program and its initial input,
determine whether the program, when executed on this input,
ever changes the world. The alternative is that it runs without
changing the world"
Consequence of "halting problem" is a Rice's theorem:
it states that only trivial properties of programs are algorithmically
decidable.
"No side effects" is not a trivial property.
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?
Real example: RegExp.source in IE is a static property. I think I don't
need to
explain how to steal cookies if I know that regexp was used for analyzing
them
at some point.
So answer is "no" on this:
"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.
"cases beyound the current CSS" is a motivation to create better CSS but not
to invent design
struts. IMHO.
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.
OT:
I've proposed two years ago flex units in CSS (aka %%).:
http://www.terrainformatica.com/htmlayout/fspu.whtm
http://www.terrainformatica.com/htmlayout/flow.whtm
Two years of use prooved - they are extremely useful.
Andrew Fedoniouk.
http://terrainformatica,com
