Well, what's wrong with static site (generators)?
I certainly get the argument, but using something like hugo or gatsby or jekyll when you want to avoid the "churn" also seems like a perfectly valid solution.
I certainly get the argument, but using something like hugo or gatsby or jekyll when you want to avoid the "churn" also seems like a perfectly valid solution.
Of course, pdfs aren't necessarily static, either, but that is why Lab6 is choosing to use pdf/a, an actually static format intended specifically for long-term archiving of immutable files. This way you can sign the file and guarantee it stays the same forever and everyone's copy is identical.
I'm kind of surprised at the response to this. The author seems well aware of how terrible pdf is as a format and this isn't some treatise of why we should want to use it. It's an unfortunate compromise that, given the requirements they're aiming to meet, of generating a file that supports rich formatting and hyperlink embedding, but which can guarantee immutability and long-term archiving directly in the spec, pdf/a is all there is, so in spite of being a terrible format with a lot of shortcomings, it's what they're using.
But just like you can choose to use PDF/A, you can also choose to have a completely static and self-contained (e.g. using data URLs for images) HTML page.
Nobody is requiring you to use PDF/A. No mainline browser (that I'm aware of) requires it.
So what is being solved? When I click on a PDF on the web, I don't know if it's using PDF/A, I don't know if it's embedding or linking its fonts. So it's the same situation, nothing has changed.
Telling people to use PDF/A when most clients do not enforce it and when there's no indication to users before they click on a link whether or not the link is following the spec -- it is exactly the same as telling them to use a subset of HTML; the author is doing the same thing they complain about.
You can't just say that PDF/A exists. That's not enough, how will you get people to restrict themselves to that format when 99% of their users will never notice the difference and no client is enforcing it?
With HTML, I have to trust that some random entity does what they state in their privacy policy, and they regularly don't. Sure, I can disable JS, but then 95% of the web doesn't work anymore.
Other than that PDF is quite clearly a less accessible format.
Pretty sure a PDF opened in the browser can't run any JS, but not completely sure. So you're right: I don't really know it for a fact. Poor choice of words.
JavaScript is allowed, but not in PDF/A, which is what I use.
The PDF 2.0 spec is damnably not public.
If you only allow PDF, then 99.9999% of the web doesn't work anymore.
I'm all for getting sites to be static, but PDF doesn't fix that because the problem has never been the technology used to build the site.
(It looks like at least some PDF readers have provided support for automatically displaying external images, for example)
I often use Tor, although I'm pretty sure that even then, a good analytics lib can see it's me based on scroll behaviour, mouse movement, time of day, and of course what I browse.
But yeah, you make a good point.
You might not be a unique fingerprint, but at best you are part of a group of somewhere between 3 and 1000 similar users.
Not to be a downer, but when I webscraped I learned that big corporations can spend money to fingerprint you.
Or a plug-in to Wordpress so you can keep the GUI/dynamic for the less technical employees: