Print Telemetry, Privacy, and Retention Limits

The record was built to answer a billing question

Charging for output is older than networked printing. Departmental copiers were metered with key counters, mainframe and Unix print spoolers kept per-user tallies, and cost recovery for shared equipment was ordinary office practice long before any of it was written down as a protocol; NARA's General Records Schedule 3.2 still names the resulting records separately, as "cost-back files used to assess charges for system use". It is worth resisting the common claim that print job accounting was invented for networked printers in the 1990s. What the 1990s produced was codification: an agreed vocabulary for practices that already existed, so that a printer from one vendor and an accounting package from another could describe the same job in the same terms.

The clearest early statement of that vocabulary is the Job Monitoring MIB, published as RFC 2707 in November 1999. It is worth stating its status precisely, because it is often overstated: RFC 2707 is Informational, published to make the work available rather than as an IETF endorsement of the MIB it describes. Its content, though, is unambiguous about purpose. It defines an object for the job's owner, an object for a submission identifier, and it names an "Accountant" role concerned with charging users or groups for resources consumed. It also introduced the idea that would matter most later: a job-retention period after a job completes, during which accounting programs can copy the accounting data out of the MIB.

That is the substrate. A retention window exists in the model not as a privacy limit but as a collection opportunity — a period during which the data must still be there, so that a billing system can harvest it. Everything the rest of this page describes is an attempt to impose a ceiling on a structure whose original function was to guarantee a floor.

Three layers, and only one of them is not about you

The most common analytical mistake in print privacy work is treating "print logs" as a single thing. They are not. A fleet holds three distinct bodies of telemetry — device counters, protocol job attributes and host spooler logs — produced by different mechanisms, held in different places, and reachable by different controls. On a multifunction device a fourth, the security audit trail, sits alongside them and is governed separately again.

The practical consequence is that setting a retention limit in one layer tells you nothing about the others. A site that configures a short job-retention window on its printers, and believes it has therefore limited what it keeps about who printed what, may still be holding a year of page-level records in a host log file that no printing standard governs — and a security audit trail on the device that was configured by a completely different team for a completely different reason.

What the protocol requires the printer to know

The current model for internet printing is RFC 8011, published in January 2017, which obsoletes RFC 2911 along with RFC 3381 and RFC 3382, and now carries the designation STD 92. Anything that cites RFC 2911 as the live IPP model — still very common in secondary write-ups — is describing a superseded document.

In RFC 8011 the identity field is not optional. "job-originating-user-name" is a REQUIRED Job attribute, which the Printer sets to the most authenticated printable name it can obtain from the authentication service; where no authentication service supplies one, it falls back to the client-supplied "requesting-user-name". Read plainly, this is a specification instructing the device to record the best identification available to it, and to record something regardless. There is no conformant configuration in which a job simply has no originating user.

The accounting extensions add more. PWG 5100.7-2023, IPP Job Extensions v2.1 (JOBEXT), dated 10 February 2023, defines "job-account-id" as the account associated with the job — and its own text illustrates the range of what that field may contain: a customer name, a sequence of digits referencing an internal billing number, or even a credit card number. It is difficult to find a more direct demonstration that print telemetry is not confined to technical metadata. The same specification defines "job-accounting-user-id", separating the identity used for charging from the identity used for submission.

The spooler log is a separate decision, and usually an unexamined one

Host-side logging is where the richest per-person record often lives, and where the fewest deliberate choices tend to have been made. The CUPS page log is the canonical example, and it repays reading the documentation rather than the folklore.

The PageLogFormat directive in cupsd.conf accepts format sequences: %u inserts the user name, %j the job id, %p the printer, %T a timestamp, and %{name} the value of any named IPP attribute. The documented standard-items string combines printer, user, job id, timestamp, page and copy counts, the job-billing value, the originating host name, the job name, the media and the sides setting — that is, the user, the machine they sent from, and the title of their document, recorded per page.

But the same documentation states that the default is the empty string, which disables page logging. The widely quoted format line is an example, not a shipped default. This distinction matters more than it may appear: it separates "what this software is capable of recording" from "what a stock installation actually records", and those two claims call for entirely different remediation. Before writing a policy about print log retention, it is worth establishing empirically which of these layers on this site is actually populated, and with what.

Copy, scan and fax leave records of their own

A multifunction device is not only a printer, and its audit surface is broader than its print path. The collaborative Protection Profile for Hardcopy Devices v1.0, dated 31 October 2022, is a useful reference here precisely because it describes person-linked auditing as a certification requirement rather than a vendor extra. Its audit-generation requirements list job completion as an auditable event with the type of job recorded as additional information; for unsuccessful authentication it calls for the supplied user id or name and the origin of the attempt, such as an IP address. A separate requirement states that the device shall be able to associate each auditable event with the identity of the user that caused it. Further requirements restrict who may review the audit trail, protect the stored trail from modification, and cover export of audit data to an external IT entity.

Fax deserves particular care, because three quite different mechanisms are frequently merged into a single claim. The human-readable identification line printed across a transmitted page is a jurisdictional labelling requirement in some countries and a function of the sending machine's configuration. The subscriber-identification signalling exchanged between machines during call setup is defined in ITU-T Recommendation T.30 — the in-force edition being T.30 (09/2005) with Amendment 1 (01/2007) — and is a protocol matter, not a printing one. The stored activity journal and confirmation reports a machine keeps or prints are a third thing again, and are the ones that constitute retained telemetry on the device. Statements about fax identification should say which of the three they mean, and any claim about specific T.30 signalling frames or about a particular regulator's labelling rule should be checked against the Recommendation text or the rule text rather than repeated from summaries.

Identification carried on the page itself

Not all print telemetry is in a log. Some colour laser printers add a faint pattern of yellow dots to output — a machine identification code — which researchers have shown can encode information tying a printed sheet to a device and a time. This is the part of the subject where the published record is thinnest and the confident retelling is thickest, so it is worth being explicit about what is and is not established.

The Electronic Frontier Foundation's work on printer dot patterns is the origin of most public knowledge here, including the decoding of a grid used by one specific printer family. Two limits follow directly from that work. First, behaviour varies by model: the EFF maintains its own list of printers that do and do not display tracking dots, which would be pointless if the practice were universal. Second, a decoding derived from one family does not generalise; monochrome laser printers, in particular, do not generally carry the yellow-dot pattern for the simple reason that they have no yellow toner.

Retention is the part the standards declined to decide

RFC 8011 does describe what happens to a job after it finishes. It partitions the life cycle into a phase in which the job is not yet completed, a job-retention phase, a job-history phase, and finally job removal. What it does not do is say how long any of those phases last. The durations are implementation-defined; the specification's one concrete figure is a recommendation that printers keep a job in the job-history phase for at least sixty seconds — a floor, not a ceiling, and a very short one.

Nor is the specification unaware that this data is sensitive. Its security considerations acknowledge that information stored in the job object can be considered personal or sensitive in nature, and can be filtered out as part of a configured privacy policy. The awareness is there; the number is not. That is a design choice, and arguably the right one for a protocol that has to serve a print shop, a hospital and a university library at once. But it means the decision was handed to the operator, and most sites have never consciously taken delivery of it.

A standardised limit did eventually arrive. PWG 5100.7-2023 defines "job-retain-until", with keyword values including end-of-day, end-of-week, end-of-month, indefinite and none, alongside "job-retain-until-interval" expressed in seconds and "job-retain-until-time" for an absolute moment. This is a genuine, client-settable ceiling on retained job data — and it is worth noticing that "indefinite" is among the legal values. The standard supplies the mechanism and declines, again, to supply the policy.

The constraint arrived afterwards, and had to be retrofitted

The privacy machinery in IPP is younger than the accounting machinery by a wide margin, and its own rationale says why it exists. The PWG's IPP Privacy Attributes v1.0 is an IPP Registration dated 12 April 2018 — not a PWG Candidate Standard, and not an IETF RFC, so citing it as "PWG 5100.something" or as an RFC would be a fabricated citation. Its IANA reference tag is IPPPRIVACY10.

The registration defines "job-privacy-attributes" and "job-privacy-scope", document- and subscription-level equivalents, and "printer-privacy-policy-uri". Its stated rationale is that RFC 8011 defines general access rights and privacy policies but does not define a way for clients to discover what those specific rights and policies are, and it notes that many countries require explicit or implied consent when personal and confidential data are processed. The scope keyword "owner" restricts private job attributes to the job's owner — which is to say, the mechanism by which a printer can decline to tell one user what another user printed had to be added as a registration two decades into the protocol's life.

Outside the printing standards, the frame is general log-management and records practice rather than anything printer-specific. NIST SP 800-92, Guide to Computer Security Log Management (2006), is the baseline federal guidance on deciding what to log, where to retain it and for how long, including archival when the originating system cannot hold data long enough; a revision, SP 800-92r1, has appeared in initial public draft. In the United States federal records context, NARA's General Records Schedule 3.2, Information Systems Security Records (Transmittal No. 33, January 2023), is unusually on point: its item 030 for system access records expressly covers audit trail files and extracts, system usage files, and cost-back files used to assess charges for system use — print accounting data by any other name — with a disposition of "Temporary. Destroy when business use ceases." Item 031, for systems requiring special accountability, sets destruction six years after the password is altered or the user account is terminated, with longer retention authorised if required for business use.

In the European frame, workplace print logging is a monitoring question before it is a technical one. The Article 29 Data Protection Working Party's Opinion 2/2017 on data processing at work (WP249), adopted in 2017, is the regulator text on employer monitoring of workplace ICT, and its proportionality and necessity reasoning is the right frame for logging who printed what on a shared office device. The GDPR's own storage-limitation principle is, as its name indicates, a purpose-bound test rather than a fixed term, and the Regulation supplies no period for logs of any kind. Any specific figure attributed to it has come from somewhere else.

Borrowed decisions

What links these claims is not that people are careless. It is that each one is an attempt to import a decision from an authority that never made it. The standards refused to set a number; the regulations set a test rather than a number; so the number gets borrowed from whichever adjacent rule sounds most official. The result is a retention period nobody chose, defended by a citation that does not say what it is claimed to say.

Making the decision instead of inheriting it

1. 1

   Inventory by layer, not by device

   Establish separately what device counters hold, what job attributes your printers retain and for how long, what your host spoolers are configured to log, and whether device audit trails are enabled and exported. A single "print logs" line in a data inventory almost always conceals at least two of these.

2. 2

   Find out what is actually populated

   Read the live configuration rather than assuming a default. Check the page log format string on the print host, check whether job-account-id or job-accounting-user-id are being set by clients, and check what the MFP's audit function is recording. The gap between what a system can record and what it does record is often the whole finding.

3. 3

   Name the purpose for each field, then test it

   Cost recovery justifies an account identifier and a page count. Security investigation justifies an audit trail with user identity. Neither obviously justifies retaining document titles at page granularity for a year. Fields whose purpose has lapsed — the departmental chargeback scheme that ended three budget cycles ago — are the clearest candidates for removal.

4. 4

   Set a ceiling at each layer, and expect them to differ

   Where PWG 5100.7-2023 retention attributes are implemented, job-retain-until and its interval and time forms give a protocol-level ceiling, but leaving it unset is not the same as setting it short. Host log lifetimes are governed by log rotation and nothing else. Device audit storage is governed by the device.

5. 5

   Use the privacy attributes where devices support them

   job-privacy-attributes with a scope of owner is the mechanism for keeping one user's job details out of another user's view, and printer-privacy-policy-uri is the mechanism for publishing what the policy is. Support varies, so verify on the actual fleet rather than assuming; and if a device does not implement them, that is itself a finding about what your users can see about each other.

6. 6

   Write down the number and the reason together

   The value of an explicit retention period is not the period; it is the recorded reasoning attached to it, which is what allows the decision to be defended, reviewed and changed. A number without a purpose is exactly the inherited default this page is about.

Timeline

1. November 1999

   RFC 2707, Job Monitoring MIB v1.0, published as Informational. Defines a job owner object, a submission identifier, an Accountant role concerned with charging for resources consumed, and a job-retention period during which accounting programs can copy accounting data out.

2. June 2004

   RFC 3805, Printer MIB v2, published on the Standards Track, obsoleting RFC 1759. Establishes the device-level counter and status model that sits underneath fleet reporting — device telemetry, distinct from person-linked job telemetry.

3. 2006

   NIST SP 800-92, Guide to Computer Security Log Management, published — the general frame for deciding what to log, where to retain it and for how long. A revision, SP 800-92r1, later appears in initial public draft.

4. 2008

   IEEE 2600-2008 published, covering authentication, authorisation, privacy, integrity and device management for printers, copiers and multifunction devices; associated protection profiles 2600.1 to 2600.4 follow.

5. January 2017

   RFC 8011 published, obsoleting RFC 2911, RFC 3381 and RFC 3382, and later designated STD 92. Makes job-originating-user-name a REQUIRED Job attribute, and partitions the job life cycle into implementation-defined retention, history and removal phases.

6. 2017

   Article 29 Data Protection Working Party adopts Opinion 2/2017 on data processing at work (WP249), the European regulator text framing employer monitoring of workplace ICT as a proportionality and necessity question.

7. 12 April 2018

   The PWG registers IPP Privacy Attributes v1.0, adding job-privacy-attributes, job-privacy-scope, document and subscription equivalents, and printer-privacy-policy-uri — because RFC 8011 defined privacy policies without a way for clients to discover them.

8. 31 October 2022

   collaborative Protection Profile for Hardcopy Devices v1.0 issued, treating person-linked audit records for job completion and authentication events as a certification requirement, with protections on review, storage and export of the trail.

9. January 2023

   NARA General Records Schedule 3.2, Information Systems Security Records, Transmittal No. 33, covering audit trail files, system usage files and cost-back files used to assess charges for system use.

10. 10 February 2023

    PWG 5100.7-2023, IPP Job Extensions v2.1 (JOBEXT), standardises job-retain-until, job-retain-until-interval and job-retain-until-time — a client-settable retention limit on retained job data.

11. 2024

    PWG 5100.11-2024, IPP Enterprise Printing Extensions v2.0 (EPX), carries the held-job and release machinery associated with pull printing, including the job-release-action attribute registered against it in the IANA IPP registry.

Laid out in order, the asymmetry is hard to miss. The accounting substrate was in place by the end of the 1990s. The mechanism for a client to discover a printer's privacy policy arrived in 2018. A standardised retention limit on retained job data arrived in 2023, roughly two and a half decades after the standardised retention period that exists to let accountants copy the data out. Retention is not a gap the standards forgot to close; it is a decision they consistently declined to make on the operator's behalf.