Remove polyfill.io

[danielmarschall]

There seems to be a supply chain attach which affects OIDplus.

polyfill.io seems to server malware: https://www.borncity.com/blog/2024/06/28/polyfill-lieferkettenangriff-gefhrdet-100-000-webseiten/

(And this is one reason why I hate dependencies so much!)

TODO:

1. We must remove polyfill.io from our source.
2. We must check: How big will the impact be? Are some important methods missing from Edge, Chrome, Firefox, Opera? (Note: Internet Explorer is not supported by OIDplus anymore). In case there is an important function/framework missing, then we must implement it ourselves without relying on polyfill.io

We are using the following polyfills at the moment:

const REQUIRED_POLYFILLS = array(
	// For various AJAX calls
	'fetch',
	'URL',

	// For OIDplusPagePublicWhois.js, OIDplusPageAdminSoftwareUpdate.js, and OIDplusPageAdminColors.js
	'String.prototype.includes',

	// For TinyMCE if it is included inside oidplus.min.js.php ( https://github.com/tinymce/tinymce/blob/5c1702a119e683f93e03ecc2231f11d17ce57395/modules/tinymce/src/core/main/ts/api/EditorManager.ts#L271 )
	'document.currentScript'
);

@wehowski Can you please test if these 4 things exist in

• Chrome
• Firefox
• Edge
• Opera

[danielmarschall]

polyfill.io was taken offline yesterday, so there is no current threat. So we don't need to rush to change the code.

[wehowski]

Hi Daniel,
for everything javascript related https://github.com/frdl/oidplus-frdljs-cdn-proxy-plugin is use

• webpack
• cdn.startdir.de

String.prototype.includes : To use prototypes on 'base classes' is not recommended any more in javascripts?

document.currentScript: I am using this polyfill in my webpack compilation:
https://cdn.startdir.de/%40webfan3/common/index_base.js

The file is a mix with other hacks and sources from stackoverflow and self, when I am home at evening I can extract or find the currentScript polyfill ...

Github nervt mich seit Tagen mit immer neuen Einstellungen die ich für 2f**Auth vornehmen/ergänzen/refreshen soll.

Viele Grüße
Till

[wehowski]

https://github.com/JamesMGreene/document.currentScript

[danielmarschall]

Cloudflare offers an alternative service which we can use: https://cdnjs.cloudflare.com/polyfill/

The 4 polyfills to use for the OIDplus core would therefore be:

https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?version=4.8.0&features=fetch%2CURL%2Cdocument.currentScript%2CString.prototype.includes

Tested browsers:

• Edge (PC) => no output = no polyfills needed!
• Chrome (PC) => no output = no polyfills needed!
• Chrome (iPhone) => TODO: test
• Chrome (Mac) => no output = no polyfills needed!
• Firefox (PC) => no output = no polyfills needed!
• Opera (PC) => no output = no polyfills needed!
• Safari (Mac) => no output = no polyfills needed!
• Safari (iPhone) => no output = no polyfills needed!

[danielmarschall]

Since the 3 biggest webbrowsers support all the features the OIDplus core needs, the question arises "Do we really need polyfill in OIDplus"?

Pro: It might be useful to have it in case we would use some special stuff in the future.

Contra: Possible longer loading times and higher risk (supply chain attacks)

[wehowski]

Hello Daniel,
one reason for me to build all these CDN proxies is to prevent GDPR/DSVGO issues.
It is often recommended to load assets from own origin/CDNs!?
Maybe (I do not looked up now?) it could be a solution to fetch the assets only at setup/install and copy it to the OIDplus (maybe it is how it works already?)??

---

If we need polyfill depends on you want to support older browsers!??
If you ask me personally/for my sites this is NOT recommended (if not easy possible)!??

[danielmarschall]

I do not want to support old versions of browsers, and Internet Explorer is not supported anymore. So polyfill would only be necessary if one browser vendor rejects to implement something extremely special. Maybe someday we want to use a super special cutting-edge feature which only a few browser vendors support?

To solve GDPR issues, OIDplus sends requests through polyfill.min.js.php , therefore the server contacts polyfill, and not the user.

[wehowski]

For any reason, I must look up and remember, there was an issue or more, I removed Opera from my stack of browsers I always install and test? I guess like IE they brew own standards and browsers...!??

[danielmarschall]

@wehowski What is your opinion? Remove polyfilling in the OIDplus core or not?

Just tested with Safari on iPhone and Mac, also does not require polyfilling

[wehowski]

I am not quite sure, but I believe webpack is adding the correct polyfilling by the configuration of browser versions and used features etc. automatically ...?
You could compile an OIDplus javascript on a local machine and add the bundle to the OIDplus core.

I think polyfilling is less necessary since browser manufacturers seem to agree on standards over time!?

[danielmarschall]

I have been thinking about this quite some time, and I think we don't need polyfilling as long as we don't do super crazy cutting-edge things.

Also, the question arises if we would need to do it in the core. The problem is that plugins cannot define their own polyfills.

So, maybe we could make a plugin that does the following:

• Plugintype publicPage
• It is an "invisible" page, like the "anti spam" plugin
• The plugin offers a method "getPolyfills" with the basic 4 polyfills, and asks other plugins via feature interface if they want any additional plugins
• Then calls the cloudflare polyfill service

This way, third-party vendors can use polyfills if they require.

[danielmarschall]

Fixed in version 2.0.1.26.

Polyfills are now outsourced from the core to a plugin.

The feature interface for plugins requesting a polyfill is INTF_OID_1_3_6_1_4_1_37476_2_5_2_3_10.

I also fixed a severe graphical bug which made OIDplus unuseable. (Why did nobody noticed it all the time?)