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