[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 3:06 PM, Kenneth Russell <kbr@google.com> wrote:
On Tue, Oct 5, 2010 at 2:45 PM, Brian Cornell <bcornell@google.com> wrote:
> 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.

Understood, especially for the cases of people building viewers for
images hosted on other sites. However, I would expect that any serious
web application needing to use this picking technique (I've seen it
used in NASA's World Wind Java visualization software) would be able
to meet this restriction.

>> 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?
> Yes.
>> 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.

And would the results be acceptable in your opinion? Is this an option
you can pursue?

If we try to introduce this into version 1.0 of the WebGL
specification it will definitely cause a delay, which is probably
detrimental for the majority of developers. We need to balance this
cost with the cost of not having this functionality, or delaying its
introduction to a future version of the specification.

There are options I can pursue for my case, though they are all slower and/or less accurate. Even if this isn't put in version 1.0, I would hope to see it added soon to the next version of the spec.


>> > 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.
>> -Ken