[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)

On Tue, Oct 5, 2010 at 2:39 PM, Kenneth Russell <kbr@google.com> wrote:
On Tue, Oct 5, 2010 at 1:42 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
> ----- Original Message -----
>> My argument as to them being orthogonal is that the canvas spec having
>> something similar would not affect WebGL. Imagine that Vlad's
>> suggestion were implemented in the canvas spec today, would that
>> somehow make it such that readPixels and tainted images could be used
>> in the same WebGL context? I don't see how. So the WebGL spec would
>> have to be changed in the exact same way whether or not it is adopted
>> for 2d canvas.
> Note that when I (and I believe) Chris says "at the Canvas level", it doesn't mean at the canvas 2D context level -- but actually at the core level of the <canvas> element, regardless of the underlying contexts.  Canvas doesn't really have much language to say there, but I think the spec could be extended to define what it considers origin clean/origin dirty in a more fine grained way.  I wouldn't want to add very detailed descriptions of that into the WebGL spec, especially at this point; doing the tracking of the various pieces is certainly possible, but it's not code that I would want to write right now for 1.0.

While I have to agree that I wouldn't want to write the code to
perform the more fine-grained security tracking for WebGL 1.0 at this
point (nor really the spec text), the question we need to ask is
whether we are excluding a large class of interactive applications by
not doing so. As Gregg mentioned, it's a common technique to implement
picking in OpenGL by drawing each triangle in a separate color and
reading back the pixel under the mouse pointer.

The application Brian works on is a real-world, non-game use case
involving a lot of data that it would be really sub-optimal to have to
replicate across multiple WebGL contexts.

A few questions for Brian:

1. Is it not feasible to serve your web pages and images from the same
domain? What about using a proxy?

It may be difficult, but is an option that can be investigated. The one main reason I can see for some people to not want this is per-domain caching rules, wanting an images domain that is cached differently than a domain serving code. Another reason people sometimes want it is to serve user generated content from an untrusted domain.
2. Do you perform per-pixel tests and discards in your fragment shader
implying that you simply can not do ray casting at the application
level and get the same results you are getting with your current
picking technique?


3. Would it be possible for you to perform ray casting in your
application against a subset of your data set to achieve similar
picking results?

Similar, but lower quality. 

> So, if the canvas (element) spec were to be extended to describe origin-clean resources and take into account CORS, etc., I don't see any reason why a WebGL implementation couldn't start following the tighter definitions in the future.

I think we should ignore the question of CORS for the moment and focus
on the more fine-grained, WebGL-specific tainting.