• ExtremeDullard@lemmy.sdf.org
    link
    fedilink
    arrow-up
    6
    ·
    5 days ago

    But these sham community engagement exercises piss me off

    That’s Google for you: they’ve been doing self-serving open-source for decades.

    For instance: they open-sourced Android. That helped Android become the dominant platform and Google capture the cellphone market. Since then, Google has been slowly moving their stuff away from the open-source AOSP and into their proprietary stack, introduced proprietary features that are almost compulsory for a practical, working Android system like Play Protect, and are actively killing deGoogled ROMs.

    There’s only one thing to keep in mind with Google: if they do something, it’s not in your interest, and they know how to play long games. Anything they do will be used against you some day.

    • Arthur Besse@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 days ago

      if they do something, it’s not in your interest

      this is often true, but sometimes (like in this case) they are actually doing things that are in (almost) everyone’s interest: making browsers more secure 🙄

      (see my other comment in this thread for details)

  • Arthur Besse@lemmy.ml
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    5 days ago

    fuck google generally, but in this case that mastodon post’s characterization that “Respondents overwhelmingly reject the suggestion” is not accurate - lots of people in that thread are in favor of removing it and those who aren’t aren’t making a strong case to keep it.

    imo client-side XSLT never needed to be implemented; afaict its primary use is styling RSS feeds and I doubt many people ever actually read RSS feeds styled that way even if millions of feeds are/were.

    some important context here

    tldr: This obscure “feature” is a significant source of vulnerabilities which attackers are able to compromise endpoints with right now. The GNOME project’s libxslt is used by all modern browsers and has been largely unmaintained for a long time, and it is a pretty sure bet that it has lots more remotely-exploitable bugs (in addition to those which have already been discovered and not yet fixed, or for which fixes are not yet widely distributed).

    it sounds like there is also a mostly-working JS replacement for this C++ code; if it is actually possible to ship that and avoid breaking any sites it would be preferable, but, otherwise, i for one would certainly be in favor of dropping browsers’ XSLT support (which was only ever for XSLT 1.0 anyway!) completely ASAP.