Setting the real base URL (rather than using a file URL pointing to the app's Resources folder) allows relative URLs to work correctly within the article, such as for images, and is compatible with Cross-Site-Origin policies that restrict use of resources outside of the origin domain.
It also implicitly eliminates access to the local file system from within the webview, as the use of a non-file base URL makes WebKit treats the webview's content as being from a remote server, and its default security policy is to then disallow local file access (except with explicit user action, such as drag-and-drop or via an `input` form element).
Note: the base URL is currently typically taken from the feed itself (specifically the "link" feed (channel) metadata). That is controlled by the feed author (or a man-in-the-middle attacker). It should perhaps be validated to ensure it's actually an HTTP/HTTPS URL, to prevent security problems.
The app-specific JavaScripts - used for fixing styling issues and the like - are now formally loaded as extensions to the web page, "user scripts" in WebKit parlance. They're isolated to their own JavaScript world - meaning they can't be seen or manipulated by JavaScript from the feed article itself, and are more secure as a result.
Fixes#4156.
Co-Authored-By: Brent Simmons <1297121+brentsimmons@users.noreply.github.com>
These changes are the bare minimum required to get footnotes to appear and function on the article page.
* The newsfoot.js script now wraps everything in an IIFE to prevent bleed to other scripts
* Stylesheets are included in the main stylesheet, with the colors extracted out into separate selectors
Currently missing the arrow pointing to the footnote link, and no consideration exists for mobile presentation
beyond a max-width: 100vh on the footnote popover.
