Ian Zimmerman <i...@very.loosely.org> wrote:
> On 2018-04-01 09:15, Martin Vaeth wrote:
>
>> noscript, ublock-origin, and https-everywhere (maybe for privacy also
>> coupled with decentraleyes, duckduckgo{-privacy-esesntials},
>> canvasblocker, skip-redirect)I had forgottten to mention: These WebExtensions (and some more) can be installed system-wide with portage using the mv overlay. ;) > Didn't know ublock was available as a webext. This was one of the first extensions which had been rewritten. It is even available for chromium. This (partial) browser independence is another advantage of WebExtensions. However, noscript uses some more advanced APIs which were introduced more recently (and so far only in firefox but not chromium). I do not know the details, but if I understood correctly, ublock-origin can come "too late" in certain cases which could be fixed only by these new APIs: This was the reason, that the WebExtension variant of noscript had been delayed until firefox-57 came out. I have no idea whether current versions of ublock-origin were able to fix these issues. I have a bit experience with WebExtensions in general and must say I like the concept: It gives enough power to program such protection extensions and simultaneously makes it impossible to do malevolent things, unless the extension requests corresponding permissions. Legacy extensions, in contrast, could easily misuse their power and break things (possibly even unintentional in case one of the frequent API changes was happening). Thus, the restriction of APIs indeed has a certain positive effect. > I have been looking at them since I adopted palemoon mid-yesteryear. An alarm sign for me was that palemoon was eventually dropped for android after being practically unmaintained (i.e. with known open security holes) for months/years. A similar alarm sign concerning linux is that they were not able to pull the fixes for the assembler code which relied on undocumented behaviour of <=gcc-5, even months after gcc-7 was out. Even if these problems are not marked as "security" issues, they can easily be some. All in all, despite first I considered palemoon as a good idea, I have removed it since some months for these security considerations. > seems to me almost all are in new code added to FF after the fork, and > moreover in code handling new web "features" which I never use. Experience shows that it is not possible to "hide": Sooner or later a website you do have to use for some reason will require such a feature. Eventually the number of these websites increases. And then you are at a dead end. Nowadays, it has already "practically" become impossible to use exclusively lynx or (e)links; in a while it will be impossible to use a browser which does not support certain new "features". > bundled version of freetype I cannot comment much on this, but palemoon had a lot of bugs if you unbundle libraries. In any case, this is more an ebuild thing than an upstream thing: Unfortunately, unbundling is supported by neither upstream.
