On Tue, Oct 5, 2010 at 2:45 PM, Brian Cornell <email@example.com
> On Tue, Oct 5, 2010 at 2:39 PM, Kenneth Russell <firstname.lastname@example.org
>> On Tue, Oct 5, 2010 at 1:42 PM, Vladimir Vukicevic <email@example.com
>> > ----- 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.