Re: Predefined JS Libraries

Well both of you, Robin and Joshua, are just saying that **any** JS is a
problem. On this point, I concur

It doesn't lead me to think that a selection of libraries with the right
limitations, won't be able to make there way to htm@il

I must admit that it would be the same as having access to some high level
API, but it would have the benefits of being able to allow extensibility

Mohamed


On Tue, Feb 4, 2014 at 5:29 PM, Joshua Cranmer <Pidgeot18@verizon.net>wrote:

> On 2/4/2014 10:11 AM, Robin Berjon wrote:
>
>> On 04/02/2014 14:08 , Innovimax SARL wrote:
>>
>>> It could be a huge mess to allow **any** library, but it might be a good
>>> idea to include already well known library
>>>
>>> On the top of my head JQuery, Prototype, Processing.js which could be a
>>> list as in http://jsfiddle.net/
>>>
>>
>> Part of the problem with allowing JS -- *any* JS -- is that in the webmail
>> case you need to ensure that it can only manipulate the rendering of the
>> email itself, and not the UI around it.
>>
>> And even then, it opens up a whole new can of worms (literally). For
>> instance, you could send innocuous-looking attachments and
>> innocuous-looking JS but if the latter were to modify the former (even just
>> by generating a Blob URL and linking to it) then you've made it past a lot
>> of virus checks.
>>
>
> There's another can of worms, too: JS can also have the potential to
> access the XHR features of the website itself, which means a malicious
> script (if the sandboxing breaks down) can do things like "forward all of
> my messages to a third party without telling me."
>
> --
> Beware of bugs in the above code; I have only proved it correct, not tried
> it. -- Donald E. Knuth
>
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 EURO