8 ms·

XML? Be cautious

90 points by bemmu 9y ago

abruzzi 9y ago
Interesting. I was going to email the link to some co-workers that work with XML frequently. I wrote a nice little email with the link, then decided to put the text of the billion laughs attack into the email. Select the full XML in the browser, change to the email client and past, and the client immediately becomes unresponsive. I open up "Activity Monitor" and the clients memory consumption is rising precipitously, and was at 19gb when I killed it. Microsoft Outlook 2016 for Mac. I was really surprised that an email client would try to interpret the XML rather than just displaying it as text.
- mdavidn 9y ago
  The same thing happened in JetBrains IDEs until about a year ago. I remember having to save my XML bomb unit test in a *.txt file to avoid freezing my IDE.
- Arnavion 9y ago
  Maybe it was trying to be helpful - detected you were pasting XML and tried to pretty-print / colorize it.
  - sebazzz 9y ago
    For that a parser without any intepretation would be sufficient.
zackbrown 9y ago
> Simple structure, a little too verbose The "too verbose" bit is overly broad cargo-cultism. XML has valid, efficient applications. A prominent one: it's a more concise serialization format than JSON (the supposed alternative) for describing self-similar typed hierarchies, e.g. scene graphs or other UI trees. (see HTML, XAML, VRML, kind-of JSX.) consider: <div> <span>Hello world</span> <div> vs: { nodeType: "div", children: [ { nodeType: "span", children: [ { nodeType: "text", value: "Hello world" } ] } ] } It's hard to take the rest of the article seriously when it starts with that unnecessary (and imprecise) jab at the technology it purports to be educating about.
- skybrian 9y ago
  There are more concise ways to use JSON. For example: ["div", ["span", "Hello world"]] You can also add attributes: ["div", {"id": 123}, ["span", "Hello world"]] Parsing is a bit trickier and the format is less obviously extensible, but in general, JSON arrays are more concise than JSON objects since you can leave out the field names.
  - beagle3 9y ago
    Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)
    - skybrian 9y ago
      When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.
      - ajanuary 9y ago
        I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
      - beagle3 9y ago
        Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
      - shakna 9y ago
        > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html
anyfoo 9y ago
The idea of XML, namely typed, semi-structured data with namespaces, was a good one. What sucks is the particular implementation chosen. XML is implemented using SGML, a completely archaic, overly general beast that gives us DTDs, entities and countless other warts that make exhaustively parsing and handling XML the insurmountable pain that it is. Seriously, I urge you to look into SGML and to explore what a weird behemoth it is, and to then realize that SGML is what XML grew out of. Unfortunately, XML was so bad that the developer community suffered some form of whiplash from it, and promptly decided to run into the opposite direction: JSON, which--superficially at least--seemed to be the simple and easy answer to the problems XML was causing. However, I don't think that XML's problems were in its ideas, but that JSON is taking away too much that had only been perceived as bad, because it came coupled to such a flawed implementation overall. And now we have efforts like JSON Schema, which emerge out of the realization that writing the same typecheckers over and over again for nearly every use case is tedious at best, and error-prone and unsafe at worst. So maybe we will get our conveniently typed and namespaced semi-structured data in the end, but I blame XML that we had to take a detour over vanilla JSON to eventually get there.
- xchaotic 9y ago
  "conveniently typed and namespaced semi-structured data in the end" - I don't think that thing will be much more simple than XML - it needs to cover Unicode, data types, namespaces, modularity and you end up with XML-level of complexity. I know wheel gets reinvented a lot in software, but with data formats you also need tools, adoption, compatibility - XML wins here
  - anyfoo 9y ago
    It might not be very simple, but I certainly hope it does not necessarily imply SGML levels of cruft. The things you have covered don't need any of that cruft. You are right that adoption is a major hurdle for any new solution, if it's even attainable, but that's pretty much my point. I'm sad that XML came to reach critical adoption for semi-structured data, and not something else.
  - pllbnk 9y ago
ams6110 9y ago
Sites that hijack the "back" button -- be cautious.
- saagarjha 9y ago
  …this is a Medium article.
  - kuschku 9y ago
    And it still hijacks the back button, and therefore shouldn't be read.
otabdeveloper2 9y ago
XML is not a serialization format. It's a structured document format. For, you know, human text and stuff. When used as intended it is wonderful.
ak217 9y ago
If you're handling XML in Python, defusedxml (https://pypi.python.org/pypi/defusedxml https://pypi.python.org/pypi/defusedxml) is a nicely packaged set of XML parser configurations that mitigate attacks in untrusted XML.

90 points by bemmu 9y ago

Interesting. I was going to email the link to some co-workers that work with XML frequently. I wrote a nice little email with the link, then decided to put the text of the billion laughs attack into the email. Select the full XML in the browser, change to the email client and past, and the client immediately becomes unresponsive. I open up "Activity Monitor" and the clients memory consumption is rising precipitously, and was at 19gb when I killed it. Microsoft Outlook 2016 for Mac. I was really surprised that an email client would try to interpret the XML rather than just displaying it as text.

mdavidn 9y ago
The same thing happened in JetBrains IDEs until about a year ago. I remember having to save my XML bomb unit test in a *.txt file to avoid freezing my IDE.
Arnavion 9y ago
Maybe it was trying to be helpful - detected you were pasting XML and tried to pretty-print / colorize it.
- sebazzz 9y ago
  For that a parser without any intepretation would be sufficient.

zackbrown 9y ago

> Simple structure, a little too verbose The "too verbose" bit is overly broad cargo-cultism. XML has valid, efficient applications. A prominent one: it's a more concise serialization format than JSON (the supposed alternative) for describing self-similar typed hierarchies, e.g. scene graphs or other UI trees. (see HTML, XAML, VRML, kind-of JSX.) consider: <div> <span>Hello world</span> <div> vs: { nodeType: "div", children: [ { nodeType: "span", children: [ { nodeType: "text", value: "Hello world" } ] } ] } It's hard to take the rest of the article seriously when it starts with that unnecessary (and imprecise) jab at the technology it purports to be educating about.

skybrian 9y ago
There are more concise ways to use JSON. For example: ["div", ["span", "Hello world"]] You can also add attributes: ["div", {"id": 123}, ["span", "Hello world"]] Parsing is a bit trickier and the format is less obviously extensible, but in general, JSON arrays are more concise than JSON objects since you can leave out the field names.
- beagle3 9y ago
  Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)
  - skybrian 9y ago
    When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.
    - ajanuary 9y ago
      I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
    - beagle3 9y ago
      Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
    - shakna 9y ago
      > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html

anyfoo 9y ago

The idea of XML, namely typed, semi-structured data with namespaces, was a good one. What sucks is the particular implementation chosen. XML is implemented using SGML, a completely archaic, overly general beast that gives us DTDs, entities and countless other warts that make exhaustively parsing and handling XML the insurmountable pain that it is. Seriously, I urge you to look into SGML and to explore what a weird behemoth it is, and to then realize that SGML is what XML grew out of. Unfortunately, XML was so bad that the developer community suffered some form of whiplash from it, and promptly decided to run into the opposite direction: JSON, which--superficially at least--seemed to be the simple and easy answer to the problems XML was causing. However, I don't think that XML's problems were in its ideas, but that JSON is taking away too much that had only been perceived as bad, because it came coupled to such a flawed implementation overall. And now we have efforts like JSON Schema, which emerge out of the realization that writing the same typecheckers over and over again for nearly every use case is tedious at best, and error-prone and unsafe at worst. So maybe we will get our conveniently typed and namespaced semi-structured data in the end, but I blame XML that we had to take a detour over vanilla JSON to eventually get there.

xchaotic 9y ago
"conveniently typed and namespaced semi-structured data in the end" - I don't think that thing will be much more simple than XML - it needs to cover Unicode, data types, namespaces, modularity and you end up with XML-level of complexity. I know wheel gets reinvented a lot in software, but with data formats you also need tools, adoption, compatibility - XML wins here
- anyfoo 9y ago
  It might not be very simple, but I certainly hope it does not necessarily imply SGML levels of cruft. The things you have covered don't need any of that cruft. You are right that adoption is a major hurdle for any new solution, if it's even attainable, but that's pretty much my point. I'm sad that XML came to reach critical adoption for semi-structured data, and not something else.
- pllbnk 9y ago

ams6110 9y ago

Sites that hijack the "back" button -- be cautious.

saagarjha 9y ago
…this is a Medium article.
- kuschku 9y ago
  And it still hijacks the back button, and therefore shouldn't be read.

otabdeveloper2 9y ago

XML is not a serialization format. It's a structured document format. For, you know, human text and stuff. When used as intended it is wonderful.

ak217 9y ago

If you're handling XML in Python, defusedxml (https://pypi.python.org/pypi/defusedxml https://pypi.python.org/pypi/defusedxml) is a nicely packaged set of XML parser configurations that mitigate attacks in untrusted XML.