Pale Moon 28.12.0 (32-bit)

What's new in this version:

Changes/fixes:
- Added controls for WASM to the browser's preferences, and enabled by default
- Enabled various arbitrarily-disabled CSS functions
- Added the use of basic path descriptors (i.e. polygon) to css clip paths
- Implemented multithreaded request signal handling for the Abort API. Please see implementation notes below
- Updated the included US-English dictionary, adding approximately 2500 additional words
- Removed the DOM battery API. This was already disabled for privacy reasons for a long while
- Fixed an erroneous warning displayed on toolkit-only add-ons like supplied dictionaries
- Fixed an issue with the sessionstore tab load preference
- Improved the generation of the names of downloaded files to prevent confusion
- Fixed a code issue with base64 encoding of data
- Fixed 2 safety hazards in JavaScript
- Fixed a spec compliance issue with regards to the cross-origin loading of scripts
- Improved the loading of a system DLL on Windows, preventing low-risk hijacking
- Unified XUL Platform Mozilla Security Patch Summary: 4 fixed, 2 defense-in-depth, 15 not applicable

Implementation notes:
- In 28.11.0, we introduced the Abort API as new code. The implementation of it still had an issue where especially web workers would not always see the availability of abort signals on fetch requests while AbortSignal was implemented in the browser. This effectively made some websites (especially those using a particular polyfill for the Abort API that would detect the need to polyfill by way of Request.signal) throw errors that were fine before. We offered users a workaround by temporarily disabling the AbortController in the browser by way of a preference (dom.abortController.enabled).
- v28.12.0 fixes the multi-threaded handling of signals, which should solve these problems. As such, the workaround is no longer needed and upon upgrade the preference will be reset to enable AbortControllers again.
- DLL-hijacking on Windows would only be possible if a malicious actor already either gained administrative access to the program's installation folder or otherwise have unrestricted access to the program folder (by having it installed in local application folders inside the user's profile space or other insecure program locations). In that case the system is already compromised and any executable can be replaced, so having dll loading hijacked would be the least of your concerns (i.e. the main program .exe could also be replaced/infected in that case).