5 ms·

It's truly troubling to see a trillion dollar corporation claim that the reason for removing a web browser feature that has existed since the 90s is because the

by imiric 1y ago

It's truly troubling to see a trillion dollar corporation claim that the reason for removing a web browser feature that has existed since the 90s is because the library powering it was unmaintained for 6 months, and has security issues. The same library that has been maintained by a single developer for years, without any corporate support, while corporations reaped the benefits of their work. Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ https://xkcd.com/2347/ situation. It would cost Google practically nothing to step up and fix all security issues, and continue maintenance if they wanted to. To say nothing of simply supporting the original maintainer financially. But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?

bawolff 1y ago
> Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ https://xkcd.com/2347/ situation. I think https://xkcd.com/1172/ https://xkcd.com/1172/ is more fitting. > But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed? No, because xml has meaningful usage on the web. The situations are very different.
- imiric 1y ago
  > No, because xml has meaningful usage on the web. The situations are very different. They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1] If security and maintenance are a concern, then they should definitely also remove XML, since libxml2 has the same issues as libxslt. [1]: https://news.ycombinator.com/item?id=45873787 https://news.ycombinator.com/item?id=45873787
  - TingPing 1y ago
    There are more xml parsers than just that and it’s a smaller scope to rewrite or maintain.
  - jll29 1y ago
    Google says: > Similar to the severe security issues in libxslt, severe security issues were recently reported against libxml2 which is used in Chromium for parsing, serialization and testing the well-formedness of XML. To address future security issues with XML parsing In Chromium we plan to phase out the usage of libxml2 and replace XML parsing with a memory-safe XML parsing library written in Rust Perhaps there are some Rust gurus out there that can deliver a XSLT crate in a similar fashion, which other folks can then integrate? The problem seems to be that the current libxslt library is buggy due to the use of C++, an unsafe language (use after free etc.). [BTW, Chris Hanson's old book "C: Interfaces and Implementations" demonstrated how to code in C in a way that avoids use after free: use pointers to pointers instead of pointers and set them to zero upon free-ing memory blocks; e.g. /* source: https://github.com/drh/cii/blob/master/src/arena.c */ void Arena_dispose(T *ap) { assert(ap && *ap); Arena_free(*ap); free(*ap); *ap = NULL; /* avoid use after free */ } ]
    - bawolff 1y ago
      > Perhaps there are some Rust gurus out there that can deliver a XSLT crate in a similar fashion, which other folks can then integrate? Even if one existed right now, i would be surprised if that changed googles mind.
      - imiric 1y ago
        Agreed. Because this decision has nothing to do with safety or low usage, like they claim. It's just another example of a corporation abusing their dominance to shape the web according to their interests.
        bawolff 1y ago
        At the request of their competitor...
      - jll29 1y ago
        Just fork out an OpenChromium branch that adds in the new implementation. Whoever will want to remain compatible to open Web W3C recommendations can develop that branch.
  - bawolff 1y ago
    > They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1] Meaningful usage being a factor does not mean it is the only factor. I think it goes without saying that google isn't going to remove support for xml (including things like SVG) anytime soon.
ExoticPearTree 1y ago
> Will we also see support for XML removed? Hopefully YES. Let the downvotes come, I know there are XML die hard fans here on HN.

by imiric 1y ago

bawolff 1y ago

> Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ https://xkcd.com/2347/ situation. I think https://xkcd.com/1172/ https://xkcd.com/1172/ is more fitting. > But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed? No, because xml has meaningful usage on the web. The situations are very different.

imiric 1y ago
> No, because xml has meaningful usage on the web. The situations are very different. They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1] If security and maintenance are a concern, then they should definitely also remove XML, since libxml2 has the same issues as libxslt. [1]: https://news.ycombinator.com/item?id=45873787 https://news.ycombinator.com/item?id=45873787
- TingPing 1y ago
  There are more xml parsers than just that and it’s a smaller scope to rewrite or maintain.
- jll29 1y ago
  Google says: > Similar to the severe security issues in libxslt, severe security issues were recently reported against libxml2 which is used in Chromium for parsing, serialization and testing the well-formedness of XML. To address future security issues with XML parsing In Chromium we plan to phase out the usage of libxml2 and replace XML parsing with a memory-safe XML parsing library written in Rust Perhaps there are some Rust gurus out there that can deliver a XSLT crate in a similar fashion, which other folks can then integrate? The problem seems to be that the current libxslt library is buggy due to the use of C++, an unsafe language (use after free etc.). [BTW, Chris Hanson's old book "C: Interfaces and Implementations" demonstrated how to code in C in a way that avoids use after free: use pointers to pointers instead of pointers and set them to zero upon free-ing memory blocks; e.g. /* source: https://github.com/drh/cii/blob/master/src/arena.c */ void Arena_dispose(T *ap) { assert(ap && *ap); Arena_free(*ap); free(*ap); *ap = NULL; /* avoid use after free */ } ]
  - bawolff 1y ago
    > Perhaps there are some Rust gurus out there that can deliver a XSLT crate in a similar fashion, which other folks can then integrate? Even if one existed right now, i would be surprised if that changed googles mind.
    - imiric 1y ago
      Agreed. Because this decision has nothing to do with safety or low usage, like they claim. It's just another example of a corporation abusing their dominance to shape the web according to their interests.
      - bawolff 1y ago
        At the request of their competitor...
    - jll29 1y ago
      Just fork out an OpenChromium branch that adds in the new implementation. Whoever will want to remain compatible to open Web W3C recommendations can develop that branch.
- bawolff 1y ago
  > They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1] Meaningful usage being a factor does not mean it is the only factor. I think it goes without saying that google isn't going to remove support for xml (including things like SVG) anytime soon.

ExoticPearTree 1y ago

> Will we also see support for XML removed? Hopefully YES. Let the downvotes come, I know there are XML die hard fans here on HN.