Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Thursday March 09 2017, @05:09PM   Printer-friendly
from the that's-no-battlestation dept.

In Feb/March 2017, we opened a usage survey for anyone to fill out, which was a public request to users, past and present alike, to indicate which parts of Pale Moon should have focus, and to decide in part on development direction. This was done in the spirit of "Your Browser, Your Way"™ -- you, the user, should have a say in what your browser will be shaped like!

This page provides an analysis of the results, and provides our (dev) response to some of the comments our survey respondents left.

[...]

About 80% of the respondents use Pale Moon as their primary web browser to surf the web. The other 20% uses either a different browser or multiple (other) browsers to varying degrees. Of course it is fantastic to see so many users using Pale Moon as their main (or only) web browser of note.

Among our users responding to the survey, the main reasons for not using Pale Moon as their primary browser have been:

      1. Extension compatibility with Firefox extensions. Unfortunately, it's not possible for us to provide exact compatibility with Firefox extensions because we are not Firefox. Because of our different application code, we are also not able to provide compatibility with WebExtensions at this time, because those use HTML for user interface elements instead of XUL. We are, however, working on providing an as broad as possible support for the three main extension formats in use: XUL, bootstrapped and SDK (in the form of PMkit); the technologies that Mozilla is going to completely abandon in November 2017 with Firefox 57.

      2. Website compatibility. As long as websites keep specifically checking for and catering to (specific versions of) only 3 or 4 "mainstream" browsers, you will always have some sites that will not cooperate with using an independent alternative. On the browser side, there is very little we can do to prevent this. As a user, however, you have the power to convince websites to give this attention by contacting webmasters of troublesome sites and making them aware of their restrictions.

      3. "Firefox is more secure". There is still a percentage of people that take arbitrary version numbers as a criterion at face value to determine what is, in their opinion, "outdated" or "insecure". Once more here the affirmation that Pale Moon is most definitely as secure, if not more so, than the current mainstream browsers. Our versioning is also independent of the versioning used by Mozilla. Security vulnerabilities that become known in the Mozilla platform code ar evaluated regularly and ported across if applicable.

      4. "Chrome is faster". This may be, depending on what you use to measure "speed"; in our experience though, there is no significant difference between any of the modern browsers when it comes to real-world speed. In fact, Pale Moon has regularly shown to perform very well in comparison on lower-end computers. Your Mileage May Vary in this respect.

[...]

Pretty much a unanimous vote here (even among the 20% who don't use Pale Moon as their main browser) that extensions are essential to the browser. Totally expected, and maybe Mozilla can draw a lesson from this.

This also underwrites the need for what we've been working on to restore: as much compatibility with Jetpack-style extensions as possible through PMkit.

http://www.palemoon.org/survey2017/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Thursday March 09 2017, @06:13PM (3 children)

    by Anonymous Coward on Thursday March 09 2017, @06:13PM (#477041)

    Did they just assume it was about version numbers?

    Being 64-bit matters. Being fully ASLR-compatible matters. (compiler flags on all object files; linked as a shared object on Linux)

    Enforcing W^X matters.

    JIT randomization matters.

    Using the new memory type register feature on Intel matters.

    Using the new return-address control on Intel matters.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1  
  • (Score: 0) by Anonymous Coward on Thursday March 09 2017, @06:52PM (2 children)

    by Anonymous Coward on Thursday March 09 2017, @06:52PM (#477067)

    As the recent javascript ASLR exploit shows, obfuscation doesn't help solve underlying security issues, and given the false sense of security, programmers are more likely to produce further critical errors which lead to the 'keys to the kingdom' being all the more easy to obtain.

    What is really needed isn't fancy and complex and limited availability security features, from NX to current gen, but rather well thought out, well designed, and well implemented codebases that ensure none of those cornercases happen in the first place. Additionally race conditions may allow opportunities to bypass *ALL* of these protections in some circumstances, which is why only input and display routines should be run in secondary threads, with limited communication between browser instance threads and no threading and only synchronous IO inside of browser window processes. Slower sure but security and verifiability always comes at a cost in performance.

    • (Score: 0) by Anonymous Coward on Thursday March 09 2017, @08:39PM

      by Anonymous Coward on Thursday March 09 2017, @08:39PM (#477115)

      Your approach is no better than a giant corporation, using unauthenticated telnet and FTP and fileshares, that installs a firewall and expects that to save them.

      You are looking for a silver bullet, and there isn't one.

      I didn't say you couldn't convert the codebase to Rust or LISP, or that you couldn't wrap the whole thing in hardware virtualization. Go right ahead.

      There is however no excuse for not making sure that ASLR and NX are working well, along with so many other things of that nature.

    • (Score: 2) by andersjm on Thursday March 09 2017, @10:52PM

      by andersjm (3931) on Thursday March 09 2017, @10:52PM (#477168)

      Pretty weird post. First you lambast mitigation strategies for providing no true profound security. Then you argue for thread compartmentalisation, which, at best, would be the same kind of mitigation strategy.

      I say "at best", because that's the first time I ever heard anyone arguing that threading would improve security. If anything, threading reduces security, because it enables additional side-channel attacks.