On Fri, Jan 8, 2016 at 9:58 AM, <kgilb...@mozilla.com> wrote: > There are two use cases for this functionality needed by the WebVR team. > > The one needed earliest is to implement HUD interfaces and dialogues. In > this case, we will only be using this API from chrome privileged code. > jgilbert has started on a mechanism we can use for now for this case as a > chrome-only API (Bug 1237489). > > For the second case, which could benefit everyone, we would like to use > DOM elements in any WebGL scene. The intent would be to deprecate the API > added in Bug 1237489 once the Khronos specification for > WEBGL_dynamic_texture is more mature and can be used in unprivileged > content. jgilbert mentions that the WEBGL_dynamic_texture specification is > due for a pruning refactor that should simplify things a bit. > > Would it help to reduce the scope and brittle-ness of the security model > by white-listing elements that are allowed in non-privileged content? The > original WEBGL_dynamic_texture proposal names specifically > HTMLVideoElement, HTMLCanvasElement and HTMLImageElement. Perhaps these > would be a good start, with an intent to expand later? >
I don't think this really helps since the element types are only part of the problem. If we wish to style content in a way that it gets sanitized of security > sensitive content, perhaps we could roll it up in a convenient CSS > attribute applied to the element we are capturing as a texture while also > ensuring that the element generates a layer and is taken out of flow from > the 2d document. > > How would you feel about this CSS: > > position: embed > > It would work like "position: absolute" in that it takes the element out > of flow; however, the element would not be positioned or rendered in the 2d > layout. It would also ensure that the element generates a layer, similar > to "will-change: transform". When called from non-privileged content, it > would enforce the whitelist, CORS, and sanitize any security sensitive > output such as those that Roc has identified earlier. > I don't think this really helps either since it still leaves us with the core problem: a security model that's hard to spec, hard to implement, and hard for authors to understand. Different ways to opt into it don't address that. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
