Talk:WebGL

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

VRML[edit]

Looks like this should mention VRML as a predecessor. —Darxus (talk) 21:33, 7 October 2010 (UTC)[reply]

From VRML: "It has been superseded by X3D". VRML/X3D have different organization behind them and VRML doesn't have anything in common with WebGL, besides they both do 3D in a web browser. Moreover VRML is sort of a markup language (not XML; take a look at specs), X3D (successor) goes straight to XML-based, while WebGL is pure JavaScript (which is awesome IMHO). To sum up: mentioning in the "See also" is good enough. —Tr00per (talk) 22:18, 8 February 2011 (UTC)[reply]
The connection is certainly tenuous. VRML is really just a file format - perhaps with an associated "player" that replays it. WebGL is an application program interface for JavaScript programmers. Sure, you could write a VRML player in WebGL - but that hardly makes them related. WebGL doesn't "supersede" VRML and might even be the savior of VRML if people decide that VRML is the best format for storing 3D models for WebGL (I sure hope that doesn't happen! VRML was **awful**). SteveBaker (talk) 00:23, 9 February 2011 (UTC)[reply]

Example[edit]

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)[reply]

Security[edit]

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))[reply]

Our problem is that Wikipedia is not (and must not be) a security firm nor a court, we are in no position to decide who tells the truth and who isn't, or whose statement have no basis. Context article seems to be received by peers and acknowledged, and we have no reason to believe it to be false unless proven otherwise, which may either happen soon (so we can write about it) or will not (so the section will transform to something titled "inherent security problems with webGL"). You are a respected MozDev so your opinion matters. However it is not peer reviewed, and you call other (known, and maybe respected) entities at least careless (if not even stronger), which may suggest your possibly reviewed the same by others.
The best course is not trying to convince us that you're right and they're wrong, but to convince other professionals, let them write about it (for your opinion) in respected sources and then come back and quote these sources on us, and we'll be able to fix the issue. --grin ✎ 07:49, 16 May 2011 (UTC)[reply]
(Reply by Benoit Jacob) I'm all for "peer review" but there has been no peer review here. There's just been a blog from Context, that has been relayed by other blogs and online news outlets, and eventually by CERT. Saying that this gives more reasons to believe that this is true is acknowledging that anything can become truth if it's repeated sufficiently many times. For what it's worth, another Mozilla employee has blogged on this issue, and other interested parties are planning to do so as soon as possible, but this is taking some time as Context took us by surprise by making their release without giving us more than a few days of notice.
I'm not saying that you should believe me and not the others, but I would like to make the point that it isn't Wikipedia's role to adopt one side of a controversy only a few days it has erupted, without giving enough time to all parties to reply (hint: Google hasn't even replied yet!). You can't be an encyclopedia AND do immediate coverage of every new controversy, at the same time.
Also, the reason why I bother writing this here rather than responding to these news outlets is that at least I know that Wikipedia is interested in not making any unfounded claims. -- Benoit Jacob 2011-05-16T14:29:17
Thanks for the clarification and the link. I have tried to update the article a bit and I hope my phrasing isn't overly misleading. I guess time will really tell what's really up.
As for myself you're one of my heroes. Thank you for all your hard work. --grin ✎ 22:04, 26 May 2011 (UTC)[reply]
Thanks Benoit. I agree that Wikipedia should not just jump onto any passing bandwagon - we must take care to report things with a sufficient delay to allow for the facts to settle down after brash early news stories. However, we must balance that against the undoubted fact that people who wish to know more about this controversy will turn to Wikipedia for that information. FWIW, the complaint about running turing-complete shader code in kernel space is a little overblown - in most cases, the shader code is tightly constrained by the GPU - which is really the ultimate sand-box environment, being electrically sealed off from having any direct effect back into the CPU. The only significant risk is with graphics systems in which the vertex shaders are emulated by compiling them into CPU-side code. If there is a failure of that system to properly sandbox the results - then that is something that should be taken up with the implementors of those systems. Meanwhile, browsers should probably black-list graphics systems that don't have an adequately sandboxed shader execution environment. The real risk here is with WebCL. SteveBaker (talk) 13:59, 21 June 2011 (UTC)[reply]
This section is still very misleading as it suggests that the 'underling' problem is solely with WebGL rather than a feature of the graphics card memory being shareable. It is weighted towards the fallacy of a authority in numbers PR campaign against WebGL, rather than giving an encyclopedic like explanation. They were designed for playing games and not with the intention of providing more processing power for more than one app at a time. Therefore, Microsoft will have the same security issue unless they too fix their software or better still have the hardware designers improve their memory management units. On medical articles, dubious press claims are quickly removed and the editors placing them there, advised to read reliable sources. Why not on technology articles as well? Gregg Tavares has some interesting thing to say around this security issue too. [1] --Aspro (talk) 07:23, 22 June 2011 (UTC)[reply]
Benoit Jacob, you have demonstrated more expertise in this area than the author of the original article from Context who is generating all of this hype on Microsoft's behalf. You need to edit the article directly to insert some of your own expertise and references. The entire Security section is in fact related to an obvious marketing effort on Microsoft's behalf. WebGL is, in my opinion, the greatest threat to Windows sales. This Context "article" is literally worth billions of dollars right now, and this Wikipedia article IS the future of Windows. If they can kill or severely damage WebGL, which I think they already have just with this one little article, without anyone ever actually demonstrating an actual exploit, that buys them at least a year more of their complete dominance on gaming front with Windows. And Windows gaming is the keymaster for the entire Windows monopoly. — Preceding unsigned comment added by 68.8.9.219 (talk) 20:19, 23 June 2011 (UTC)[reply]
If you really want to defend WebGL, instead of wasting time on complaints that can in no way be put into the article, why not go convince members of the Khronos Group to publicly, officially endorse the rock-solid security of WebGL? Wikipedia is just like that: you have no point if you remain silent, because Wikipedia cannot invent points on your behalf. The section in question is not misleading, just interpreted as such. It unequivocally attributes every single claim to whoever makes the claims. It merely reflects what happens when the situation of authorities on one side of a controversy not bothering to respond meets Wikipedia policies. If Google, Mozilla and Apple (and whoever that qualifies as WP:RS) stand up and say "WebGL is absolutely bulletproof", that will certainly help balance the argument. grin raised this point more than one month ago in reply to Benoit above. All that is needed now is somebody with the necessary social connections to get it done. Kxx (talk | contribs) 22:38, 27 June 2011 (UTC)[reply]
Please update the Security section with this new info.
Mozilla already fixed cross-domain textures in Firefox 5.0, which was released June 21, 2011 [but we all knew that ;-)]. Firefox 5.0.1 (to be released tomorrow, July 11, 2011) will fix even more issues (? = I have not read about them yet); will be posted here, but this URL does not exist yet until 5.0.1 will be officially posted at the Mozilla site (most likely tomorrow, July 11, 2011).
Google Chrome (12 stable, 13 + 14 beta + developer, and Canary test) will disable cross-domain textures in next releases, in just a few days, possibly tomorrow, July 11, 2011.
Microsoft Silverlight developers admit in their official forum to similar security flaws in current Silverlight build, and pledge to fix them in next release.
HTH [hope this helps]
MDGx☹☺ 18:42, 10 July 2011 (UTC)[reply]
July 11, 2011 Update:
Firefox 5.0.1 (stable build) was released today [as planned ;-)], but no canvas/WebGL changes, according to 5.0.1 release notes.
Google Chrome 14 developer was updated [as planned ;-)] to build 841.0, and these are the WebGL fixes. All other Chrome releases are the same.
HTH
MDGx☹☺ 11:49, 12 July 2011 (UTC)[reply]

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)[reply]

Firefox 5 doesn't support WebGL any more[edit]

Read [2] — Preceding unsigned comment added by 80.121.23.11 (talk) 15:20, 20 June 2011 (UTC)[reply]

Firefox 5 *does* support WebGL, just not all the features that were implemented in previous builds.

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)[reply]

You would know (or you could learn) if you would take a few minutes to install FF5 and enable/disable these about:config settings: ;-)

  • webgl.disabled -> false (turns on WebGL) OR true (turns off WebGL);
  • webgl.enabled_for_all_sites -> true (WebGL turned on for all web sites) OR false (allows to turn on WebGL selectively for specified web sites);
  • webgl.force-enabled -> true (WebGL always turned on) OR false (allows to turn off WebGL if invalid code/access);
  • webgl.force_osmesa -> true (uses Mesa 3D only if using installed Mesa 3D libraries: http://www.mesa3d.org/) OR false (disables use of Mesa 3D libraries);
  • webgl.osmesalib -> type Mesa 3D library name/string (only if using installed Mesa 3D libraries: http://www.mesa3d.org/) OR leave blank (if not using Mesa 3D libraries);
  • webgl.prefer-native-gl -> true (turns on browser built-in WebGL rendering engine for compatibility with Windows 2000/XP/2003 without DirectX 10/11) OR false (turns off browser built-in WebGL rendering engine in Windows Vista/2008/7 with DirectX 10/11);
  • webgl.shader_validator -> true (invalid GPU shader access displays warning messages) OR false (allows all GPU shader access regardless of validation status);
  • webgl.verbose -> true (displays detailed error messages) OR false (does not display error messages unless critical).
    HTH [Hope This Helps]
    MDGx☹☺ 16:34, 27 June 2011 (UTC)[reply]

Firefox 5 DOES support WebGL, just not Cross-Domain Textures[edit]

Google 'Firefox 5 WebGL'. Above post is probably deliberately misleading. 68.8.9.219 (talk) 20:14, 23 June 2011 (UTC)[reply]

Bias on the part of the Security editors[edit]

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)[reply]

While certain forms of argumentum ad hominem is undoubtedly accepted (and even enforced) on Wikipedia, I do not believe that argument by speculated affiliation is one of them. As for whether there exists an image exploit, my judgment would be based on Mozilla's reaction—they removed CORS image support for WebGL in Firefox 5. Kxx (talk | contribs) 16:15, 27 June 2011 (UTC)[reply]

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)[reply]

Resistance is futile... (IE)WebGL is taking over the (IE) world ;-)[edit]

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)[reply]

Don't you find declaring a piece of software only a few days old secure laughable? Especially when it has not been subjected to serious real-world security challenges. Instead of ranting policy violations like this on this talk page, time is much better spent if you go talk to the Khronos Group and get them to declare WebGL 100% bulletproof and put an end to this for everyone's sake. Kxx (talk | contribs) 05:15, 22 July 2011 (UTC)[reply]
It is also most definitely NOT "free, open source". From their FAQ page:
Q: Is it freeware software?
A: Yes it is, if you are not developing a WebGL project. It is free for all end users, which use sites based on WebGL technology. It is not true, if you are developing such site.
Q: I'm a web developer, can I evaluate your product ?
A: Yes, simply install IEWebGL plugin, and start prototyping and making tests.
Q: I'm a web developer, what I'm paying for, if I want to use IEWebGL ?
A: You pay to hide UNREGISTERED VERSION banner for your domain, that otherwise will be shown to end user. Or you can think - you pay to widen your project's audience to virtually all IE users. Also you can use all updates for free during the paid period.
That's about as far from "free, open source" as it is possible to be!
Does anyone know whether it's based on the ANGLE code-base or entirely new development? SteveBaker (talk) 13:55, 22 July 2011 (UTC)[reply]
To Kxx:
1. To date [please correct me if I'm wrong], the only [alleged, but not yet demonstrated in the "real-world"] security risks found [solely in a private company blog, not in an actual peer-reviewed IT security environment = now that's laughable, don'cha think? ;-)] are: (1) cross-domain texture high-jacking, aka "borrowing" textures originated from a domain other than the scripts' + graphics'; and (2) unbuffered textures exploiting an old nvidia/ati/intel video driver release to spy-read "dirty" data [bug which to my knowledge has been fixed some time ago by the drivers manufacturers].
And if I may, this works the other way around: one is innocent until proven guilty in most countries with true democratic regimes -> ergo: the bug finder (not the developer of said technology) has to prove their theory in practice, even better, have a neutral/unbiased 3rd party do this in a peer-reviewed forum. Until then it remains only an allegation, not a fact. ;-/
2. I'm sure the Khronos group, from what I've been reading [and as you may have figured out already, if not let me spell it out: I'm in no way affiliated with them nor with any other computer/IT/media/related company in the world, I do speak here representing only myself, and my opinons are solely mine], is doing their part in ironing out bugs to the best of their abilities. Or maybe they need help, would you like to give them a hand? I'm also sure they are already aware of this blown out of proportions security issue. That they choose to not add more comments to this already hyped up allegation, that's their choice. Maybe you would like to address this with them, and please don't try to use me as intermediary for the voicing of your opinions.
3. What policy violations? Please point me to them, I'd like to know. I'm only posting pertinent info and expressing an opinion relevant to the subject, isn't that the purpose of this discussion page? And thanks for your time + concern.
To SteveBaker:
1. My bad, it is not open source. But I do not care that it is not free for developers/for-profit businesses [more likely for for profits], because I am an end-user, and for me it is 100% free (completely different market). Sounds like the author presumes all developers of websites that may wish to develop around his technology work for profit, an assumption I do not agree with, but tough luck, you may wish to contact him, maybe he'd consider a special deal or even give you a free copy of his SDK, if you qualify as a not-for-profit developer that is, or even change his policy/license for non-profit developers.
2. If you've been browsing a bit throughout the web, you would have noticed (like I have) that this free-for-users-but-commercially-licensed[for a price]-for-for-profit-businesses policy is widely used in this industry by many for-profit companies. Obvious examples that come to mind are Microsoft, Mozilla, Adobe, Sun (now Oracle).
3. I do not know if iewebgl uses ANGLE (as far as I'm aware they are not), you may wish to contact the developers of both iewebgl + angle.
4. From June 27 [1st posted beta of iewebgl] to July 10 [the date of my 1st writing about iewebgl] there are 15 days, a lil > 2 weeks, in my book that goes beyond "a few days". ;-/ And if you look at how many releases have been posted so far [only 2, looks like none of them are bug-fixes], that tells me it must be quite stable, because I'm sure by now he had a few bug reports from users/testers, and if he would have had to fix something, he would have posted at least another (fixed) release. And if you think about it, iewebgl only translates OpenGL code into DirectX code compatible with IE's Direct3D/Media/Transform rendering engine, so if there would be any security flaws, those would be traced back to the webgl or opengl APIs, not to the translation engine.
MDGx☹☺ 16:18, 6 August 2011 (UTC)[reply]
As an end-user, you most certainly do care whether it's truly OpenSourced or not. If the developer of some web-site does not wish to pay money to the owners of this product then that web site won't work when you use IE. It doesn't matter that it's free to the end user. My web site uses WebGL, there are some cool games to play there - but because I choose not to pay for this product, you can't play them using IE because it's not free to me. If I DID choose to pay for the product then you could use it to play those games under IE. So whether the product is free to the developer or not determines whether you, the end user, can benefit from it. Also, your view of security is exceedingly naive! SteveBaker (talk) 14:56, 9 August 2011 (UTC)[reply]
To SteveBaker:
Rejoice, IEWebGL [starting with v1.0.7] is now 100% freeware, for personal and commercial use. ;-)
My view of security is "exceedingly naive" because I'm not a computer professional (seen disclaimer above?). That's why I only make comments on the talk page (from my personal point of view), I do not make policy, nor edit wikipedia with information I do not know.
But if you read Benoit Jacob's comments [a Mozilla WebGL developer] on this page and Kronos wiki pages, you would learn that most security issues have been resolved a long time ago, in all current versions of major web browsers which support the WebGL implementation.
HTH [hope this helps]
MDGx☹☺ 23:11, 23 June 2012 (UTC)[reply]

Support not just by browser but also by computer[edit]

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)[reply]

Well, you're certainly correct - if your computer has a very low end GPU that can't support shaders - then the browser will deny the web page access to WebGL. Additionally, the browser writers sometimes 'blacklist' a particular GPU or a particular driver because of security concerns or if it's broken in some manner that prevents WebGL from functioning correctly. I suppose we could mention something along those lines. But listing devices and drivers that don't work is well beyond the scope of what we can do here - that list changes often and is not easy to track down, so it would be a nightmare to maintain. SteveBaker (talk) 14:10, 29 September 2011 (UTC)[reply]

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)[reply]

Mike Shaver, not Mark Shaver[edit]

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

Thoughts on how Wikipedia can get manipulated[edit]

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

On the contents of the security section[edit]

(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)[reply]

How to report this page as not meeting Wikipedia standards?[edit]

(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)[reply]

I also find the security section to be poorly phrased. To an average reader it will suggest that WebGL allows internet sites to run programs (viruses, trojans etc.) on the client. That is not true, WebGL includes a layer of abstraction between the internet and the client. The abstraction will be implemented differently in various clients, though most will try to let it as close to the hardware as possible. The issue is that WebGL allows the internet to exploit hardware indirectly. This could cause performance problems, crash the browser, or the hardware. However these are domain problems, where the site can affect the client outside of the browser, rather than security issues in the typical sense.
I intend to return to this page in a few days time and rephrase this section. The report mentioned should be included as a reference, but not quoted verbatim. 83.216.149.7 (talk) 01:53, 16 December 2011 (UTC)[reply]
Wikipedia isn't some place where you can "report" problems and they'll be fixed. It is a place where people can come and fix things themselves. So if you don't like the way the article is, you have to fix it yourself. Obviously, there will be times when other people disagree with your fixes - so the fixes get fixed (or possibly just reverted). If you have problems with that then you can discuss the matter with other editors here. But there is no central 'authority' that will step in and fix bad pages - it's always a matter of debate that is carried out right here, in this talk page. In this specific case, I agree that the source is over-dramatizing the security concerns and that WebGL is safe in practice...if not in theory. However, the other part of how Wikipedia works is that all controversial statements must be backed up by "reliable sources" - and if we have a reliable source that says that WebGL is a security risk - then we have to discuss that in the article - until/unless there is an overwhelming number of other reliable sources that say this is not so. Hence, the first step towards fixing this issue is to find multiple reliable sources that argue from your position. SteveBaker (talk) 14:10, 16 December 2011 (UTC)[reply]
I understand how Wikipedia works, but that doesn't mean that everything written cannot be changed without counter proof. Many topics are a mixture of opinion and known truth. Why would it be a problem removing the supposition and keeping the fact? My intention is to rephrase the section so that it mentions the potential issues with WebGL but doesn't use the inflammatory language. The idea would be to make the article more explicit. There should be no problem with that unless somebody wants to portray the issue with a bias. The text in question is based entirely on one report and should not be taken as gospel simply because it's quoted here. 83.216.149.7 (talk) 20:43, 16 December 2011 (UTC)[reply]
(Benoit Jacob) I have a direct stake in this (Mozilla employee), so it's not very good practice for me to directly edit this article. That's why I'm explaining my point on this discussion page instead, so that unbiased, independent people can hopefully make the call.66.207.208.98 (talk) 18:14, 20 December 2011 (UTC)[reply]

Criticism section?[edit]

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)[reply]

(Benoit Jacob) Note that on Windows, browsers normally use Direct3D, not OpenGL, for rendering WebGL. Here's a documentation of current blacklists and here is analysis of the proportion of users who were getting blacklisted as of August 2011. The fixed-function API isn't present in WebGL; it also isn't present in OpenGL ES 2.0, upon which WebGL is based; it doesn't allow to take advantage of current hardware anyway; if one included vertex array support (as in OpenGL 1.5) then it would have the exact same DOS vulnerability as WebGL/Flash11/Silverlight5 have (note that DOS testcases do not use complex shaders at all), and if one didn't include vertex array support then it would be even more lame. Also, your guess doesn't match the reality that most of the demand for WebGL is for games, advanced (e.g. medical) data visualization, and video/image processing (web-based photo editing apps, for example), none of which can be contented by OpenGL 1.x level functionality. People who just want to do basic charts drawing, even with some 3D in it, can do it with the 2D canvas instead of WebGL. — Preceding unsigned comment added by 174.118.15.162 (talk) 23:10, 20 November 2011 (UTC)[reply]
Most 3D APIs have had a fixed function layer. If your website stuck to the fixed function APIs then it can be said that the browser is wholly responsible. The DoS techniques explained in the security stuff mostly use custom shaders. The browser could prevent all other DoS by limiting the bandwidth available. It doesn't make sense to pump large assets thru a browser if we expect it to play nice. Browsers really should not be game platforms. Anyway, my point was mainly that its unacceptable for WebGL to not be able to support all environments. There's never been anything selective like that that is built into web browsers in the history of the WWW. Supporting more sophisticated graphics could be classified as being like supporting ever higher levels of CSS, but some basic functionality should be available. Its absurd that a WebGL browser would not support Windows XP or a wide variety of drivers that might be built into various devices to some degree. At the very least fallbacks should be available to WebGL scripts if the standard is to be of a lot of use / not a gaming platform (browsers should not be gaming platforms). --12.213.80.36 (talk) 00:54, 21 November 2011 (UTC)[reply]
(Benoit Jacob) "The DoS techniques explained in the security stuff mostly use custom shaders." This doesn't mean anything as WebGL just forces you to use "custom shaders": you can't draw anything in WebGL without a "custom shader". But the DOS testcases out there use completely trivial "custom shaders" just writing one pixel, and in some cases, doing one texture fetch. Sometimes they try to maximize texture cache misses, but that's also easy to do with plain OpenGL 1 using large texcoords and GL_REPEAT. 174.118.15.162 (talk) 14:11, 21 November 2011 (UTC)[reply]
Point is. If shaders were not exposed and bandwidth was throttled there would be no security risk then. And it would look more like a traditional toe in the water / equal opportunity web standard. That's a valid criticism. Just offering advice for improving the article... if that is any notable sources are noting the fact that the standard excludes certain types of environments looks like a weakness. I would like to see the standard address this concern myself in some way but this is just a Wikipedia article. A builtin catalog of shaders with certain parameters that could be mapped to real world rendering APIs by the browser or be supported by drivers would probably work fine without bloating the standard. --99.197.224.57 (talk) 18:26, 21 November 2011 (UTC)[reply]
(Benoit Jacob) Sigh. I don't know how I have to say it, this is now the 3rd time I try to explain it. Every 3D API of the past 14 years has the DOS vulnerability. Even OpenGL 1.1 from 1997. Texture bandwidth can't be throttled. This has nothing to do with complexity in shaders. All you need is to be able to draw many triangles at once, aka "vertex arrays". This was introduced in OpenGL 1.1 in 1997; have fun with OpenGL 1.0 all you want. 174.118.15.162 (talk) 00:49, 22 November 2011 (UTC)[reply]
^Not your personal talk page. The idea is to improve the article. And throttling means not allowing many triangles to draw at once. As in the framerate will stop if the system is burdened. There is an ARB extension that does something like that according to some of the related articles. The only question is, what other criticisms are out there. --12.213.80.55 (talk) 23:38, 22 November 2011 (UTC)[reply]

Mozilla Foundation[edit]

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)[reply]

(Benoit Jacob) WebGL originally was pioneered by Vladimir Vukicevic, under the name "Canvas 3D", around 2006 or 2007. Vladimir was a Mozilla Corporation employee (engineer) at the time, which he remained until 2011. This Wikipedia page even has a link to http://blog.vlad1.com/2007/11/26/canvas-3d-gl-power-web-style/ (see 10. under References). Around the same time, Opera experimented another, higher-level approach to a 3D canvas context: http://my.opera.com/timjoh/blog/2007/11/13/taking-the-canvas-to-another-dimension . Eventually a '3dweb' working group got created at Khronos, Vladimir's lower-level approach was preferred, and the name 'WebGL' was adopted. 174.118.15.162 (talk) 14:04, 21 November 2011 (UTC)[reply]
Maybe a source should be in the info box then. --12.213.80.55 (talk) 23:39, 22 November 2011 (UTC)[reply]

How far off is anisotropic filtering?[edit]

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)

This kind of discussion is for the WebGL mailing list - this page is for discussion of the Wikipedia article - not for bemoaning the capabilities of the API. SteveBaker (talk) 21:17, 27 January 2012 (UTC)[reply]
For the record. Firefox 10.0 adds built in anisotropic filtering. Point was to figure out what's what and hopefully provide supplemental information towards making a more informative article. I should've posted that I had looked everywhere for info. -- 02:16, 7 February 2012 (UTC)

Security section deleted[edit]

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)[reply]

I'll have to check what that section said before, but do note that Microsoft didn't implement WebGL until their concerns about CORS were put in the standard, or at least that's what their program manager said [3]. Carmack also said some unpleasant things in that regard about WebGL initially [4] and he qualifies as WP:RS as well. Reliable sources don't have to agree with each other on matters of opinion, we just need to present such opinions in a WP:NPOV manner. JMP EAX (talk) 22:23, 6 August 2014 (UTC)[reply]
Carmack revisited the issue in the 2nd half of this talk snippet. JMP EAX (talk) 22:29, 6 August 2014 (UTC)[reply]
I found the section that was deleted [5]. It needs some work, particularly more references for the fixes part, but it's not incredibly bad. JMP EAX (talk) 01:02, 7 August 2014 (UTC)[reply]
I'm assembling a few sources here, so the section can be written in a more NPOV/comprehensive manner than it was before. This seems a useful one, albeit dated. JMP EAX (talk) 07:12, 7 August 2014 (UTC)[reply]

Internet Explorer & WebGL obvious?[edit]

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)[reply]

browser 3-D and w3 : history[edit]

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)

Please rewrite[edit]

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)[reply]

It's not clear what you don't understand. This article is very high-level and really doesn't delve into any details... I had no trouble understanding any parts of it. Is it not sufficiently linked? You cannot expect it to explain every concept it mentions (instead of linking). I think you should consider that WP:NOTTEXTBOOK. JMP EAX (talk) 22:11, 6 August 2014 (UTC)[reply]

Please Add[edit]

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)[reply]

IE fully supported but Firefox partial?[edit]

See: [6] comp.arch (talk) 11:02, 17 September 2014 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:WebGL&oldid=1209957361"