On Mon, Jan 4, 2016 at 5:46 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote: > >> > Essentially, we would extend the same API but allow the WDTStream >> >> interface to apply to more HTML elements, not just HTMLCanvasElement, >> >> HTMLImageElement, or HTMLVideoElement. >> >> >> >> We would also need to implement WEBGL_security_sensitive_resources to >> >> enforce the security model: >> >> >> >> >> >> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/ >> > >> > >> > I wish I'd known about this proposal earlier! This looks pretty good, >> > though I'd always thought this would be too complicated to spec and >> > implement to be practical. Glad to be wrong! Although I think we should >> get >> > as much feedback as possible on this in case of hidden gotchas. >> >> Historically in our investigations of this, it seemed very very hard >> to guarantee a lack of timing vectors, even just for arithmetic. >> (Particularly since we're handing the sources to the driver, which >> will try to optimize away as much as it can) >> > > Feedback from GPU vendors would be key here, I think. I'd like to hear that > before declaring it dead. If they already did --- RIP :-).
What if, rather than using a black-list approach indicating which operations are forbidden, we use a white-list approach indicating a small number of ways that security-sensitive texture data may be used? For example only allow it to be scaled, added to and clamped to a range. Or some such. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
