Removing the polyfill-fastly.io library of webform.libraries.yml

The following change removes the polyfill.io library from the webform.libraries.yml file. This library was being included for older browser support, specifically Internet Explorer 11 and earlier. The removal of this polyfill is necessary to address a security concern where it appears as an auto source in the Content Security Policy (CSP) module, potentially exposing the application to security risks.

That is polyfill-fastly.io not polyfill.io.

🐛 polyfill.io Library is no longer considered safe to use Fixed

In what way is polyfill-fastly.io a security risk?

I understand that the library is only there for compatibility with IE 11. Since that is no longer supported by Drupal core, it should be removed anyway.

That’s not a security reason, to be clear.

What @thony1199 brought up originally is about using a strict Content Security Policy, which can block external network requests. It's best to bring down external libraries, and serve them directly through Drupal.

Whether or not that's the primary concern, it does make sense to remove this library outright. Internet Explorer was retired two years ago on June 15, 2022, and is no longer supported by Drupal. The polyfill is no longer needed.

I agree @Liam Morland and @RobLoach, removing the redundant Polyfill library makes sense. Leaflet and Geofield Map contrib modules recently removed it altogether, since it's not needed anyway.

About using CDN's such as polyfill-fastly.io ... It is safe to use today, but what happens if Fastly is bought up and closed, goes bankrupt, or something else, and the domain is squatted in two years time, just like polyfill.io was ...

As a general observation about managing script libraries, see for example Collapsiblock, which has decided to pragmatically include a needed library in the module, making life easier for the end user:

As of 4.2.0 the slide-element library is now bundled into the built code. It is no longer necessary to mess around with CDNs or downloaded libraries.

From #3392947-8: Update readme to reflect JS library download no longer required → , see also https://git.drupalcode.org/project/collapsiblock#js-library.

In my opinion, it would be prudent to revise the "Policy on 3rd party assets on Drupal.org > Third party libraries" page, which currently says:

Having third party libraries that are hosted elsewhere on the Internet in the Drupal.org repo is strongly discouraged. [...].

From https://www.drupal.org/node/422996#libraries →

It could be relaxed a bit, to something like this:

Third party libraries hosted elsewhere on the Internet can be included in the Drupal.org repo, though it's not recommended.

As I see it, it could ease the burden for module maintainers, and make life easier for module end users, if it wasn't strongly discouraged to include a small library in a contrib module.

Alternatively, the Drupal community could make a handful of Composer packages for the most popular JavaScript libraries, so that module maintainers could require drupal/javascript-library-xyz making sure the end users always get the latest, safest version?

Partially from #3426106-11: Polyfill.io is no longer considered safe and should be removed → , where I got these very valid counter arguments by @mcdruid:

Yeah it's a balance, and I don't think there's a clear "right answer" at present.

Putting a static copy of the library in the module mitigates supply chain risk, but on the other hand if/when a vulnerability is found and fixed in the (upstream) library... we then need to find all copies of it everywhere and update them (or backport the fix).

Which problem is worse?

Referencing dependencies with tools like composer (and perhaps npm in the future?) has the advantage that it makes automated auditing easier (dependabot etc..) and potentially sites can update themselves without relying on Drupal projects doing new releases (that's subject to appropriate constraints being in place, and everyone's interpretation of semver agreeing etc.. etc..)