WEBGL_texture_source_iframe discussion

I'm wondering how it deals with all the issues past proposals that did the same thing where pointed out to have.

Allowing WebGL to see use a texture from an iframe allows WebGL to read that texture. Disabling `gl.readPixels`, `canvas.toDataURL` and `canvas.drawImage->canvas.getImageData` are not enough because shader timing can be used to read the texture.

This was all discussed quite a bit many years ago including Adobe's CSS shader proposal and trying to make it impossible to make timable shaders.

What's changed? Why this proposal now?

Same origin is not enough to guarantee security here. At a minimum it would also require no images used in the iframe are cross origin (all of them, not just images used in a canvas). That also includes images used in the iframes inside the iframe as well as images referenced by SVG inside the iframe, images referenced by CSS, etc... Otherwise you could get around the CORS restrictions and read their contents through timing.

I don't know if this would be a solution and it would be a non-WebGL thing but what if you could create a "safe" iframe like

Where `safe=true` means

* src must be same origin
* cross origin non-CORS permission images just are not allowed period.

Not in images, not in css, etc.

* the CSS :visited selector becomes a no-op

including the default so you can't use shader timing to read people's browser history

* etc...

In other words, rather than having to check everything about iframe fits the requirements instead don't allow the iframe to have issues in the first place.

Start with the WebGL texture-source iframe proposal and the security paths named in the issue: gl.readPixels, canvas.toDataURL, canvas.drawImage→canvas.getImageData, shader timing, and nested or cross-origin resources. Review the prior CSS shader discussion referenced in the issue. Done would require a documented security resolution for the proposal and any required constraints.

Written by the indexing model from the issue text.