On Thursday, January 7, 2016 at 1:32:59 AM UTC-8, Robert O'Callahan wrote:
> On Thu, Jan 7, 2016 at 8:46 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> > At least enforcing CORS-same-origin would be somewhat trivial from a
> > specification perspective since all fetches go through Fetch. Limiting
> > plugins and other affected features would be some added conditionals
> > here and there. I don't see how content changes would have an impact
> > since you can only change the policy through navigation at which point
> > you'd have a new global and such anyway.
> >
>
> Some of the things that would need to be handled:
> -- <input type="file"> controls need to not expose sensitive data about
> file paths
> -- For SVG images we disable native themes to avoid those being inspectable
> by the Web site
> -- Non-origin-clean canvas images, <video> frames and MediaStream frames
> would have to be suppressed
> -- Non-same origin content (<img>, <iframe>, etc) would have to be blocked.
> This isn't as simple as a change to Fetch, since a site could create an
> element and load its contents in an unrestricted browsing context and move
> it into a different document with different rules.
> -- :visited
>
> 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
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?
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.
A chrome-only version with a different name could be used from privileged code
to implement backwards compatibility of 2d web pages in a VR based browser:
position: embed-unsanitized
(I'd love to hear other attribute naming ideas)
For the case of 2d web pages in a VR based browser, we would need to include
things such as iframes, cross-origin content, and :visited link styles. These
could be restricted to be used by privileged code only with "position:
embed-unsanitized"
Thanks for exploring this with me and the great feedback!
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
