chaosmonk wrote:- If I understand correctly, Iceweasel-UXP is based on Basilisk. Is it a hard fork or does it receive updates from upstream? Is the appropriate place to submit bug reports and features requests Hyperbola's issue tracker or upstream's?
Please submit all bug reports to our bug tracker. If it is an upstream issue we will correlate with upstream. It is a soft-fork of Basilisk as we're working pretty closely with them at the moment. We do have some different application goals, primarily removal of DRM and some different privacy and security defaults, but both of us are working towards the same goal of keeping XUL alive and patched with security updates. All of the toolkit (browser engine) portion of Basilisk changes are also applicable for Iceweasel-UXP. You can have a look at UXP's recent changes here.
chaosmonk wrote:- Is it appropriate to request backporting of Firefox >=52 (last pre-Quantum ESR) and/or >=57 (post-Quantum) features that do not rely on WebExtensions or otherwise conflict with Hyperbola's goals?
The WebExt code is radically different, so anything pre-FF52 we can have a look at and in some (rare) cases we can backport post-Quantum stuff by either inventing it from scratch or borrowing the few relevant bits that are not dependent on it. I'd rather not reinvent things from scratch, but others are certainly welcome to do so. If you're going to submit a bug report I prefer you link to the last known XUL (legacy) version and we can go from there.
chaosmonk wrote:- I did not see NoScript in the Iceweasel addons page
For addons we are currently bundling, they are included in the package repository directly. This may change once upstream implements a shared addons database for UXP applications. You can find our NoScript package here. There are some patches we've applied, primarily removal of Google, some networking pings, and the whitelist. We do not feel the whitelist should auto-populate every time the addon starts, as many of the websites listed are running non-free JavaScript and can open you up to security vulnerabilities, so we disable this and let the user decide what should be whitelisted. See the current patch here.
I'll update the wiki to clarify this.
chaosmonk wrote:I was referring to other features of Firefox, such as privacy-enhancing patches implemented as part of the Tor Uplift Project.
I'm currently monitoring these. Many of them do not currently apply to us as they are for post-Quantum design and/or are incomplete.
We're not currently trying to compete with Tor browser, as it requires a significant rewrite of the HTTP layer that was optimized for Tor. Mozilla has not fully gotten on board with that either which is why Tor browser continues to exist.
Their modifications include longer proxy timeout defaults and GUI changes to mark all onions as "secure" with a green lock regardless of whether or not they run HTTPS. There is also the Tor Browser button, which works exclusively with their browser and uses their custom networking layer to open a new circuit per page and set a bunch of default about:config options with a slider.
I currently recommend using different Profiles for extra privacy. You can launch iceweasel-uxp with --ProfileManager and you can have one for banking/personal, and one for every day browsing.
We have back-ported some important items such as disabling SSLKEYLOGFILE which is a patch borrowed from Tor that prevents local SSL stripping. See here for more details.
chaosmonk wrote:I only mentioned xprop's output because I think that the WM_CLASS value might have something to do with why the icon and titlebar say "Firefox".
I'll try to reproduce and fix this for the next release, thanks for the report.