On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I see security problems all over ... you own your function, you can make
> it "pure" or serializable ... you don't know your function, I believe
> there's no way you want that unknown function to be executed in your own
> sandbox opening doors for any sort of attack, i.e. ... this is pure, no
> outer scope access at all: function pure() { function(){return
> this}.call(null).Function.prototype.serialize = function() { /* boom */ } }
JavaScript is singly threaded. Within a given JavaScript
thread/process/worker/vat/whatever, any code which is ever given control
can just go into an infinite loop or throw, so none of the within-vat
sandboxes attempt to make any claims about availability[1]. However, SES,
by following the object-capability model, makes strong claims about
integrity. Irakli's notion of closed strict functions is adequate for safe
remote execution, where "safe" means that it can cause no effects on the
integrity of its importing context not explicitly authorized by the
references passed into it.
[1] MS WebSandbox claimed only resistance to availability accident, not to
availability attack.
>
>
> On Mon, Nov 5, 2012 at 12:19 PM, Herby Vojčík <he...@mailbox.sk> wrote:
>
>>
>>
>> Irakli Gozalishvili wrote:
>>
>>> Hi,
>>>
>>> I keep running into cases where I would like to know if function is
>>> pure. Although my interpretation of pure is not quite right but I don't
>>> know any better name. By pure in this context I would refer to functions
>>> that don't access an out scope variables and don't
>>> do any mutations of itself or it's properties no references to itself
>>> could be an option too. My intended use case for such a feature is to
>>>
>>
>> IOW, 'stateless'; or 'serializable'. For in fact it means, that I can
>> send f.toString() to the other side and when evaled, I can use it.
>>
>>
>> processes too, it would be great if we had something like
>>> Function.isPure(f). Also as far as I know jits already capture this info
>>> for optimisation purposes maybe it could be exposed ? Another
>>> alternative could be pure(function() { …. }) that would throw compile
>>> error if
>>> function followed is not pure.
>>>
>>
>> Yes, it could be nice to have some API to help with this. Maybe not
>> generic isPure or the like, maybe Function.serialize(f) and
>> Function.deserialize(**serialized_f) would be enough, the former
>> returning null if not pure/stateless/serializable.
>>
>> It is good to note that the function is serializable not only if it has
>> no outer pointers, but also when its outer pointers only point to 'known
>> primitives' (numbers, strings, null, true, false; not symbols).
>>
>>
>>
>>> Thanks!
>>> --
>>> Irakli Gozalishvili
>>> Web: http://www.jeditoolkit.com/
>>>
>>
>> Herby
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
