Update README.md

[vasilich-tregub]

The original text attributes the failure of running the samples from a file:/// URL to a non-secure context. However, it is not an unspecified security issue. It is a CORS policy violation: with a file protocol scheme, the origin is 'null', and the null is identical to nothing. Therefore, the CORS policy check fails.

Also, for Sample 8 to run, the browser can require "user gesture". I explain how to use the browser privacy settings to circumvent this requirement.

Is a Tetrahedron link dead or is it only my connectivity problem? If the link is dead, delete the 'Additional' example' subsection.

[bsmth]

Thanks for raising. I'm going to close for now as I think the original is sufficient and the suggestions add in some additional information which isn't necessary for the example. If you'd like to look for other things to work on, please check for issues labeled good first issue or accepting pr - these have a better chance of being accepted! Thanks a lot! 🙏🏻

[vasilich-tregub]

...WebGL requires that any textures or other binary data be loaded from a secure context, which means you can't just use most of these samples from a file:/// URL

Actually, you cannot use ANY of these samples (1-8) from a file:/// URL.

Then, I've searched MDN for the phrase "WebGL requires that any textures or other binary data be loaded from a secure context" and found the document https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL. In the section Loading textures, 1st Note, the document declares that the loading of textures follows cross-domain rules (it is correct) and, at the same time, in the section Cross-domain textures, 2nd paragraph, that WebGL now requires textures to be loaded from secure contexts (it is not correct, if not simply false). In fact, WebGL does not require to be loaded from secure contexts, and you can easily verify this claim: the webgl-example samples do work when served from http server, and http://localhost is NOT A SECURE CONTEXT.

For definition of what conditions make browsing contexts secure, see, e.g., the normative text with examples cited in the work-in-progress W3C document https://w3c.github.io/webappsec-secure-contexts/#examples-top-level. Conforming to CORS policy rules alone does not make the site secure; the data shall be delivered over an authenticated and encrypted channel, which is not the case with http server. Still, the samples work when served from http server, and the requirement of secure context given in your text can be weakened to just CORS policy conformance requirement.

Why this consideration is not the act of nitpicking: your writing is intended to be a tutorial. Along with bits of practical advice, you communicate the knowledge, and you are under obligation to make the information you provide to your readers as verifiable and trustworthy as practically possible. You can check for yourself that reduction of the secure context requirements to only CORS conformance and the statement that WebGL now requires textures to be loaded from secure contexts are not pieces of verifiable and trustworthy knowledge for the time being.

I think the original is sufficient

As I've explained, the original is misleading, although not in quite obvious way. I do not have a recipe of how to correct your document. I used the PR form only to raise the issue. Maybe you are overly talkative in this document, and it is sufficient to only mention a testing server with the reference to the article "How do you set up a local testing server?" -- I did not see glaring errors in this article. Maybe you should not talk about secure context and https server at all. Anyway, notice that the Allow edits by maintainers check is marked.

However, students can experience a "user hand gesture" problem when examining sample 8 -- it is your responsibility to decide whether the student should be able to solve this problem on their own, or the issue deserves be mentioned in the tutorial.

Only remember, that the facts you communicate in tutorials can be uncritically accepted as true by freshmen, even when these facts seem to have no direct interconnection with the subject covered.

If you'd like to look for other things to work on, please check for issues labeled good first issue or accepting pr - these have a better chance of being accepted

Thank you, I fear I could not accept your kind invitation for job as I have a habit to make things carefully or not make them at all. I simply have no time for a time-consuming job of technical writer.

Back to my PR: as I usually learn new software technologies directly from the code published or reviewed, I did not read your README document first when occasionally recommended the tutorial to a webgl learner. The request that followed was to teach how to install Python's https (TLS secured) server. So, I finally did read the tutorial README, and now you and I discuss your document.

Please inform me how I can have my PR re-opened.

[bsmth]

Thanks a lot for sharing. I'd also ask for another set of reviewer eyes on it so you have more diverse feedback on this. Pinging @mdn/content-team for a look 👀

[pepelsbey]

I can see where the original intention is coming from, but I agree with @bsmth that the readme doesn’t have to go into so much detail. This is something that just a few people would ever read. I would rather recommend focusing your attention on reference and guides, where you’d be able to achieve a much bigger impact.

[vasilich-tregub]

I edited the document Using textures in WebGL: in particular, removed the phrase WebGL now requires textures to be loaded from secure contexts (because only CORS policy conformance is required, secure context is not mandatory). I made PR#42165 in https://github.com/mdn/content/pulls.
@pepelsbey you may be right that the readme doesn’t have to go into so much detail, but the readme also should not include misleading statements. At minimum, it is sufficient to only mention a testing server with the reference to the article "How do you set up a local testing server?" and then one can remove any words about secure context and https server at all. As for the other stuff, it is at the discretion of the maintainer.