[pdftex] Re: pdftex-pdfcrypt - The Missing Link(?).

[Wroth, Mark]

Various people commented on Greg Black <gjb at gbch.net> 's assertions
regarding Michael Chapman's intended uses for pdfcrypt:

MC| 1. I am treasurer of the WWW Virtual Library project. I am due to
publish the 
MC| accounts. I will now do so not only by plain text e-mail but 'for the
record' 
MC| as a PDF document.
MC| Obviously any inspired 14-year-old cracker could 'forge' a look-alike
balance 
MC| sheet, but by closing the file to alterations it stops anyone innocently

MC| (officiously) fiddling with them -the gratuitous correction of a seeming

MC| typo' before passing them on, etc. There is thus one document (with all
its 
MC| typo's :-)> ) as a document of record.

GB> This goal is much better met by attaching a digital signature
GB> with PGP or GPG and leaving the document in a form that allows
GB> its readers to use it in ways that are comfortable for them.

I have to agree with Greg here.  Several comments:

PGP integrates quite nicely into both of the mailers I use, and the
installation is not difficult.  But this is a red herring.  If the goal is
to be able to verify that the "record copy" is in fact what the author sent
out, a digital signature is the right answer (using whatever tool).  Most
users will not need to make that verification; those who do should adopt a
tool that lets them do so.  If the organization can't agree on such a tool,
then electronic forms should not be the record document.
	It's relevant, of course, that a document signed but not encrypted
by PGP is readable whether or not you choose to verify the signature.

Encrypting the PDF makes it harder to change the document, but provides no
way of verifying whether the document is the original.

Michael Chapman <mchapman at mchapman.com> then asked

MC> But what proposrtion of e-mail recipients have (functionally) access to 
MC> (and/or understanding of) PGP/GPG?
MC> Conversely, Acrobat is installed on most people's boxes. 

I think the question should be "what proportion _of the people who need to
verify the authorship of the document_ have access to PGP?"  If the answer
to that (or the equivalent question for some other signature tool) is not
"almost all", then you ought not be using an electronic version as a record
copy. 

But the key point, I think, is that I suspect this group is much smaller
than the people who merely want to read the document.


MC| 2. We publish a (free) newsletter. This has split into a plain text
version 
MC| and an on-screen (was HTML, now moving to PDF on-screen) version. 
MC| Printing out the sreen version looses you all the link information. I
will 
MC| lock out printing on the 'colour edition' to force naive users to use
the 
MC| better edition for them. (I think that is constructive and not over
nanny-ing 
MC| ?)

GB> Again, this is just absurd.  If you don't want people to see the
GB> contents at all, encrypt the document (but with a purpose-built
GB> tool like PGP or GPG).  But, if you want people to read it,
GB> don't patronise them by deciding that you know best how they
GB> should go about it.  It's perfectly reasonable for somebody to
GB> choose to have a printed copy for reading or reference and to
GB> accept that she can't click on links that way.  Give up on this
GB> silliness.

While I might disagree with the tone of Greg's comments, I have to agree
with the meat of them.  Hyperlinks don't typically work real well on paper
copies, so the loss of hyperlink information at the "print to paper" step
seems a poor reason to deny people the ability to print the document.  

Why is it important to limit your readers' ability to do things the way they
want to, whether you think that's the way they _should_ want to or not?


pdfcrypt is probably useful for some purposes; I haven't seen any need for
it personally, but I have no gripe with it being available for people who
do. But I don't think it's a good solution for authenticating documents, and
I can't say that (attempting to) prevent users from printing the document
seems like a strong argument.
 
Mark