[whatwg] Side effects free scripts

----- Original Message ----- 
From: "Alexey Feldgendler" <alexey@feldgendler.ru>
To: <whatwg at whatwg.org>
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 
> <news at terrainformatica.com> 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

Received on Thursday, 1 June 2006 00:27:11 UTC