SEC: replace polyfill.io with Cloudflare equivalent - #16629

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

I think this only affected a doc example? So I'll defer to @nstarman . Thanks!

We should definitely not be recommending a supply-chain attack to users 🙅

It should also be backported. Since this PR is already merged, how do we do that?

It also highlights the dangers of supply-chain attacks by using any js library. While the alternative in this PR (cloudflare) is trustworthy, we should keep our attack surface small by avoiding js code that's not absolutely necessary. In this particular case, I see why MathJax is needed, but do we really need polyfill at all?
If it just gives up some performance is one html code example or compatiblity with some really old browsers, then we might just remove it altogether.
I'm not an html/js expert, but it seems to me that just loading mathjax alone should be sufficient.

Let me give it a try:

@meeseeksdev backport to v6.1.x

Awww, sorry neutrinoceros you do not seem to be allowed to do that, please ask a repository maintainer.

I thought so. Well, now you know how to do it @hamogu :)

@hamogu Adding an integrity attribute to the script tags usually does the trick (example below). Even if there's a supply-chain attack, that maximum damage would be a broken application. Although this wouldn't work in case of polyfill.io since the JS it sends back depends on the User-Agent header. So the hash would be different depending on the browser 🤷.

<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

@meeseeksdev backport to v6.1.x

Thanks, @hamogu !

@nstarman , can we remove polyfill ?

@tnfssc That approach also comes with a cost: While it prevents a supply-chain attack, it increases the maintenance burden because you can't just link to the "most recent bugfix version" of any library, but any update has to be manually validated. Of course, in some sense that's the whole purpose - but we're not js experts and in many cases will pretty much have to rubber-stamp whatever update the js library does. In addition, there is a significant time-lag. Astropy is released only every 6 months or so, and older versions are in use for years after that for a typical user. If we link to the "most recent version" all those old users will get the most recent bug and security fixes on any js library we link to - if we select a fixed version, that reduced supply-chain attacks like this, but might deliver libraries dangerously out of date by the time a user uses it.
(It's a bit less of a problem here, since this is more a documentation example and not code people run straight up, but there are a few other places in astropy where we interface or use with js libraries.)

@pllim I do think we can remove the link entirely as its only for compatibility with old browsers. https://docs.mathjax.org/en/latest/web/start.html#browser-compatibility

I vote to just remove it then. People nowadays can probably debug old browser problem via the power of Internet anyway.