Smith,
> On Dec 1, 2020, at 4:59 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
> ...
> Our concern is that the serial number could be used to identify the owner via a warranty call etc.
So, that *is* one of the use cases for having this information - the serial number is usually associated with a warranty registration of a product. And per the definition of prtGeneralSerialNumber, it might also be reset to another site-specific identifier, e.g., enterprise property barcodes, etc. (Note: the system-serial-number is read-only but the MIB element is read-write, so I think both system-serial-number and printer-serial-number should be potentially read-write...)
Anyways, a printer has a serial number (like all technology products) whether we report it in an attribute or not. If (and this is a big if) we want to put conformance requirements on Clients, we can require (or recommend) that Clients only display these values for the user but not transmit the values to third parties, noting the opportunities for abuse.
That said, we already have a far more potent identification attribute - printer-uuid - which is widely implemented (close to 100% of all network printers), unique across vendors and product lines (where serial number might not be), and unchangeable. But I've not heard of any abuse of this information... Also, printer-uuid is exposed in the DNS-SD TXT record and is used for some basic man-in-the-middle protection (along with X.509 cert validation).
I will also note the default hostname of a printer typically is a vendor prefix followed by the last 3 bytes of the (unique) MAC address - also very useful as a unique identifier! And then there are those pesky printer URIs we use...
> The IPP Privacy Attributes v1.0 doesn't define a "printer-privacy-attributes (1setOf type2 keyword)" or "printer-privacy-scope (type2 keyword)" so we don't have a way to indicate to a Client that "printer-serial-number" might not be available other than via an authenticated Get-Printer-Attributes etc.
There is no such thing as an authenticated Get-Printer-Attributes request, and as we've discussed previously we can't retroactively change that without breaking billions of IPP Clients and all printing in the process.
We have Get-User-Printer-Attributes for the authenticated query operation, but the purpose there is for policy support and not privacy, and I honestly don't think it would be a good fit for querying private/sensitive attributes.
I'm not sure whether we need printer-privacy-xxx attributes - most of the printer description attributes can be used to uniquely identify a printer (that's the whole purpose, after all :) so I think the focus needs to be on best privacy practices for Clients and what Clients do with the information.
> Considering this, I almost wonder if we need to talk again about why an unauthenticated Get-Printer-Attributes is required to expose all Printer Description attributes.
*Because that is the definition in STD 92*. IPP was never designed as a minimum exposure protocol. We expose attributes and values that are necessary to use, monitor, and support a network printer, and we expect that the local site will, if necessary, configure the printer to limit access to specific clients or users, change values that are reported, etc. as appropriate.
> I remember us discussing the justification was to preserve backward compatibility. But surely some Printer management attributes should only be visible to the "Owner" or "Operator", and that identity should be authenticated?
What, if any, existing management attributes are you thinking of? Don't forget that everything in IPP is also typically exposed via SNMP with no password, "public" community name, etc., including my proposed printer-serial-number attribute.
> Sorry, not trying to open up too many cans of worms here...we can discuss in person on Thursday?
Yes, of course.
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201201/ff25a91b/attachment.sig>