Re: Zeroconf applet

["Alan Gibson" <alan gibson gmail com>]

On 7/18/06, Rodney Dawes <dobey novell com> wrote:
> It seems like both of these could be merged into one single option,
> which is "Enable Zeroconf Broadcasting" but with better terminology.
> This could also just be placed in the Network preferences, rather
> than having a whole new capplet for it.

sorry, i meant to suggest that it go into Networking; no point in a
new capplet at all.

what im imagining is an extra tab in Networking. It would have 3 radio
buttons: 1. Enable Zeroconf service announcements (or something like
that) 2. Disable zeroconf service announcements 3. Set by application

selecting 3 would turn on a checkbox list of all currently installed
zeroconf-enabled apps. unchecking would set whatever configuration
options that app required to disable zeroconf (and if it is a service,
restart it); checking it would do the reverse.

> The real questions is whether
> the policy belongs in Avahi, or something a bit higher. Basically,
> the policy would be based on the option and enable/disable broadcasting
> for that user. If the policy is in Avahi, the daemon can be told of the
> settings change, via dbus. If the policy is higher up on the desktop
> somewhere, I'm not sure how exactly it would work.

it would be very slick if we could tell Avahi to not pass messages for
a certain user or application, but i dont think its possible at the
this moment. so if one wanted centralized control of what apps publish
zeroconf info, and i admit it may be too complicated to be worthwhile,
it seems like it would have to be done on the desktop level. but if
one wanted to set restrictions by user, it seems like it would almost
have to go into Avahi. therefore patching Avahi to support
restrictions by user and application might be the way to go. that
would definiately go along way toward getting over the objections of
the security minded.

> -- dobey
>
> On Mon, 2006-07-17 at 19:21 -0700, Alan Gibson wrote:
> > ive been doing some research on zeroconf lately and id like to know
> > what everyone thinks about creating a capplet for it. it would
> > basically do two things: 1. start/stop zeroconf daemons 2. disable
> > support in specific applications. the latter is of course potentially
> > complicated because each app will have its own way of doing things.
> >
> > support for zeroconf is growing rapidly, and since there is some
> > reluctance to implementing it based on security concerns, being able
> > to turn off zeroconf could ironically foster its growth.
> >
> > alan