This is the
talk page for discussing improvements to the
WebGL article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "WebGL" – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to multiple WikiProjects. | |||||||||||||||||||||||||||||||||||||||||||
|
Looks like this should mention VRML as a predecessor. — Darxus ( talk) 21:33, 7 October 2010 (UTC)
FYI: The picture of the cowboy in the infobox comes from http://tubagames-barfight.net - which I wrote, and I gave permission for use of screenshot. SteveBaker ( talk) 03:57, 13 January 2011 (UTC)
Hi, I'm Benoit Jacob, working on the WebGL implementation at Mozilla. I would like to express my dismay at seeing some of Context's vague allegations on WebGL security incorporated into this Wikipedia article.
The only newsworthy part of this story is the Cross-Domain Image Theft vulnerability ( proof of concept here). We are actively working on addressing that at the level of the spec. You can track Mozilla's implementation progress on this here.
The rest is a mix of non-news and nonsense. Sadly, you have incorporated the nonsense in to the wikipedia article. For example, the wikipedia article currently reads "According to the report, WebGL fundamentally allows Turing-complete programs originating from the Internet to reach kernel-mode graphics drivers and graphics hardware." There are two completely wrong things here. The first one is the part about "kernel-mode graphics drivers". The kernel part of modern graphics drivers is tiny and isn't concerned with shaders. Shader compilers run in user mode, and the resulting compiled shaders run on the GPU where "kernel-mode" does not even make sense. The second wrong thing here is the part about "Turing-complete". WebGL shaders are OpenGL ES shaders, not desktop OpenGL shaders. Loop boundaries must be compile-time constants. So I don't see how that is Turing-complete.
I know that you wrote "According to Context," but that doesn't fully remove your responsibility in propagating nonsense. I normally wouldn't get all worked up on this, but too much press has already done the same mistakes in repeating Context's claims and I'm trying to get that to stop.
Regarding the DOS (denial of service) concern, as the Khronos announcement said, we have always had these issues in mind and there is no news here. Context's own blog links to Khronos' official WebGL test suite for a proof-of-context, implicitly acknowledging that we've always known about this and even discussed it in the open (see archives of the WebGL public ML). To put these concerns into some perspective, WebGL does not even show up once on the list of top 300 Firefox 4 crashers. Of course the DOS risk is not just about process crashes but you get the idea: contrary to what Context would have you believe, disabling WebGL is not going to make your browsing experience significantly better/more stable than it is.
Also, regarting the US-CERT part, the wikipedia article reads: Later, the United States Computer Emergency Readiness Team (US-CERT) issued a warning that "WebGL contains multiple significant security issues. The impact of these issues includes arbitrary code execution, denial of service, and cross-domain attacks. There is no basis for US-CERT's claims here. In particular, when they say "impact of these issues includes arbitrary code execution", they are plain wrong: there is currently no known code execution exploit related to WebGL, in either Firefox or Chrome. Whenever we find a potentially WebGL-exploitable bug in graphics drivers, we just blacklist these drivers. This true for both Firefox and Chrome. The US-CERT failed in a major way here: not only they blindly repeated what Context said, but they did a poor job at it: while Context's claims here were just ambiguous enough to not be blatantly wrong (they said WebGL "can" have exploitable flaws, whatever "can" means), the US-CERT's version is blatantly wrong. — Benoit Jacob ( 174.116.211.195 ( talk) 00:04, 16 May 2011 (UTC))
I have removed the paragraph about security, low level calls and attack vectors, added by 86.83.239.142. It seems inappropriate and irrelevant to have this as a part of the article. Security problems have historically been present in all parts of web browsers, everything from url parsing to image decoding have contained serious flaws. It is also interesting to note that the section was added by a person who almost exclusively edits articles about Zune, ribbon interfaces, IE, Windows Mobile etc. The fact that Microsoft has not implemented WebGL does not mean that it is insecure by design. -- 130.225.245.21 ( talk) 21:56, 8 August 2012 (UTC)
Read [2] — Preceding unsigned comment added by 80.121.23.11 ( talk) 15:20, 20 June 2011 (UTC)
Edit:
Mozilla removed cross-domain textures from FF5 to alleviate security concerns regarding potential (alleged), theoretical (not yet demonstrated in practice) risks. That's what the URL above points at...
Besides being in German [reminder: this is the English Wikipedia, and not every1 speaks German ;(], it only has a few words ["However, it has removed the support for cross-domain textures in WebGL, here refers to any related security problems."], which could have been simply cut-&-pasted-quoted here (like I have), thus avoiding the trouble of translating + reading the entire blog, for 1 small phrase pertaining to this discussion. ;-)
Conclusion:
Disabling WebGL cross-domain textures only disables textures coming from a domain other than the 1 which hosts the accessed web document. All other WebGL features are available and can be accessed in FF5, if settings below are enabled.
Hope this clears things out. ;-)
MDGx
☹
☺
03:03, 5 July 2011 (UTC)
You would know (or you could learn) if you would take a few minutes to install FF5 and enable/disable these about:config settings: ;-)
Google 'Firefox 5 WebGL'. Above post is probably deliberately misleading. 68.8.9.219 ( talk) 20:14, 23 June 2011 (UTC)
Note that both the originator of the Security section and one of the main editors (or the same person) have IPs that resolve to the vicinity of Shoreline, WA (near Microsoft headquarters). 67.185.162.47 98.232.18.191 http://www.geobytes.com/IpLocator.htm?GetLocation&IpAddress=98.232.18.191 This somewhat validates my belief that the "Security" concerns promoted around WebGL are really just an attack vector from Microsoft in order to protect their Windows PC gaming monopoly. Please examine the supposed image "exploit" in the Context "report" -- it demonstrates no such actual exploit, and is obviously designed to scare people. 68.8.9.219 ( talk) 20:42, 23 June 2011 (UTC)
This entire article is obviously designed to discredit WebGL and make it look like a security risk. Clearly the article is being protected from modification to remove this bias. — Preceding unsigned comment added by 68.7.147.10 ( talk) 21:52, 4 August 2011 (UTC)
FYI...
Please see
IEWebGL (free, open source).
Looks like now all Microsoft Internet Explorer (all builds starting with 6.0) web browsers (32-bit + 64-bit, for all 32-bit + 64-bit Windows OSes beginning with Windows 98) support WebGL. ;-)
IEWebGL plug-in is based on latest MS DirectX SDK (June 2010) Managed DX (MDX) implementation (build 43), and includes the MDX DLLs (both 32-bit and 64-bit). IEWebGL DLL uses JavaScript (and VBScript) to "translate" HTML5 (canvas tags) WebGL commands into Internet Explorer 6/newer built-in DirectX 3D API [probably using DirectX Media 3D/Object/Transform libraries] to render 3D objects in real time [thus bypassing OpenGL entirely, which is not needed ;-)], and allowing up to 100 fps (IE 9/10/newer). DX API accesses the hardware accelerated video controller GPU thru the video driver to achieve this, the same way WebGL does.
And the best part is that current build of IEWebGL (beta 2) is secure, because cross-domain *and* local textures are disabled. ;-)
This is a beta release, which does not (yet) support HDR textures properly (as shown by some
Chrome Experiments demos).
HTH [hope this helps]
MDGx
☹
☺
19:25, 10 July 2011 (UTC)
The section on support makes it sound as though (for example) anyone running Chrome 9 or later will have WebGL support, which is not the case. For example, I'm on Chrome 14 on Windows XP Starter on a netbook and I don't have it (I'm guessing it's because this netbook has a barebones videocard which doesn't support it?). It would be nice if someone knows what the considerations are other than browser version... and could add those to the article.
Thanks! :)
-
SColombo (
talk)
03:36, 29 September 2011 (UTC)
I've modified the list, because not only Firefox has a blacklist, but also Chrome. — Preceding unsigned comment added by 151.73.130.33 ( talk) 08:57, 14 October 2011 (UTC)
(Benoit Jacob) I don't want to edit this article since I have a direct stake in this, but please fix: Mike Shaver, not Mark.
(Benoit Jacob) Regardless of the contents of the Security section, the fact that it is by far the biggest section in this article gives the impression that there are security problems around WebGL. This is a great example of how to manipulate Wikipedia: create a controversy, get it covered in great detail on a wikipedia page, it will stay there long after the controversy has evaporated elsewhere.
(Benoit Jacob)
Problems in the Security section:
According to the report, WebGL fundamentally allows Turing-complete programs originating from the Internet to reach kernel-mode graphics drivers and graphics hardware.
I don't think that this sentence is precise enough to meet wikipedia standards: what does it mean for programs to reach kernel-mode graphics drivers? This might suggest that these programs (shaders) get somehow executed by the drivers; this is not the case; the drivers merely compile shaders. While bugs in shader compilers have been found (and worked around or blacklisted), no exploit has ever been found at that level in relation to WebGL. I.e. Context's post on this topic was pure speculation.
The US-CERT quote doesn't add any more material as all they did was read Context's announcement and repeat it.
The Khronos Group which includes Mozilla and Google responded to the concerns, suggesting possible solutions and future development approach.[16] After reviewing the Context report, Mozilla decided to disable support for cross-domain images in Firefox; while the Khronos Group has been updating the WebGL specification to enhance protection against denial-of-service and cross-origin resource sharing attacks.
This information is out of date (cross-domain textures are now possible again in both Firefox and Chrome) and mis-represents the interaction between Mozilla and Khronos: the real timeline is 1) the spec got updated 2) Mozilla implemented the spec change. http://hacks.mozilla.org/2011/06/cross-domain-webgl-textures-disabled-in-firefox-5/ http://hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/
At this time, the proposed solutions are still in development, and not ubiquitously deployed by GPU vendors.[18]
Here it's very unclear what you refer to, and since above it was question of the cross-domain-textures issue, it's natural to read this as applying to that, and that would not make sense at all: that issue is completely unrelated to GPU vendors/drivers. Please make clear that this (negative) sentence only applies to the DOS issue.
The next 4 paragraphs are unilaterally lining up arguments from the anti-WebGL side without any evidence of critical distance.
In the last paragraph, as I said above, s/Mark/Mike/.
Again, I am NOT really interested in getting this fixed point by point; I'd rather have this Security section trimmed down to a size that's reasonable compared to the rest of the article. — Preceding unsigned comment added by 66.207.208.98 ( talk) 17:55, 9 November 2011 (UTC)
(Benoit Jacob) To be honest, for reasons stated above, I think this page is embarrassing to both WebGL and Wikipedia. What's more, my above comments haven't received a reply in 10 days. I would like to know what is the procedure to report this page as not meeting Wikipedia standards.
If WebGL was as insecure as its opponents have claimed it to be, Chrome and Firefox (which ship it enabled by default) would have had to back out already. They (we) haven't. — Preceding unsigned comment added by 174.118.15.162 ( talk) 22:15, 19 November 2011 (UTC)
Security aside. I am about to start working on WebGL features for a content development website behind login... but it seems to me if this is going to be how 3D is done on the web, it needs to work for everyone if the browser is to support it. Can sources be found criticizing the selective nature of support? Eg. drivers and OpenGL implementations are blacklisted by certain browsers etc.
Are traditional "Fixed Function" APIs part of the scripting repertoire? If so those would be pretty easy to secure since GPU access would not need to be exposed to scripts, and older drivers / software renderers could easily be supported. Just like how video games have individual requirements, a website should be able to determine its/its users own needs. My guess is most sites would just like to be able to visualize some data or perform simple effects / not deliver modern day video games to end users. -- 12.213.80.55 ( talk) 22:41, 20 November 2011 (UTC)
Does Mozilla really qualify as "Original author(s)" per the infobox? Or was Mozilla just the first codebase to implement the standard? It seems like Mozilla would have had to pushed for / developed the standard (feeling threatened by??) originally to qualify for the title of Original Author. -- 12.213.80.36 ( talk) 00:54, 21 November 2011 (UTC)
The lack of anisotropic filtering in WebGL seems like a show stopper for WebGL, since you can't make a quality presentation without it. Is this intentional to hold off adoption until the technology is more mature? What gives? -- (talk) 11:40, 27 January 2012 (UTC)
I deleted the section on Security since it doesn't match the expected quality criteria of the Wikipedia. It contains personal and commercial opinions. It just speak about potential problems without a reliable measure of the risk or any serious reference from security-experts. — Preceding unsigned comment added by 93.9.68.254 ( talk) 21:10, 22 May 2012 (UTC)
quote: Internet Explorer - Obviously Microsoft has not announced any plans to support WebGL.
While its statistically obvious that MS will implement support many years after firefox/opera/webkit/safari/etc (if at all), isn't this kinda.. racking down on MS?
Divinity76 ( talk) 02:08, 8 June 2012 (UTC)
Should the history piece not at least mention the early days of w3 and the 3-D of web language MIT Curl ? see www.curl.com see Curl_(programming_language) G. Robert Shiplett 09:57, 1 November 2012 (UTC)
I'm a computer programmer, and I have a hard time understanding this article. Can an expert re-write this like... at the eighth grade level or something? It's incredibly dense and especially so, for our target audience who has little understanding of web technologies or jargon. Wjhonson ( talk) 18:19, 26 November 2012 (UTC)
Could someone please add to this to specify which matrix mathematics routines have been deprecated?
WebGL lacks the matrix mathematics routines deprecated in OpenGL 3.0. — Preceding unsigned comment added by 80.161.53.14 ( talk) 01:55, 20 June 2013 (UTC)
This is the
talk page for discussing improvements to the
WebGL article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "WebGL" – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to multiple WikiProjects. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Looks like this should mention VRML as a predecessor. — Darxus ( talk) 21:33, 7 October 2010 (UTC)
FYI: The picture of the cowboy in the infobox comes from http://tubagames-barfight.net - which I wrote, and I gave permission for use of screenshot. SteveBaker ( talk) 03:57, 13 January 2011 (UTC)
Hi, I'm Benoit Jacob, working on the WebGL implementation at Mozilla. I would like to express my dismay at seeing some of Context's vague allegations on WebGL security incorporated into this Wikipedia article.
The only newsworthy part of this story is the Cross-Domain Image Theft vulnerability ( proof of concept here). We are actively working on addressing that at the level of the spec. You can track Mozilla's implementation progress on this here.
The rest is a mix of non-news and nonsense. Sadly, you have incorporated the nonsense in to the wikipedia article. For example, the wikipedia article currently reads "According to the report, WebGL fundamentally allows Turing-complete programs originating from the Internet to reach kernel-mode graphics drivers and graphics hardware." There are two completely wrong things here. The first one is the part about "kernel-mode graphics drivers". The kernel part of modern graphics drivers is tiny and isn't concerned with shaders. Shader compilers run in user mode, and the resulting compiled shaders run on the GPU where "kernel-mode" does not even make sense. The second wrong thing here is the part about "Turing-complete". WebGL shaders are OpenGL ES shaders, not desktop OpenGL shaders. Loop boundaries must be compile-time constants. So I don't see how that is Turing-complete.
I know that you wrote "According to Context," but that doesn't fully remove your responsibility in propagating nonsense. I normally wouldn't get all worked up on this, but too much press has already done the same mistakes in repeating Context's claims and I'm trying to get that to stop.
Regarding the DOS (denial of service) concern, as the Khronos announcement said, we have always had these issues in mind and there is no news here. Context's own blog links to Khronos' official WebGL test suite for a proof-of-context, implicitly acknowledging that we've always known about this and even discussed it in the open (see archives of the WebGL public ML). To put these concerns into some perspective, WebGL does not even show up once on the list of top 300 Firefox 4 crashers. Of course the DOS risk is not just about process crashes but you get the idea: contrary to what Context would have you believe, disabling WebGL is not going to make your browsing experience significantly better/more stable than it is.
Also, regarting the US-CERT part, the wikipedia article reads: Later, the United States Computer Emergency Readiness Team (US-CERT) issued a warning that "WebGL contains multiple significant security issues. The impact of these issues includes arbitrary code execution, denial of service, and cross-domain attacks. There is no basis for US-CERT's claims here. In particular, when they say "impact of these issues includes arbitrary code execution", they are plain wrong: there is currently no known code execution exploit related to WebGL, in either Firefox or Chrome. Whenever we find a potentially WebGL-exploitable bug in graphics drivers, we just blacklist these drivers. This true for both Firefox and Chrome. The US-CERT failed in a major way here: not only they blindly repeated what Context said, but they did a poor job at it: while Context's claims here were just ambiguous enough to not be blatantly wrong (they said WebGL "can" have exploitable flaws, whatever "can" means), the US-CERT's version is blatantly wrong. — Benoit Jacob ( 174.116.211.195 ( talk) 00:04, 16 May 2011 (UTC))
I have removed the paragraph about security, low level calls and attack vectors, added by 86.83.239.142. It seems inappropriate and irrelevant to have this as a part of the article. Security problems have historically been present in all parts of web browsers, everything from url parsing to image decoding have contained serious flaws. It is also interesting to note that the section was added by a person who almost exclusively edits articles about Zune, ribbon interfaces, IE, Windows Mobile etc. The fact that Microsoft has not implemented WebGL does not mean that it is insecure by design. -- 130.225.245.21 ( talk) 21:56, 8 August 2012 (UTC)
Read [2] — Preceding unsigned comment added by 80.121.23.11 ( talk) 15:20, 20 June 2011 (UTC)
Edit:
Mozilla removed cross-domain textures from FF5 to alleviate security concerns regarding potential (alleged), theoretical (not yet demonstrated in practice) risks. That's what the URL above points at...
Besides being in German [reminder: this is the English Wikipedia, and not every1 speaks German ;(], it only has a few words ["However, it has removed the support for cross-domain textures in WebGL, here refers to any related security problems."], which could have been simply cut-&-pasted-quoted here (like I have), thus avoiding the trouble of translating + reading the entire blog, for 1 small phrase pertaining to this discussion. ;-)
Conclusion:
Disabling WebGL cross-domain textures only disables textures coming from a domain other than the 1 which hosts the accessed web document. All other WebGL features are available and can be accessed in FF5, if settings below are enabled.
Hope this clears things out. ;-)
MDGx
☹
☺
03:03, 5 July 2011 (UTC)
You would know (or you could learn) if you would take a few minutes to install FF5 and enable/disable these about:config settings: ;-)
Google 'Firefox 5 WebGL'. Above post is probably deliberately misleading. 68.8.9.219 ( talk) 20:14, 23 June 2011 (UTC)
Note that both the originator of the Security section and one of the main editors (or the same person) have IPs that resolve to the vicinity of Shoreline, WA (near Microsoft headquarters). 67.185.162.47 98.232.18.191 http://www.geobytes.com/IpLocator.htm?GetLocation&IpAddress=98.232.18.191 This somewhat validates my belief that the "Security" concerns promoted around WebGL are really just an attack vector from Microsoft in order to protect their Windows PC gaming monopoly. Please examine the supposed image "exploit" in the Context "report" -- it demonstrates no such actual exploit, and is obviously designed to scare people. 68.8.9.219 ( talk) 20:42, 23 June 2011 (UTC)
This entire article is obviously designed to discredit WebGL and make it look like a security risk. Clearly the article is being protected from modification to remove this bias. — Preceding unsigned comment added by 68.7.147.10 ( talk) 21:52, 4 August 2011 (UTC)
FYI...
Please see
IEWebGL (free, open source).
Looks like now all Microsoft Internet Explorer (all builds starting with 6.0) web browsers (32-bit + 64-bit, for all 32-bit + 64-bit Windows OSes beginning with Windows 98) support WebGL. ;-)
IEWebGL plug-in is based on latest MS DirectX SDK (June 2010) Managed DX (MDX) implementation (build 43), and includes the MDX DLLs (both 32-bit and 64-bit). IEWebGL DLL uses JavaScript (and VBScript) to "translate" HTML5 (canvas tags) WebGL commands into Internet Explorer 6/newer built-in DirectX 3D API [probably using DirectX Media 3D/Object/Transform libraries] to render 3D objects in real time [thus bypassing OpenGL entirely, which is not needed ;-)], and allowing up to 100 fps (IE 9/10/newer). DX API accesses the hardware accelerated video controller GPU thru the video driver to achieve this, the same way WebGL does.
And the best part is that current build of IEWebGL (beta 2) is secure, because cross-domain *and* local textures are disabled. ;-)
This is a beta release, which does not (yet) support HDR textures properly (as shown by some
Chrome Experiments demos).
HTH [hope this helps]
MDGx
☹
☺
19:25, 10 July 2011 (UTC)
The section on support makes it sound as though (for example) anyone running Chrome 9 or later will have WebGL support, which is not the case. For example, I'm on Chrome 14 on Windows XP Starter on a netbook and I don't have it (I'm guessing it's because this netbook has a barebones videocard which doesn't support it?). It would be nice if someone knows what the considerations are other than browser version... and could add those to the article.
Thanks! :)
-
SColombo (
talk)
03:36, 29 September 2011 (UTC)
I've modified the list, because not only Firefox has a blacklist, but also Chrome. — Preceding unsigned comment added by 151.73.130.33 ( talk) 08:57, 14 October 2011 (UTC)
(Benoit Jacob) I don't want to edit this article since I have a direct stake in this, but please fix: Mike Shaver, not Mark.
(Benoit Jacob) Regardless of the contents of the Security section, the fact that it is by far the biggest section in this article gives the impression that there are security problems around WebGL. This is a great example of how to manipulate Wikipedia: create a controversy, get it covered in great detail on a wikipedia page, it will stay there long after the controversy has evaporated elsewhere.
(Benoit Jacob)
Problems in the Security section:
According to the report, WebGL fundamentally allows Turing-complete programs originating from the Internet to reach kernel-mode graphics drivers and graphics hardware.
I don't think that this sentence is precise enough to meet wikipedia standards: what does it mean for programs to reach kernel-mode graphics drivers? This might suggest that these programs (shaders) get somehow executed by the drivers; this is not the case; the drivers merely compile shaders. While bugs in shader compilers have been found (and worked around or blacklisted), no exploit has ever been found at that level in relation to WebGL. I.e. Context's post on this topic was pure speculation.
The US-CERT quote doesn't add any more material as all they did was read Context's announcement and repeat it.
The Khronos Group which includes Mozilla and Google responded to the concerns, suggesting possible solutions and future development approach.[16] After reviewing the Context report, Mozilla decided to disable support for cross-domain images in Firefox; while the Khronos Group has been updating the WebGL specification to enhance protection against denial-of-service and cross-origin resource sharing attacks.
This information is out of date (cross-domain textures are now possible again in both Firefox and Chrome) and mis-represents the interaction between Mozilla and Khronos: the real timeline is 1) the spec got updated 2) Mozilla implemented the spec change. http://hacks.mozilla.org/2011/06/cross-domain-webgl-textures-disabled-in-firefox-5/ http://hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/
At this time, the proposed solutions are still in development, and not ubiquitously deployed by GPU vendors.[18]
Here it's very unclear what you refer to, and since above it was question of the cross-domain-textures issue, it's natural to read this as applying to that, and that would not make sense at all: that issue is completely unrelated to GPU vendors/drivers. Please make clear that this (negative) sentence only applies to the DOS issue.
The next 4 paragraphs are unilaterally lining up arguments from the anti-WebGL side without any evidence of critical distance.
In the last paragraph, as I said above, s/Mark/Mike/.
Again, I am NOT really interested in getting this fixed point by point; I'd rather have this Security section trimmed down to a size that's reasonable compared to the rest of the article. — Preceding unsigned comment added by 66.207.208.98 ( talk) 17:55, 9 November 2011 (UTC)
(Benoit Jacob) To be honest, for reasons stated above, I think this page is embarrassing to both WebGL and Wikipedia. What's more, my above comments haven't received a reply in 10 days. I would like to know what is the procedure to report this page as not meeting Wikipedia standards.
If WebGL was as insecure as its opponents have claimed it to be, Chrome and Firefox (which ship it enabled by default) would have had to back out already. They (we) haven't. — Preceding unsigned comment added by 174.118.15.162 ( talk) 22:15, 19 November 2011 (UTC)
Security aside. I am about to start working on WebGL features for a content development website behind login... but it seems to me if this is going to be how 3D is done on the web, it needs to work for everyone if the browser is to support it. Can sources be found criticizing the selective nature of support? Eg. drivers and OpenGL implementations are blacklisted by certain browsers etc.
Are traditional "Fixed Function" APIs part of the scripting repertoire? If so those would be pretty easy to secure since GPU access would not need to be exposed to scripts, and older drivers / software renderers could easily be supported. Just like how video games have individual requirements, a website should be able to determine its/its users own needs. My guess is most sites would just like to be able to visualize some data or perform simple effects / not deliver modern day video games to end users. -- 12.213.80.55 ( talk) 22:41, 20 November 2011 (UTC)
Does Mozilla really qualify as "Original author(s)" per the infobox? Or was Mozilla just the first codebase to implement the standard? It seems like Mozilla would have had to pushed for / developed the standard (feeling threatened by??) originally to qualify for the title of Original Author. -- 12.213.80.36 ( talk) 00:54, 21 November 2011 (UTC)
The lack of anisotropic filtering in WebGL seems like a show stopper for WebGL, since you can't make a quality presentation without it. Is this intentional to hold off adoption until the technology is more mature? What gives? -- (talk) 11:40, 27 January 2012 (UTC)
I deleted the section on Security since it doesn't match the expected quality criteria of the Wikipedia. It contains personal and commercial opinions. It just speak about potential problems without a reliable measure of the risk or any serious reference from security-experts. — Preceding unsigned comment added by 93.9.68.254 ( talk) 21:10, 22 May 2012 (UTC)
quote: Internet Explorer - Obviously Microsoft has not announced any plans to support WebGL.
While its statistically obvious that MS will implement support many years after firefox/opera/webkit/safari/etc (if at all), isn't this kinda.. racking down on MS?
Divinity76 ( talk) 02:08, 8 June 2012 (UTC)
Should the history piece not at least mention the early days of w3 and the 3-D of web language MIT Curl ? see www.curl.com see Curl_(programming_language) G. Robert Shiplett 09:57, 1 November 2012 (UTC)
I'm a computer programmer, and I have a hard time understanding this article. Can an expert re-write this like... at the eighth grade level or something? It's incredibly dense and especially so, for our target audience who has little understanding of web technologies or jargon. Wjhonson ( talk) 18:19, 26 November 2012 (UTC)
Could someone please add to this to specify which matrix mathematics routines have been deprecated?
WebGL lacks the matrix mathematics routines deprecated in OpenGL 3.0. — Preceding unsigned comment added by 80.161.53.14 ( talk) 01:55, 20 June 2013 (UTC)