Beautiful response.
If you absolutely must have an XUL-based Firefox derivative: 1) you don't, 2) stop, and 3) don't use this one if you don't listen to #1 or #2.
But I reject the square-peg premise you're trying to jam into that round hole anyway, as it's not a democracy, either. Your choices impact your neighbors without their consent. It's not about fucking over power users or whatever the weird little epistemic enclosure you come from wants to insist it is, it's about addressing technical debt both in terms of performance and security--and the latter matters quite a lot in terms of not enabling people who think they're power users to 1) blow their own leg off, and 2) blow the legs off the people next to them. That's why those "leftist fascist" evil scary Firefox people decided "hey, let's patch some of these up."
Customization, in and of itself, is fine (modulo the combinatoric explosion that leads to security holes). Few enough people would disagree with that, though I understand that the aforementioned epistemic closure holds as axiomatic that everybody just hates the tweaker types. On the other hand, customization at the expense of competent security development, which is what you get with Pale Moon, is not. And seeing as how there certainly doesn't seem to be much in the way of developer competence, to the point where "don't use the stuff that upstream has working just fine because we can't figure it out" is a legitimate attempt at "discussion", it ought to be dumpstered.
Somehow, this "power user" (god, I hate that term) gets by just fine with poor, benighted Firefox--having switched to it from Chrome/Safari after Quantum because it finally felt as pleasant to use as back in The Day. Clearly, though, that just makes me a radical-left SJW hater or something. But that's fine. Modern Firefox is heckin' great.
https://github.com/privacytoolsIO/privacytools.io/issues/375...
> There also seems to be a small group of devout followers who travel from the Palemoon forums to other parts of reddit, HN and github to spruik the project and derail criticism. I've observed (without naming names) it's the same names doing it over and over again.
They always use the same phrases too "nazi" and "fake news", "false narrative" etc. They tend to refer to themselves as "power users" with a clear tone of superiority to their comments.
I guess it must be the deep state! (sarcasm).
(And nobody is falling for your "leftist Nazi" shtick. It's quite telling that you can't even come up with terms for your imaginary opponents and have to fall back on misusing "fascist", "nazi", and "dictator", isn't it?
Here, in the interest of the English language, are some actual left-wing baddies you can use: Bolsheviki, Stalinist, Stasi, Politburo, Khmer Rouge, ETA (potential for puns here), (Popular|Democratic|Worker's) (Front|Army|Committee|Union) for (Liberation|Democracy|A Better Future|Legalisation)
Web applications are fully isolated and sandboxed, have fine-grained permissions, are easy to inspect, and the runtime is built with a modern threat model.
ChromeOS is probably the most secure desktop OS for this reason.
I want my browser to expose more functionality to web apps, because it means that I have to run less random unsandboxed code on my underlying OS.
An app on my smartphone or - much worse - an Electron app "sandboxed" in a flatpak on my desktop has access to far wider range of dangerous APIs than a web application. What's wrong with a browser as a high-level OS?
I don't mind Chrome OS and love my chromebook.
Some of this is aesthetic so I don't really expect to change minds, but if we lived in the world of "Life and Death of Javascript" and booted to some kind of Web OS I'd be annoyed at the loss of low level hackibility and get over it.
Booting to Linux, then booting a browser to get to a normal app that doesn't need network connectivity "feels" wrong.
If they took a Xerox approach, ChromeOS would have a tiny mikrokernel, hypervisor type 1 style, and jump directly into Chrome.
I value discoverability and comprehensibility of the underlying platform a bit more, and have recognized that isn't likely to happen any time soon.
Until they're delivery vehicles for obfuscated wasm to canvas rendering applications. Then nothing of the "web as graph of hypertext documents" will be left.
(also, wasm changes nothing here, you could always obfuscate js just as much)
It is a significant change because it lowers the bar to create a blackbox. wasm offers the performance, canvas provides an opaque, flexible render target. Without either you're limited to obfuscating your JS (which indeed already happens) and obfuscating your DOM (also happening). But the DOM still leaves enough surface for adblockers and other extensions to intervene. Perhaps throw in a websocket/webrtc to channel all your data over a single connection and you basically have created a single intransparent blob which extensions cannot interact with on the behalf of the user.
You turned the user agent into the site's agent.
> "DRM will be used even for text!!1" (wrt. EME especially)
I am not aware of EME offering a data path to bring encrypted text to the screen. Without such a path these claims have no merit, wasm + canvas on the other hand offer a clear path.
Once it's an application instead of a document the text just isn't there.
I would actively block Pale Moon if I thought I worked with people silly enough to use a slow single-process browser in 2020. (Instead of a moderately slow multi-process browser. But I digress.)
Somebody seems to be doing something right.
Provide evidence.
Here's the output:
$ sha256sum palemoon-bin
0b7f4ad73fc671e20bfb2366aa9d9ad81e82a3c8f63acde7f37063e73fda2141 palemoon-bin
$ checksec --file=./palemoon-bin --output=json --extended | jq
{
"./palemoon-bin": {
"relro": "partial",
"canary": "no",
"nx": "yes",
"pie": "no",
"clangcfi": "no",
"safestack": "no",
"rpath": "no",
"runpath": "no",
"symbols": "no",
"fortify_source": "no",
"fortified": "0",
"fortify-able": "15"
}
}
Mitigations and sandboxing are the difference between an exploit a CTF player can write on an afternoon, and a multi-month expert-level endeavour.
This whole project appears to be a security disaster and nobody should use it.