Readit News logoReadit News
bawolff commented on Exploring EXIF (2023)   hturan.com/writing/explor... · Posted by u/jxmorris12
shatsky · 6 hours ago
Fun fact: EXIF is simultaneously JPEG format (EXIF spec describes compressed image file format which is based on JIF, the base JPEG file format described in JPEG spec, also EXIF is for "EXchangeable Image File format", suggesting that authors saw it as new file format) and TIFF format (EXIF metadata is actually embedded TIFF which can be parsed with tiffdump, also EXIF spec describes uncompressed image file formats which are TIFF with embedded EXIF metadata which is also TIFF...)
bawolff · 3 hours ago
Its a less fun fact when you have to write a parser for it

All the various metadata formats are kind of weird. IIM (less popular now but still sometimds seen in jpeg files. Was originally for news organizations) is even weirder than Exif. My favourit part is how you specify its utf-8 by adding the iso-2022 escape code in a field. Like wut.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
tannhaeuser · 10 hours ago
I was surprised this wasn't brought up earlier, as it always is in these discussions. It's trivial to mitigate security risk arising out the use of entities. SGML even has the CAPACITY ENTLVL built-in entity nesting limit.

TBH, a browser has one million other potential leaks and exploits and denials to care about. Unlike a markup language with carefully crafted rules about what to expand in which context, a browser providing a Turing-complete language trivially runs into infinite loops or recursion and could at best heuristically terminate JS code, after using laborious best-efforts methods such as execution traces and watchdog timers. Moreover, JS syntax itself and how it's represented in markup unneccessarily gives rise to obfuscation and escaping attacks. And the browser in addition also plays fast and loose with an ever-expanding, potentially Turing-complete styling language with super complicated styling syntax and constraint-based layout models with a complete lack of formal semantics or any other formal reasoning. CSS itself can contain HTML literals at several places such as data URIs and the content property with questionable escaping, but I guess this is par for the course when CSS is basically just tunneling yet another syntax through HTML attributes and elements. Context Security Policy is just bolted on to limit this pointless and careless gratuitious syntax proliferation, and of course must invent its own little item-value microsyntax to be tunneled through HTTP headers and HTML header tags.

Considering these glaring and obvious deficits weren't discussed at the same time I assume those who brought up XXE and suggested SGML/XML could leak documents or smuggle executable instructions did so in bad faith or were repeating hearsay to sound clever or something.

bawolff · 10 hours ago
This is mostly not an issue in browsers so much as non browser implementations. Its not even really an issue in modern implementations with better defaults.

What it did do is create a perception that XML is insecure. This hastened its demise.

> It's trivial to mitigate security risk arising out the use of entities.

Obviously. However in practise, historically most implementations did not. At least not by default.

XML spec bears some responsibility for this for not being explicit about suggesting secure defaults.

Regardless, JSON won partially because it didnt have the attack surface, so people didn't have to worry. XML being theoretically easy to secure means nothing when practically implementations made it difficult.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
tannhaeuser · 21 hours ago
This is how the simplest variant of SGML (or XML) entities have worked since 1986:

    <!doctype html [
      <!entity e system "e.html">
    ]>
    <html>
      <title>Hello, world!</title>
      <p>The content of e is: &e;</p>
    </html>
HTML was envisioned as an SGML vocabulary from day one. That SGML's document composition and other facilities were used only at authoring time and not directly supported by browsers was merely due to the very early stage of the first browser software ([1]) which directly mentions SGML even, just as HTML specs have presented HTML as a language for authoring and not just delivery since at least version 4.

There really never had been a need or call for browser devs to come up with idiosyncratic and overcomplicated solutions relying on JavaScript for such a simple and uncontroversial facility as a text macro which was part of every document/markup language in existance since the 1960s.

[1]: https://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html

bawolff · 11 hours ago
Entities are also probably a significant reason for XML's bad reputation. Between using them to leak senditive files (XXE), and recursive expansion being a DoS vector (million laughs), it cemented XML's reputation as a security risk.

In the browser context though, i don't see why they couldn't just follow same origin rules.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
myfonj · 18 hours ago
That's strange; the `head` and `footer` nodes were present in the XSL template this morning [1], last GH change was Feb 13 [2], what matches

    curl --head --silent --url https://xsl-website.widloski.com/template.xsl | grep modified
    last-modified: Thu, 13 Feb 2025 07:11:02 GMT
from here.

[1] at 09:11:48, according https://web.archive.org/web/*/http://xsl-website.widloski.co... [2] https://github.com/Evidlo/xsl-website/commits/master/templat...

bawolff · 11 hours ago
The footer is in the stylesheet in both my and Evidlo's example. In neither of our examples are these in separate files from the stylesheet.
bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
Evidlo · a day ago
Thanks for the CSS example.

By the way, the advanced/ folder has a slightly more complicated example that demonstrates template inheritance and "slots".

bawolff · 20 hours ago
Yeah, i saw. Unfortunately the advanced example wouldn't be doable in CSS. I suppose i'm being a bit intellectually dishonest to not explicitly point that out.
bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
magicalist · a day ago
> Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else

At least the browser has to load template.xsl before it can know it has to load the css file though, right? And this is just a simple demo page.

bawolff · 20 hours ago
I guess its ine extra layer, but its not like we've gone 14 layers deep or something.

I imagine preloading the css file using the http link header would solve this problem.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
lenkite · 21 hours ago
Umm..your CSS example doesn't show any template includes. No way to put header/footer in separate files.
bawolff · 20 hours ago
The original example didn't have that either.
bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
simpaticoder · a day ago
It's kind of too bad XSLT didn't take off. It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem. Perhaps a devastating 0-day in V8 will make us really, really want an alternative to the current best practice.
bawolff · a day ago
I don't think react is comparable.

React's main thinh is client side reactivity, something that xslt doesn't offer.

A closer comparison would be a templating engine that does statuc conversion to html.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
bawolff · a day ago
Since this seems to be about the recent proposal to remove xslt, i'd point out you can do the same thing with CSS

https://bawolff.net/css-website/index.xml is Evidlo's example but using a css stylesheet instead of xslt. I changed some of the text to explain what i was doing, but otherwise the XML is unchanged with one exception. Unfortunately you do have to put the <a> tags in the xhtml namespace to make them clickable. Other than that no changes to the xml.

Obviously there is a lot that xslt can do that css cannot, but when it comes to just display, CSS is an option here.

bawolff commented on Show HN: JavaScript-free (X)HTML Includes   github.com/Evidlo/xsl-web... · Posted by u/Evidlo
b_e_n_t_o_n · a day ago
This works client side right? So when a user navigates to this page, it recursively fetches content from the server? And if you have nested includes it would waterfall?

Even single page app frameworks have mostly solved this by doing the rendering on the server instead of making multiple round trips from the client. This feels like the no-JavaScript version of Spinnergeddon.

Does the browser wait for all the includes to resolve before showing the page or does it flicker in?

bawolff · a day ago
Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else. So its not that different in terms of requests than how css would work.

u/bawolff

KarmaCake day23785July 16, 2019
About
Hi, I'm Bawolff.

In open source world, I mostly contribute to MediaWiki.

View Original