[hrjet]

Thoroughly solving security problems would of course take time. But the parent comment asked a very high level question: How does the security of this new proposal compare to a client-server model such as that of OpenGL? One can simulate one model over another, but in that case, performance can suffer due to overheads. This sort of thing needs to be addressed at the outset, because graphics needs performance and the web needs security; neither can be compromised upon.

[om2]

I don't think passing command buffers or structures in memory will be an obstacle to security.

The main security issues will likely be: * Avoiding out of bounds memory reads * Avoiding threadsafety issues * Figuring out lifetime for everything to avoid enabling out of bounds memory reads * Coming up with a safe and validatable shader format (probably a binary one, which makes validation harder) * Checking correctness of things enough to avoid making drivers completely choke

We haven't figured out a lot of these deeper issues. We don't believe the basic model is intrinsically harder to secure than OpenGL though. In fact, OpenGL's complex drivers make security harder, because exploiting the driver means a kernel exploit, so you have to be super paranoid about what you pass to the OpenGL API. Modern graphics APIs have thinner drivers so there's less risk.