On Mon, Jan 4, 2016 at 4:54 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> A big problem is sticking HTML/CSS content into WebGL is that WebGL >> effectively enables reading pixel data through custom shaders and >> timing attacks. > > > If you read > https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/ > carefully I think it's designed to prevent timing attacks by forbidding > shader control flow from depending on security-sensitive texture data. > > It's hard for me to judge how implementable it is, but in principle it > should be doable. It requires analysis of shader code.
That's really cool if it's possible to do! We'd have to be careful to make sure that security-sensitive texture data can't affect paint performance in other ways. For example if such data can be used (directly or indirectly) as alpha channel of a surface, you could probably stick a slow-rendering texture behind it and that way check for certain values. Also, if any of the GLSL functions have performance which depends on the values passed to it, then we'd have to forbid passing security-sensitive texture data to such a function. So for example if abs(x) is faster for positive numbers than negative numbers, if sin(0) is faster than sin(x!=0), or if all([f, f, f, f]) is faster than all([t, t, t, t]) we have to forbid passing security-sensitive texture data to those functions. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
