subreddit:
/r/palemoon
submitted 3 years ago byNotTheOnlyGamer
Based on the information released here about the new version: https://www.palemoon.org/releasenotes.shtml , I have some serious concerns about the direction Pale Moon's been taking - veering sharply toward being another Chrome-lite with a different GUI. First we had non-standard JS support (less of an issue since 99% of my browsing in PM has JS disabled) and non-standard CSS support as pre-existing concerns but I could accept for "quality of life" improvements to some users. I still would have preferred a setting for "standards-compliant only", but whatever. Now, in the last version we had this:
That, and the error with the old spellcheck libraries are serious concerns based on why I use PM - to have a secure browser that maintains the parts of classic Firefox which I used; but now, there's this gem in the changelog:
This one line feels like the beginning of the end for Pale Moon as something other than a WASM/WebExtensions Chrome-lite. I am increasingly concerned that we're going to have an Addonpocalypse for PM, just like Firefox did, but lacking the developer support that Firefox had. On top of that, the user is gradually losing control of the user agent again.
We need to have a build that does not include any support for this nonsense in a distribution and update channel.
3 points
3 years ago
Have you tried just unchecking the tickbox and disabling WASM if it doesn't suit you?
Have you tried joining the effort to ensure that XUL Extensions have a vibrant future with all the power in the world to do anything?
No to either? Well then maybe you should re-evaluate your life choices and surrender to your Google masters.
2 points
3 years ago
WASM should definitely be provided by an optional NPAPI plugin with a third-party WASM engine.
2 points
3 years ago
Personal opinion, I don't care if it's first party, third party, or dinner party. But I agree that it should be separate from the core browser so that we as users can decide for ourselves whether it should be part of our vulnerability or not.
1 points
3 years ago*
So how would YOU make this happen? Make a user on first run have to set hundreds of preference states in a seemingly never ending wizard? Eliminating any such thing as a default?
Oh yeah,, You mentioned builds.. So you think it is even remotely feasible to provide builds for Windows (32bit and 64bit), Linux (gtk2 and soon gtk3), Solaris and Illumos, Macintosh (official or contrib) for every configure option and every preference combination.
You literally expect what would likely be something along the lines of thousands if not hundreds of thousands of built and shipped binaries for every new version? All because of one little preference you can flip and almost certainly be done with it?
You do realize if we do it for you we must do it for everyone, every preference, every configuration. Else, how could it ever possibly be fair?
Or perhaps you think we should just make builds to order. Fast Food Browsers, eh? Burger Moon. Made fresh in 45 minutes or less or you're browser is free.. Wait.
So, what is your illustrious solution to this oh so incredibly terrible problem faced by everyone ever and not just you and maybe a few others?
3 points
3 years ago
What I was suggesting with a variant build is that, for a large scale change, which now includes into Pale Moon something which was not there previously, which presents a new and different security concern for the browser, and - most importantly - is an emblematic technology directly related to the reason many users switched from Firefox to Pale Moon, there should be two versions produced.
The suggested build should include everything but the kitchen sink - heck, if you find a way to code a kitchen sink, go for it. But the other should be WASM-free - in many ways, my suggestion is similar to the way that Firefox introduced an option to avoid the controversial WebDRM (EME) at the time that it was first included in the browser. I'm not talking about a build for every possible option; and I don't think anything I've said could be construed that way. Having the ability to change and set options is one thing. But this is a major breaking point, one which had an effect on PM's userbase and acceptance by the browser community at large when Firefox introduced WebExtensions and WASM into the browser.
3 points
3 years ago*
That just isn't a reasonable expectation. Special interest builds are just going to breed more special interest builds and create a nightmare of release engineering, support, etc.
Thing is about WASM is it has been in UXP since it was created and Basilisk had it enabled all the way back in 2018. It isn't like we expressly added the functionality.
As I have already said, the webcompat need has now outweighed the general or personal distaste of the technology or any new risks implied with it. The decision to flip it on for Pale Moon was NOT taken lightly and it was made sure that all known security issues with it were well patched. As well, we are keeping an eye on it.
We are not adopting WebExtensions. I personally ex-ter-min-at-ed WebExtensions at great personal cost actually. The XUL Extension situation has already been explained in another post in this very thread. Please refer to it.
2 points
3 years ago
Special interest builds are just going to breed more special interest builds and create a nightmare of release engineering, support, etc.
Agreed.
1 points
2 years ago
I personally ex-ter-min-at-ed WebExtensions at great personal cost actually.
Why?
2 points
3 years ago*
You sir, don't understand how either technology works.
2 points
3 years ago*
The resources and people are limited, so maintaining a first-party WASM engine isn't feasible. How about improving NPAPI instead?
1 points
3 years ago
You are still ignorant of what and how various technologies work.
1 points
3 years ago*
Are you dense? If not possible currently, then you guys should make a way of implementing a foreign WASM engine. C/C++/Rust code in the context of WASM doesn't even have access to the DOM.
1 points
3 years ago
One. No. Two.. No. Three there is no rust only some left over hooks that need to be cleaned up largely in the stylesheet code. Four. No.
0 points
3 years ago*
What?! I'm not talking about code in UXP, but about Rust, C and C++ code used by WASM web apps. These languages don't have access to the DOM, like JavaScript does. It's you, sir, who don't understand how WASM works.
"I see you went to the Donald Trump School of Communication" - darkempath, 2020
1 points
3 years ago*
And yet you don't understand how the JS engine nor NPAPI works. For that matter the dom code.
I am in general against what WASM as a technology is. Don't make the mistake of confusing retaining or enabling the capability and accepting or promoting the technology.
As a matter of historic fact, I was doing this long before the 2016 election. An election I did not cast a vote in and I didn't much care about.. It only captured my attention on the morning after the election around 1 or 2am eastern and I was watching CNN at the time.
Nice try, but no dice. However, you did give me something very special right there. Insight to your motivations. Thank you. While it won't serve you at all.. It shall serve me in the future very well.
0 points
3 years ago*
Don't make the mistake of confusing retaining or enabling the capability and accepting or promoting the technology
Even if not possible to do a plugin, shipping with a WASM engine from another browser would be good to improve maintainability.
1 points
3 years ago
To address your points:
Are you making a personal guarantee that there will never come a time or a PM update that alters my choice on this? That there will never be a time that the option is removed? And further, are you personally guaranteeing that if I uncheck said tickbox, no user with malicious intent will ever be able to activate any part of that highly dangerous over-privileged code to use it as part of an attack against me? If the answer to that last one is 'no', for security reasons a completely WASM-free build should be deployed as an option for users to pick.
All of the add-on functionality which I need or want already exists, mainly in add-ons from what is now the "Classic Add-on Archive". Why should a user be expected to fix what is not broken?
3 points
3 years ago
Except it is broken, will be broken, shall be broken. No matter what. Pale Moon is not Firefox and never will be again. Extensions target the application not the other way around. Firefox extensions by definition do not target Pale Moon. All XUL Firefox Extensions are unmaintained thus are not updated when things that will change do change.
Why should a user be expected to help ensure a rich future for the technology? Because 99% of the over 19 thousand Firefox Extensions ever created were by Firefox users, not Mozilla and not other companies. While it is true some of these users turned developers eventually started companies to varying degrees.. It sure didn't start that way.
Simple as that.. Firefox users built almost all Firefox extensions and for those who truly understand that history Pale Moon users should take responsibility creating or forking extensions for Pale Moon.
We have a significant advantage that those back in the day didn't have. We have the fruits of their labor to build from be it forks or merely examples on how to do something for use in something new. Almost all Firefox extensions are also open source which means names, icons, ids aside.. Anyone can fork something and breath new life into it.
HOWEVER, if this is not what you think you have signed up for.. Leave now. Run. Run as far as you can because preserving and building on history along the path originally set down by our Netscape forefathers and the true Mozilla brethren of old may simply not be for you.
1 points
3 years ago
highly dangerous over-privileged code
Don't be stupid. The browser has content isolation.
-1 points
3 years ago
Tobin stated:
Well then maybe you should re-evaluate your life choices and surrender to your Google masters.
And there it is, in plain sight, as plain as it gets.
Why should a user be expected to fix what is not broken?
Because, by using Pale Moon, you are "in for the ride." And you are not the driver of the vehicle...that's Moonchild, Tobin, etc. THEY decide where it goes and what it does. Not you. Not Google. Not any or every website out there. THEY decide.
Your browser, your way? No way. You're just a passenger in their resistance movement against Mozilla, Google, etc.
And if, tomorrow, Palemoon fails to work with 99% of the Internet's websites/services because of some change pushed by Mozilla, Google, etc, you can be content knowing that you are a proud member of that resistance movement.
are you personally guaranteeing that if I uncheck said tickbox, no user with malicious intent will ever be able to activate any part of that highly dangerous over-privileged code to use it as part of an attack against me?
Ah, no need to worry about that, my friend. If your favorite websites refuse to load or render properly in Pale Moon, you won't be using Pale Moon to access those websites in the future, eh? Therefore, no future risk of malicious code being run by it, right?
PROBLEM SOLVED! Or, in Tobin-speak: "WON'T FIX" "CLOSED"
1 points
3 years ago
Muh 99% of websites
Almost all of my browsing is done with javascript disabled. I don't need 99% of websites to work. I just need to read them. If you cannot tell the difference between the last two sentences, you are too stupid to comment on the purpose of Palemoon.
If you want your 99% websites to work use Firefox. Palemoon is not Firefox.
-1 points
3 years ago
Perfect!
Welcome to Pale Moon: Your Browser, Your way
Welcome to Pale Moon: Our Browser, Our way. If you want your 99% websites to work use Firefox. Palemoon is not Firefox.
MUCH better.
0 points
3 years ago
Welcome to Pale Moon: This browser will render text, images and videos as much as it can adhere to standards. It will not try to imitate Google or Mozilla for the latest fad technology of using web.
PS: Javascript, WASM, WebExtensions are not text, images or videos.
4 points
3 years ago*
Oh and as for WASM or preferences in general. There are only three ways that your setting could be disregarded on update.
Turn WASM off if it suits you. There are very legit reasons for doing so.. But there were other reasons to make it default on. We didn't, in this case, LIKE it when the situation called for it to be enabled but then again that is why it is a preference that can be set.
You could, however, continue to doom-say and freak out and turn negative like others in this thread. That's fine.
-OR-
You can enlighten yourself to what is and what could be and realize that you will always have a choice and that sometimes choices have consequences and that all choices, most definitely, have trade-offs.
1 points
3 years ago
I'm fine with the default change issue (in spite of occasional frustrations), I've lived with it since the day I switched from Navigator to Communicator, and again when I migrated to SeaMonkey and then back to FF+Thunderbird and now to PM+Interlink. I'm aware of the logic behind why it works the way it does and frankly, I'm aware that it would be an astonishingly huge hassle to set a subkey that defines user-set vs. default for basically no benefit. That's actually part of why I read changelogs as closely as I do. So thank goodness for Netscape teaching me good user practice.
When a preference changes in a way that means I have to go check that my choice has been respected (by the software update - not the dev team), I do trust the developers of this software to ensure that a changelog entry will be there to alert the user base to go do that. I wouldn't be using PM if I didn't trust you all - which is why something that goes so strongly against type gets me very worried.
But I'm still not seeing a real guarantee that "turning it off" totally removes the security risk, or the potential performance challenges.
Honest question: Are you sure that I'm overreacting?
Are you certain that when I turn it off, it stays totally dormant and doesn't expose me to risks or challenges? If you're sure and you've tested it and you know that with that box unticked, no WASM-related code will be live in the browser, and that you know for a fact there will be no changes either to my risk profile or my experience, I'll trust your word on it.
I accept that I may well be overreacting. But the PM team introducing WASM feels to me almost as incomprehensible as, say, introducing Australis interface would be. Most of the time when PM adds something, it's incremental to functions already present, and follows the mindset of being unique from current FF and Chrome, but allowing compatibility when needed. The addition of WASM isn't incremental and I don't feel there's been nearly enough explanation of why this is necessary; that's a major part of the concern I have. And as I said, it's emblematic of why people left FF on top of being a real risk - you said yourself, there are valid reasons not to want it around.
5 points
3 years ago*
I am absolutely sure that when disabled it is disabled and nothing expressly WASM that might go wrong will go wrong when disabled. (If that wasn't the case then there has been a problem for years, but that is not the case.) We will NOT be removing the preference or the ability to disable it at runtime.
There are a few reasons why we won't be. One is of course, if you know you don't need it or have the same concerns we do about it security wise then it should be able to turn it off.
The second is applications can opt-out of having it on by default. Such as Interlink which has no real need for it. As you likely read in the Release Notes or the commit log.
Why do you think it wasn't switched on from day one? There ARE concerns about it though we know that all known exploits are good and patched but new ones could come up and we could advise people to switch it off until the next patch or whatever. The reason it was turned on was simple.. Massive web compatibility reasons. With keeping up on security issues and the webcompat issues without it enabled growing we just couldn't keep ignoring it. But the preference will be retained forever. I'll see to it. For the record, Basilisk HAS had it on since day one.
Anyway, glad to see you might be more level-headed than you may have seemed at first glance.
5 points
3 years ago
What? You mean Pale Moon isn't really "Your browser, your way?" That it isn't really "offering full customization and a growing collection of extensions and themes to make the browser truly your own?"
I'm shocked!
But in all seriousness, while you're certainly not alone in your concerns, I wouldn't delude yourself that it's going to get any better. The truth is that what YOU may want the browser to do and be is likely quite different from what Moonchild, Tobin, and others developing it want it to do and be.
The direction Pale Moon will be taking? Answer: Their browser, Their way.
Plan accordingly.
0 points
3 years ago*
[deleted]
0 points
3 years ago
I still think it is Latitude.
4 points
3 years ago
No. u/GoldJello and u/BronzeJello are Latitude.
2 points
3 years ago
Then who is Golden12345?
0 points
3 years ago
I'm...ME. As in, not "Latitude."
As I've said before, I don't know much at all about "Latitude." I've seen the name around but couldn't tell you much of anything beyond that.
And, as I've said before, I have no idea what his writing style is but can only guess that it's similar enough to mine to...trigger familiarity? But, personally, assuming that temer171 is correct that he uses GoldJello and BronzeJello. I can't see any similarities in their post histories and mine.
2 points
3 years ago*
This one line feels like the beginning of the end for Pale Moon as something other than a WASM/WebExtensions Chrome-lite.
I've actually switched to mostly using Waterfox Classic, since Pale Moon (and cunts like Tobin) have progressively been giving me the shits.
But in this case you seem to be conflating wasm with webextensions. Webassembly is a recommendation from the World Wide Web Consortium (just like HTML, CSS, and Javascript), whereas webextensions are ineffectual garbage from the world's largest advertising company.
Pale Moon has its issues (mostly its developers), but calling it Chrome-lite seems a bit harsh.
We can talk all day long about how shitty the implementation of Pale Moon's non-compliant CSS and Javascript are. However, just like wasm, these are W3C standards that should be available in any functioning modern browser. The fact that Tobin has a hundred and one excuses for why Pale Moon's implementations are sub-standard does not mean a browser like Pale Moon shouldn't support CSS, Javascript, or wasm.
1 points
3 years ago*
The fact that Tobin has a hundred and one excuses for why Pale Moon's implementations are sub-standard
Yup.
1 points
3 years ago
I can only give you facts dude. It is up to you what you do with them.
1 points
3 years ago*
[deleted]
1 points
3 years ago
So, mistreating me is just fine when it is out of the blue is it?
Using your other thread title as your last resort because you have lost not only this argument but that one too doesn't help build your credibility.
Anyway, as I said there.. JustOff is a particularly special case. There is a lot of history there.
And as for G4JC, you don't have all the facts.
all 36 comments
sorted by: best