<div dir="ltr">Thanks Till.<div><br></div><div>To clarify, we don&#39;t consider advertisement on localhost to be a security problem.  But in the spirit of reducing our attack surface we prefer to moderate communication between processes.  Because of this, we prefer not to communicate over the loopback interface.  Instead, we currently use Unix Domain Sockets since we can control access to those using standard user and group permissions.<div><br></div><div>Sean Kau</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018 at 2:26 PM Till Kamppeter &lt;<a href="mailto:till.kamppeter@gmail.com">till.kamppeter@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I talked with Sean Kau and David Valleau from Chrome OS (CCed) about the <br>
implementation of IPP-over-USB with ippusbxd in Chrome OS. Sean told<br>
<br>
----------<br>
Using DNS-SD on localhost doesn&#39;t fit our security model as we don&#39;t <br>
want to allow arbitrary processes to talk to each other.<br>
----------<br>
<br>
This would mean that we cannot implement IPP-over-USB and Printer <br>
Applications as innitially thought out. They are supposed to make the <br>
printer available as<br>
<br>
ipp://localhost:PORT/ipp/print<br>
<br>
with PORT varying so that there can be several devices connected to the <br>
same machine (and CUPS running in addition). For CUPS (or the printing <br>
system in general) automatically discovering the devices and creating <br>
print queues the Printer Applications (and ippusbxd) are supposed to <br>
advertise themselves via DNS-SD.<br>
<br>
This would mean (local-only) advertising of localhost via DNS-SD, which <br>
Sean considers a security problem. Is this actually a security problem? <br>
If so, how should Printer Applications (and ippusbxd) actually work?<br>
<br>
    Till<br>
</blockquote></div>