[sane-devel] Sandboxing scanner applications

[Till Kamppeter]

Hi,

as leader of the OpenPrinting project and so also the principal 
architect of the printing environment of Linux and other POSIX-style 
operating systems I have already started to work on sandboxed packaging 
for printing (CUPS, printer drivers, applications which print or 
administrate printing) and due to multi-function printers also worked on 
sandboxed packaging for scanning. The implementation is already in the 
works by a student project.

Printer and scanner drivers were added to a system by putting the 
driver's files (filters and PPD files for printers, shared libraries for 
scanners) into reserved directories of CUPS and SANE.

With sandboxed packages (Snap. flatpak, ...) this does not work as each 
package has its own, separate file system. As we are working towards 
distros totally based on sandboxed packaging, like an all-Snap Ubuntu.

By the way, I am working for Canonical, doing also the packaging of 
printing-related stuff for Ubuntu, therefore I am more familiar with 
Snap than with flatpak, but for flatpak it is probably similar.

For solving this problem we did not have to design something new from 
the ground up, as the Printer Working Group (PWG, http://www.pwg.org/) 
came up with IPP (Internet Printing Protocol) already 20 years ago and 
more recently, they add the driverless IPP Everywhere printing and IPP 
scanning standards.

CUPS which was based on IPP currently uses filters and PPD files as 
printer drivers, but due to the fact that PPD files are decades ole, 
designed for PostScript printers, and not covering the needs of modern 
printers, this concept is deprecated. CUPS should only support 
driverless IPP printers in the future, most modern printers are 
driverless, and if a driver is needed the driver should be provided as a 
Printer Application, an emulated driverless IPP printer on the local 
machine, a daemon which behaves as an IPP printer and internally 
converts the job to the physical printer's format and sends it off to 
the printer. The Printer Application advertises itself via DNS-SD, so 
CUPS easily finds it, and via IPP CUPS can poll all capabilities, so no 
local data files, like PPDs needed, purely driverless.

The communication between CUPS and the Printer Application is a network 
(IP) communication, even if CUPS and the Printer Application are running 
on the same machine. It is easy to create sandboxed packages which can 
do IP communication, Snap for example has an appropriate interface for 
that. So CUPS can be in a Snap and the Printer Application can be in 
another Snap, and there can be any number of Printer Applications on the 
same machine, for example if you use printers of different manufacturers.

Snaps (and probably flatpak packages, too) are distribution independent. 
A Printer Application in the Snap Store should work on all 
distributions, so manufacturers have much more ease to create drivers 
for their hardware.

Seeing all this and also that the PWG created an IPP Scan standard to 
complete IPP for multi-function devices I came up with an extension of 
this idea to also allow snadboxed packaging of scanner drivers.

For this we create Scanner Applications, emulation of IPP scanners. The 
Scanner Application listens for scan requests via IPP and passes on the 
request to the actual scanner, and returns the scanned image, if needed, 
converted to the requested data format. A client (a GUI application like 
simple-scan for example) simply needs to talk IPP to the scanner (or 
better Scanner Application), so it always works driverless.

So the Scanner Application replaces the classic SANE driver but as with 
Printer Applications we have again a pure IP communication. So the 
client and the drivefr can be in different Snaps (or flatpaks) and 
distribution-independent scanner driver packages in the Store.

Naturally a Printer Application can also be an emulation of a 
multi-function device, containing both printer and scanner drivers. We 
can imaging that HPLIP could for example be provided this way. But this 
is not required, the printing part of a multi-function device can be 
supported by a Printer Application for Gutenprint and the scanning part 
by a Scanner Application for SANE, think about Epson multi-function devices.

Do not think that I want to kill SANE, SANE will still be used but not 
be that visible any more. We will create Scanner Applications which use 
SANE internally, so that existing SANE drivers stay available in the new 
world of IPP Scan, all scanners supported by SANE will also be supported 
by a Scanner Application. We will also have an IPP Scan SANE backend, so 
that client applications can scan on scanners supported by a Scanner 
Application. As CUPS finds printers via DNS-SD, this backend will find 
scanners (Scanner Applications) via DNS-SD.

For the sandboxed packaging, if one packages some SANE frontend, an 
application which scans, one packages it with the IPP Scan SANE backend. 
Then this sandboxed application can scan on all scanners supported by 
Scanner Applications. The Scanner Applications get also sandboxed, like 
Printer Applications.

Implementation of all this is already in the works, by two students 
working in a Linux Foundation Mentorship Program project One student 
expands sane-airscan to support IPP Scan as a client, to be packaged 
with SANE frontends, applications which scan. The other student 
implements IPP Scan as a server, to have the framework for Scanner 
Applications.


And here are some links for more details about all this:


OpenPrinting Microconference on Linux Plumbers Conference 2019

https://openprinting.github.io/OpenPrinting-Microconference-on-Linux-Plumbers-Conference-2019/

Here we have started the discussion about the driverless IPP scanning 
concept.


My monthly news posts about the work at OpenPrinting

https://openprinting.github.io/news/

Here you can see how the development of driverless scanning and 
Printer/Scanner Applications was going


OpenPrinting Microconference on Linux Plumbers Conference 2020

https://openprinting.github.io/OpenPrinting-News-September-2020/#openprinting-microconference-on-linux-plumbers-conference-2020

A lot has happened between the two microconferences on Linux Plumbers. 
Here you get more concrete information about the new concepts.


Linux Foundation Mentorship Program project "IPP scan (or virtual MF 
device) server (Scanner Application)":

https://people.communitybridge.org/project/55cdb4a1-76bd-423a-ab48-3bdf1502a171

The implementation of IPP Scan, extension of sane-airscan for IPP Scan 
as a client support and extension of PAPPL for IPP Scan as a server support


Ongoing Google Season of Docs project on designing and packaging printer 
and scanner drivers

https://piyushgoyal16.github.io/openprinting.github.io/documentation/

Guidelines/Tutorial for free software projects and for hardware 
manufacturers on creating printer and scanner drivers. It is not yet 
complete, we are only one week into the 3 months of GSoD, but already a 
lot of interesting info.


PAPPL - Printer Application Support Library

https://github.com/michaelrsweet/pappl/

Everything which Printer/Scanner Applications have in common, to emulate 
a complete network multi-function device, including DNS-SD advertising, 
supply of full capability info via IPP, job handling, and also a web 
admin interface, as on a physical printer.


sane-airscan - SANE backend for driverless scanning

https://github.com/alexpevzner/sane-airscan

Currently it supports the protocols multi-function devices which claim 
to do AirPrint use for scanning (AirScan): eSCL and WSD. IPP Scan 
support is about to be added.


CUPS Snap - The CUPS printing stack in a Snap

https://github.com/OpenPrinting/cups-snap

This is the official CUPS Snap, intended to be the standard printing 
environment of Ubuntu, but can be used on any distribution with snapd 
installed.


Bastien, so this is more your second approach of drivers being on the 
host side, but we use IPP Scan as IPP is an established standard 
protocol and it is used for both printing and scanning, so ideal for 
multi-function devices. We get also interoperability between different 
operating systems, scanning from mobile devices, ....

    Till



On 17/09/2020 11:40, Bastien Nocera wrote:
> Hey,
> 
> I wanted to finally start looking at how to properly integrate SANE-
> based scanning applications into Flatpak[1].
> 
> I looked at 2 different ways to implement this:
> 
> - either the drivers are bundled with the application itself, and we
> need to punch holes for those drivers to be able to communicate with
> the hardware (eg. network, or USB[2]),
> - or just as for a lot of other drivers, we can expect the drivers to
> live on the host side, with the distribution, and we'd communicate with
> those drivers (free or proprietary, like the ones for Epson V600...)
> through a service that's outside the sandbox.
> 
> I think that the latter is the best one to put in place, especially if
> we want to support more complicated setups like networked scanners,
> multi-function devices, and proprietary drivers.
> 
> The idea would be to reimplement the client (based on the "net" driver)
> to use D-Bus and reimplement or extend the server ("saned") to use D-
> Bus.
> 
> Would the SANE project want to ship those in its own repositories? Are
> there are dependencies that wouldn't be acceptable? I plan on using
> systemd's D-Bus library, sd-bus, as it doesn't require a GLib mainloop
> like the very capable GDBus, so would be less disruptive when loaded
> into apps. Should I extend saned, or write a new daemon?
> 
> Cheers
> 
> [1]: https://github.com/flatpak/xdg-desktop-portal/issues/218
> [2]: https://github.com/flatpak/xdg-desktop-portal/issues/227
> 
>