Re: remove private information from user documents

[Ingo Schwarze <schwarze@usta.de>]

Hi Joerg,

Joerg Sonnenberger wrote on Sun, Feb 27, 2011 at 08:35:20PM +0100:
> On Sun, Feb 27, 2011 at 08:14:39PM +0100, Ingo Schwarze wrote:

>> Theo noticed that mandoc(1) includes information about itself
>> into PostScript and PDF documents it creates.

> Like pretty much every other program that creates either format.

Wow, indeed, even basic tools like a2ps, dvips, pdflatex do that;
i never noticed, which, somehow, proves my point that this is done
behind the back of the user, doesn't it?

Besides, "everybody does that" doesn't sound like a particularly
convincing argument...

>> I don't like that.  Basically, what software i'm running, and which
>> version, is private information about myself.  I don't expect such
>> information to end up in documents i'm creating.

> I somewhat disagree. I don't care much about the version number,
> but at least the creation program is useful enough.

What for, in particular from the point of view of the author?

For interpreting the format?
It shouldn't matter, these formats are standardized.
And even if it does matter, a parser using the Creator
information to disambiguate would be an awful kludge.

For which other reason should that matter?

And do these other reasons really outweigh the privacy argument?

> I'm not sure whether the field is required by the specification
> for the preamble or not, but I think it should be kept.

Regarding the comments in the PostScript preample, i can't find
any specification whatsoever, the strings used there seem to be
mere convention, even for stuff like %%Pages: (atend), the PostScript
language reference doesn't mention anything about these comments,
as far as i can see.

Regarding the Document Information Directory in PDF files,
according to the PDF 1.7 specification, both the presence of
the directory and all of its content are optional.  My patch
only removed the directory but not the reference to it;
according to the standard, that is not an error, as a reference
to a non-existant object refers to the null object.  However,
mandoc handles the deleted object incorrectly in the xref table
in three ways: The 0th enty in the xref table does not point to the
deleted object, the deleted object is not marked as deleted,
and its generation number is not incremented.  Thus, we should
rather not remove the object but just its content, keeping the
empty object.

So, i'm including an updated patch.

By the way, in case we want to keep this information - i still
don't understand why it is useful, and i still regard it as
potentially harmful - we should at least change the name for
PDF from "/Creator" to "/Producer", see Table 317 on page 550
of the PDF 1.7 standard.

Yours,
  Ingo


Index: term_ps.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/term_ps.c,v
retrieving revision 1.14
diff -u -p -r1.14 term_ps.c
--- term_ps.c	31 Jan 2011 02:36:55 -0000	1.14
+++ term_ps.c	27 Feb 2011 22:33:22 -0000
@@ -788,7 +788,6 @@ ps_begin(struct termp *p)
 
 	if (TERMTYPE_PS == p->type) {
 		ps_printf(p, "%%!PS-Adobe-3.0\n");
-		ps_printf(p, "%%%%Creator: mandoc-%s\n", VERSION);
 		ps_printf(p, "%%%%CreationDate: %s", ctime(&t));
 		ps_printf(p, "%%%%DocumentData: Clean7Bit\n");
 		ps_printf(p, "%%%%Orientation: Portrait\n");
@@ -808,7 +807,6 @@ ps_begin(struct termp *p)
 		ps_printf(p, "%%PDF-1.1\n");
 		pdf_obj(p, 1);
 		ps_printf(p, "<<\n");
-		ps_printf(p, "/Creator mandoc-%s\n", VERSION);
 		ps_printf(p, ">>\n");
 		ps_printf(p, "endobj\n");
 
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv