>
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.
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.