Web Printing API

[GrapeGreen]

こんにちは TAG-さん!

I'm requesting an early TAG review of the Web Printing API.

This API enables deeper integration with printer-related functionality in web applications by providing a set of JavaScript methods that allow developers to query local printers, submit print jobs to the most appropriate printers, and manage print job options and status directly from web applications. To represent these concepts, it relies on the attribute names and semantics from the Internet Printing Protocol (IPP) specifications.

• Explainer¹ (minimally containing user needs and example code): Explainer
• User research: N/A
• Security and Privacy self-review²: Questionnaire
• GitHub repo (if you prefer feedback filed there): GitHub repo
• Primary contacts (and their relationship to the specification):
  • Andrew Rayskiy, GrapeGreen@, Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature: Chrome Status

Further details:

• [X] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google

You should also know that...

There's a demand for this API from VDI providers (Citrix & VMWare).

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify GrapeGreen@

[hadleybeeman]

Hi @GrapeGreen. We are looking at this in our W3C TAG breakout session today.

We have a lot of concerns about this, and don't think it should be added to the web platform in its current form.

The web has always been separate from the operating system, and implementing this proposal would take capabilities of the client's environment and hand them off to the server. Not only does this pose a large privacy risk, some of which you've outlined in your explainer, but it also moves the boundary of where the web ends and the user/client's environment takes over.

But most importantly, the use case seems rather niche, so the privacy risk is not balanced by a comensurate gain in user experience. Therefore, we are not convinced that the trade-off is worth it. We wondered if this might be better tackled with a browser plug-in.

We are proposing to close this review issue. You are welcome to come back to us with questions, or with a substantial re-architecture.