4 ms·

> 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 sto

by 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.
- jll29 1y ago
  Porting libxslt to Fil-C could also be an option: https://fil-c.org/invisicaps https://fil-c.org/invisicaps
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.

by imiric 1y ago

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.
jll29 1y ago
Porting libxslt to Fil-C could also be an option: https://fil-c.org/invisicaps https://fil-c.org/invisicaps

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.