| >
Your comment doesn't make sense. You've always been able to embed the renderer with non-JIT JavaScript. Apple's renderer. Not your own custom one. > The attack vector they're concerned about is to do with the JIT exposing access to shared memory. I don't know what "exposing access to shared memory" means. All applications that download data place potentially-hostile data into memory. > As for alternate engines, any such engine would need to include a JavaScript engine, which immediately opens up vectors for attack. Such as? Describe a specific attack that is prevented by forbidding interpreters of remote content. > That's why the ability to download and execute code is restricted. Downloading and interpreting code is something that even a PDF viewer does. Why is that not restricted? > now, thanks to a robust and secure cross process communications framework, many restrictions that were supposedly 'for business reasons' have been lifted. But not the restriction on alternate Web engines. |