4 ms·

I like this, and of course you could also embed the text of the document. Nothing stops us from doing this right now. But: don't we need some way to prove tha

by biztos 5y ago

I like this, and of course you could also embed the text of the document. Nothing stops us from doing this right now. But: don't we need some way to prove that the data matches what is visually rendered in the PDF reader? And if we can prove that the embedded data matches the rendered document, couldn't that same logic just be used in reverse to generate the structured data from the renderable PDF?

xmprt 5y ago
That's not necessary. If you think of the PDF as a checksum then it's possible to have a one way function that generates the PDF (checksum) but that you can't retrieve the original JSON from. I do really like the idea of having a checksum of some sort if we end up embedding metadata like this.
- q-base 5y ago
  That would be necessary. It should probably be baked into the creation of the file and perhaps even be included in the footer of the document itself.
- biztos 5y ago
  That's a good idea: the tool that processes the data can just run your function and if the file doesn't match the result then it's rejected. But in the real world people are going to want to annotate the PDFs, there will be open-and-save cycles that add metadata and break the checksum, etc and so on, even without considering malicious actors. Restricting all that is maybe easy -- just reject anything that doesn't match the checksum, done -- but communicating that restriction to the users without making a mess of it is probably hard. Long ago I wrote some PDF generating programs and it was a lot of fun, but the spec has evolved in ways I imagine would make it less fun today. Still, could be a cool thing, and I'd be surprised if someone hasn't already done a version of it somewhere. [Edit: plus, whoever creates the one-way function is deciding what all the PDFs are going to look like, which means you will end up with many such functions to accommodate the different rendering goals, and then each validator needs to know each one and someone decides which ones to trust, and so on...]

by biztos 5y ago

xmprt 5y ago

That's not necessary. If you think of the PDF as a checksum then it's possible to have a one way function that generates the PDF (checksum) but that you can't retrieve the original JSON from. I do really like the idea of having a checksum of some sort if we end up embedding metadata like this.

q-base 5y ago
That would be necessary. It should probably be baked into the creation of the file and perhaps even be included in the footer of the document itself.
biztos 5y ago
That's a good idea: the tool that processes the data can just run your function and if the file doesn't match the result then it's rejected. But in the real world people are going to want to annotate the PDFs, there will be open-and-save cycles that add metadata and break the checksum, etc and so on, even without considering malicious actors. Restricting all that is maybe easy -- just reject anything that doesn't match the checksum, done -- but communicating that restriction to the users without making a mess of it is probably hard. Long ago I wrote some PDF generating programs and it was a lot of fun, but the spec has evolved in ways I imagine would make it less fun today. Still, could be a cool thing, and I'd be surprised if someone hasn't already done a version of it somewhere. [Edit: plus, whoever creates the one-way function is deciding what all the PDFs are going to look like, which means you will end up with many such functions to accommodate the different rendering goals, and then each validator needs to know each one and someone decides which ones to trust, and so on...]