cultural reviewer and dabbler in stylistic premonitions

  • 11 Posts
  • 26 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle

  • Arthur Besse@lemmy.mltolinuxmemes@lemmy.worldthe perfect browser
    link
    fedilink
    English
    arrow-up
    12
    ·
    edit-2
    2 days ago

    The three currently-maintained engines which (at their feature intersection) effectively define what “the web” is today are Mozilla’s Gecko, Apple’s WebKit, and Google’s Blink.

    The latter two are both descended from KHTML, which came from the Konquerer browser which was first released as part of KDE 2.0 in 2000, and thus both are LGPL licensed.

    After having their own proprietary engine for over two decades, Microsoft stopped developing it and switched to Google’s fork of Apple’s fork of KDE’s free software web engine.

    Probably Windows will replace its kernel with Linux eventually too, for better or worse :)

    How else are Chrome, Edge, Brave, Arc, Vivaldi and co getting away with building proprietary layers on top of a copyleft dependency?

    They’re allowed to because the LGPL (unlike the normal GPL) is a weak copyleft license.

















  • I trust Debian developers far more

    i definitely agree with you here :)

    I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out.

    I found the notion of free software implementing PDF DRM rather hilarious, so I had to know more. First I found this help page which confirms that evince does have code which implements PDF restrictions, but it says that its override_restrictions option is enabled by default.

    But I wondered: when did this get implemented? and was it ever enabled by default? So, I went digging, and here are the answers:

    • in May 2005, the restrictions were implemented in evince in this commit
    • in September 2005, the override_restrictions option was added in this commit, after discussion in bug #305818
    • in December 2006 bug #382700 was opened, requesting that override_restrictions be enabled by default
    • in January 2008, the default changed in this commit - but only after someone pointed out that the PDF spec does not in fact require the restrictions to be enforced. (The spec says “It is up to the implementors of PDF consumer applications to respect the intent of the document creator by restricting user access”) 😂

    I don’t see any indication that Debian patched this out during the time when evince had it enabled by default, but I’m sure they would have eventually if GNOME hadn’t come to their senses :)

    I’ve seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it.

    In my opinion both sides of the Debian–Mozilla trademark dispute were actually pretty reasonable and certainly grounded in good intentions. Fortunately they resolved it eventually, with Mozilla relaxing their restrictions in 2016 (while still reserving the right to enforce their trademark against derivatives which make modifications they find unreasonable):

    Mozilla recognizes that patches applied to Iceweasel/Firefox don’t impact the quality of the product.

    Patches which should be reported upstream to improve the product always have been forward upstream by the Debian packagers. Mozilla agrees about specific patches to facilitate the support of Iceweasel on architecture supported by Debian or Debian-specific patches.

    More generally, Mozilla trusts the Debian packagers to use their best judgment to achieve the same quality as the official Firefox binaries.

    In case of derivatives of Debian, Firefox branding can be used as long as the patches applied are in the same category as described above.




  • It’s not yet fit to protect from malicious apps, but it still finds some use.

    That it is “not yet fit to protect from malicious apps” is an important point which I think many people are not aware of.

    This makes sandboxing something of a mixed bag; it is nice that it protects against some types of incompetent packages, and adds another barrier which attackers exploiting vulnerabilities might need to bypass, but on the other hand it creates a dangerous false sense of security today because, despite the fact that it is still relatively easy to circumvent, it it makes people feel safer (and thus more likely to) than they would be otherwise when installing possibly-malicious apps packaged by random people.

    I think (and hope) it is much harder to get a malicious program included in most major distros’ main package repos than it is to break out of bubblewrap given the permissions of an average package of flathub.