[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)
> ----- Original Message -----
>> I totally agree with Steve, this should be about finding the right
>> balance. If we ban all non-origin-clean textures, doesn't that rule out
>> some pretty obvious and compelling use cases, such as a slide show app
>> for Flickr photos? Or in-game ads sourced from an ad provider's domain?
> Those are exactly the use cases that CORS was created for -- all it would
> take is for Flickr and the ad network to send the right http headers to
> explicitly indicate that their resources can be used from a foreign
>> I would also like to put this threat into perspective. Is the ability
>> to read out non-origin-clean pixels among the worst security issues
>> with WebGL in the first place? Personally, I'm more concerned about
>> the ideas that Stephen White brought up, i.e., a malicious script
>> breaking out of the shader sandbox, or being able to sniff data from
>> other GL contexts, or masquerading as a legitimate password dialog.
> It's not an issue of "degree of badness"; any security issues that we know
> about, especially if we can reproduce, we have to do something about. The
> issues that Stephen brought up are certainly dangerous issues, but they
> are either things that we are explicitly dealing with (breaking out of
> shader sandbox, sniffing data from other GL contexts), or things that we
> can't really do anything about (spoofing). If any bugs were found that
> would allow code to break out of the sandbox, they would be treated as
> security bugs and fixed.
Escaping out of the shader sandbox would be an error for the driver
writers to handle. nVidia, ATI, Intel, etc have to prevent their shaders
from doing that - and since they are (mostly) running on highly controlled
hardware - I don't think we have too much to worry about there. The only
place I'd be remotely concerned about that would be with drivers for low
end hardware where the vertex shader is implemented in CPU software. But
even then, that's an issue for the driver writers. If they write insecure
drivers - that's their fault and there is absolutely nothing we can do
about that. We don't get concerned (at the browser level) about exploits
in keyboard and mouse drivers...why is graphics any different?
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: