a future caller alternative ?

Jorge Chamorro jorge at jorgechamorro.com
Sat Mar 9 03:58:04 PST 2013

On 09/03/2013, at 00:54, Andrea Giammarchi wrote:

> Mark,
>   that is an exhaustive list of links and talks but how many real use cases where we let the user inject any sort of script code in the website and we inject malicious libraries we are not aware, compared with the number of all website that would never suffer any problem with this ?
> Comparing Java Applets with JavaScript is a no-go, Java had privileged access to the system, nothing caller could achieve in all it's possible evil forms, neither eval could do much there.
> I think there are no real use cases where caller is dangerous if not few academic purpose attempts to make it safer, and you seemed to work in probably all of them ... ask devs out there how many are using those libraries.
> As summary, you ask us to bring real cases where caller is needed, I would do the other way around: bring real cases in the real world where caller could be such disaster because trusting user inputs and blindly include external libraries are not, again, real world use cases ... not the majority of them, am I wrong ?
> I see this like "don't use SQKL ever because there could be SQL injections" ... sense? None for me :-/

I think the key terms are "cooperation under mutual suspicion", "mashups", and "object capability": the idea is that you'd *want* to be able to run untrusted possibly evil code side by side with your code in your page (e.g. an ad and a payment gateway).

Other links:

Gears and the Mashup Problem: <http://www.youtube.com/watch?v=qfBL2sc2zUU/>
Web Forward: <http://www.youtube.com/watch?v=yh7TeoEwNyI#t=15m40s>
Securing JavaScript: <http://www.youtube.com/watch?v=T6TTQoqln7c>

We'd much rather play with unloaded guns than in hopes that nobody else pulls the trigger?

More information about the es-discuss mailing list