Re: Predefined JS Libraries

Thanks Joshua,

I can ear/read what you say and I understand it

What I'm saying is that the ePub people have already gone that route and
ended up allowing Javascript : it might be interesting to see what made
them think that it would be ok in the end

My understanding is that the User Agent (the ePub reader) put a lot of
constraint of the allowed javascripts

Again, I'm not saying we should allow anything. But I don't concur on
**not** allowing anything. We should allow something along the lines of
what ePub has already gone.

To me HTML in Email has *a huge* lot in common with offline electronic
books : we should look at what they made (right or wrong) instead of
(1) either having a too conservative position of staying at 1999's Web 1.0
(2) or starting to look from scratch at some work that seems to have
already been **started** to say the least

Mohamed


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

> On 2/4/2014 10:47 AM, Innovimax W3C wrote:
>
>> 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
>>
>
> Allowing untrusted JS by itself is extremely problematic. Merely letting a
> page read and change the src parameter of an <img> is sufficient to
> constitute a privacy leak were JS to be enabled (using cid: would cause the
> URL to be rewritten into one that selects the part and therefore contains
> privacy-sensitive data like a path on the local machine; setting the source
> URL again would cause a lookup to an attacker-controlled webpage,
> submitting this information).
>
> As a result, only trusted JS would be tolerable--but this means that not
> even code to control a library would be tolerable. Logically speaking, what
> this leaves you with is a JS library that could only act on declarative
> HTML markup. This is effectively indistinguishable from defining a set of
> declarative extensions to HTML that apply in email, and this feature is
> certainly a much more tolerable pill to swallow than allowing JS execution.
>
>
> --
> 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