Say you made the foreground text color the same as the background text color, so you could no longer see the source code. You can no longer do anything. You can no longer save those changes. And then what?
Better, say you did that in a script file which additionally saved the image, so that image was now unusable. And then what?
The parent comment was talking about a deployed application, and making sure users can't modify the source code.
In that case, your image hopefully was built using source code from a VCS and no such changes will have been applied. This is not so different from building an app by pulling the latest version of the code from Git.
And if you did manage to commit changes that completely mess up your environment, you throw that image away, take a vanilla one and load your source code into it. Again, not so different from using Git.
How do you define cryptography? Let's say my files are written in a format that only my software can read. Is it then illegal to distribute said files?
I define it as anything that even slightly inconveniences the so called "authorities".
I've seen local judges give interviews to television networks about high profile cases where they were nearly foaming at the mouth with rage over end-to-end encryption. Cryptography is whatever causes that.
Streaming is defined in the XSLT 3 spec: https://www.w3.org/TR/xslt-30/#streamability. When you want to use streaming, you are confined to a subset of XPath that is "guaranteed streamable", e.g. you can't just freely navigate the tree anymore. There are some special instructions in XSLT such as <xsl:merge> and <xsl:accumulator> that make it easier to collect your results.
Saxon's paid edition supports it. I've done it a few times, but you have to write your XSLT in a completely different way to make it work.
This was as I remember under development at the time. However, if working on bounded memory on communication buffers it, without remembering all the details, it was a pain not because of XSLT but mostly its interactions with XPATH. I was at the time formally looking into hedge grammars and visibly pushdown automata as formal basis, but to me it seemed at the time, that formal complexity was unnecessarily pushed beyond what was straightforward feasible. As I said it was about transforming binary (intermediate) representations of XML. Use case was actually to build message middlewares/routers for IoT stuff at the time. IMHO also the picked binary XML standards where mostly the wrong choice for small embedded systems (interestingly MPEG 7 is btw one of the few standards that supports rather nice streaming binary XML. I think however it is only used in digital broadcasting)
My specific claim was that you could represent it in JSON, so you can't claim, as the post I responded to did, that JSON "cannot be used."
I'll fully grant, I don't want to write a document by hand in either of the JSON formats I suggested. Although, given the choice, I'd rather receive it in that format to be parsed than in any XML format.
The web app probably authenticates using an API as well, in which case it's trivial to add that to your shadow client as long as you have the credentials.
