|
|
|
|
|
|
by simonh
3855 days ago
|
|
|
Your comment doesn't make sense. You've always been able to embed the renderer with non-JIT JavaScript. Now you can build an app with full JIT embedded, so saying they don't want you to for business reasons is obviously false. They do let you do it. The attack vector they're concerned about is to do with the JIT exposing access to shared memory. As for alternate engines, any such engine would need to include a JavaScript engine, which immediately opens up vectors for attack. That's why the ability to download and execute code is 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.