[growl-discuss] Preference Manifest for Mac Managers?

[sourcehound]

Recently, there was some discussion on the Mac Enterprise list
(MACENT...@LISTS.PSU.EDU)of how Adobe snuck a Growl Install in as
part of its own installation registration process, then failed to
clean it up. During the discussion, some network managers expressed a
dislike for, or discomfort with Growl. I do not share that dislike or
discomfort, though I do understand why they might feel that way.

While the Growl Application Framework is a nice step away from a
system-wide Growl for some developers, those of us who are System
Managers would probably appreciate a way to manage Growl alerts for
individual apps using an MCX Preference Manifest that could be used
for Group Policy enforcement. That way, if a System Manager decided
one app needed to use Growl, but didn't want Growl alerts for other
apps, these settings could be managed using centrally.

Here's a PDF from Apple about Preference Manifests.

developer.apple.com/.../Preference_Manifest.../
Preference_Manifest_Files.pdf

Thoughts?

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
To post to this group, send email to growld...@googlegroups.com.
To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.

[Christopher Forsythe]

Ya, I saw that thread. I almost joined, but didn't at the last minute.

Whether an application notifies is stored within the <users>/Application Support/Growl directory I believe, not in Preferences. The link you provided didn't work for me, or I'd have dug into what this is exactly.

We're not opposed to admins trying to run their network. And unfortunately we're stuck in a boat you guys are, in that adobe is installing this and there's no control here. We'll do what we can to help here.

Right now I'm trying to gauge how long it will take to get sparkle integrated into Growl, so that we can at least provide better updating mechanisms on the *next* update. However we have some pretty important fixes to go out, so if it takes too long, we'll probably push 1.2.1 and update version checking in 1.3. And then get slammed with "hey, what's growl" questions from people who shouldn't have to ask them

Can you find the correct link to that document?

Chris

[Peter Hosey]

On May 17, 2010, at 11:57:45, sourcehound wrote:
> Here's a PDF from Apple about Preference Manifests.
>
> developer.apple.com/.../Preference_Manifest.../
> Preference_Manifest_Files.pdf

Here's a complete link to the HTML version:

<http://developer.apple.com/mac/library/documentation/MacOSXServer/Conceptual/Preference_Manifest_Files/>

There are two problems with the idea of a preference manifest for Growl:

- Growl doesn't store the Applications-tab settings as preferences (i.e., using the user defaults system).
- Even if it did, Growl doesn't know in advance what applications will register with it.

So, you could manage the (default) display settings, but that's about it.

[sourcehound]

On May 17, 3:26 pm, Peter Hosey <p...@growl.info> wrote:
> On May 17, 2010, at 11:57:45, sourcehound wrote:
>
> > Here's a PDF from Apple about Preference Manifests.
>
> > developer.apple.com/.../Preference_Manifest.../
> > Preference_Manifest_Files.pdf
>
> Here's a complete link to the HTML version:
>

>         <http://developer.apple.com/mac/library/documentation/MacOSXServer/Con...>

>
> There are two problems with the idea of a preference manifest for Growl:
>
> - Growl doesn't store the Applications-tab settings as preferences (i.e., using the user defaults system).
> - Even if it did, Growl doesn't know in advance what applications will register with it.
>
> So, you could manage the (default) display settings, but that's about it.
>
> --
> You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
> To post to this group, send email to growld...@googlegroups.com.
> To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/growldiscuss?hl=en.

I recognize that it might be a non-trivial matter, but I think you
should be able to set/override the Applications Tab settings using the
User Defaults System, so long as Growl programatically consulted that
list first. As for knowing what would be registered in advance, yes,
there'd have to be a "notification firewall" that would suppress any
application alerts, regardless of registration, and the User defaults
would need to be managed at the Local Domain Level - meaning on a
computer account basis, versus a user account basis. There's already
some good examples of manifests like those in the Manifest Destiny
repository: http://code.google.com/p/manifestdestiny.

I know it's easy to dismiss this request, but if you want Growl to be
taken seriously in the Enterprise / Education world, it's probably a
good idea to consider manageability. I'd imagine that the code it
would take to consult a preference file for "allowed" registrations
would be fairly easy. Please consider it for a future version.

[sourcehound]

On May 17, 2:53 pm, Christopher Forsythe <ch...@growl.info> wrote:
> Ya, I saw that thread. I almost joined, but didn't at the last minute.
>
> Whether an application notifies is stored within the <users>/Application
> Support/Growl directory I believe, not in Preferences. The link you provided
> didn't work for me, or I'd have dug into what this is exactly.
>
> We're not opposed to admins trying to run their network. And unfortunately
> we're stuck in a boat you guys are, in that adobe is installing this and
> there's no control here. We'll do what we can to help here.
>
> Right now I'm trying to gauge how long it will take to get sparkle
> integrated into Growl, so that we can at least provide better updating
> mechanisms on the *next* update. However we have some pretty important fixes
> to go out, so if it takes too long, we'll probably push 1.2.1 and update
> version checking in 1.3. And then get slammed with "hey, what's growl"
> questions from people who shouldn't have to ask them
>
> Can you find the correct link to that document?
>
> Chris
>
>
>
> On Mon, May 17, 2010 at 1:57 PM, sourcehound <dean.sha...@gmail.com> wrote:
> > Recently, there was some discussion on the Mac Enterprise list

> > (MACENTERPR...@LISTS.PSU.EDU)of how Adobe snuck a Growl Install in as

> > part of its own installation registration process, then failed to
> > clean it up. During the discussion, some network managers expressed a
> > dislike for, or discomfort with Growl. I do not share that dislike or
> > discomfort, though I do understand why they might feel that way.
>
> > While the Growl Application Framework is a nice step away from a
> > system-wide Growl for some developers, those of us who are System
> > Managers would probably appreciate a way to manage Growl alerts for
> > individual apps using an MCX Preference Manifest that could be used
> > for Group Policy enforcement. That way, if a System Manager decided
> > one app needed to use Growl, but didn't want Growl alerts for other
> > apps, these settings could be managed using centrally.
>
> > Here's a PDF from Apple about Preference Manifests.
>
> > developer.apple.com/.../Preference_Manifest.../
> > Preference_Manifest_Files.pdf
>
> > Thoughts?
>

Chris,

if you are going to implement Sparkle, you might find that some
Network Managers sort of hate that too. At the very least, provide
some mechanism so that the SU check on startup can be disabled - hey,
like a preference manifest.

Basically, Network Manager want to be able to control all aspects of a
program's behavior. Adding Sparkle to Growl will just make many
dislike Growl more as that's just more uncontrolled prompts they can't
manage. The solution = keep Growl off their machines.

See where I'm going with this?

[Peter Hosey]

On May 17, 2010, at 14:40:10, sourcehound wrote:
> if you are going to implement Sparkle, you might find that some Network Managers sort of hate that too. At the very least, provide some mechanism so that the SU check on startup can be disabled - hey, like a preference manifest.

We already have an updater. Your objection applies equally to it, so your objection really has nothing to do with Sparkle specifically.

Sparkle would actually be a benefit to you, because once you disable the in-app update check, you could have a separate application that checks all installed applications' appcasts for updates you may want. Then you would not only be in control of updating, but have ready access to the feed of updates.

Can you not already manage the preference without a manifest?

[Peter Hosey]

On May 17, 2010, at 14:33:18, sourcehound wrote:
> I think you should be able to set/override the Applications Tab settings using the User Defaults System, so long as Growl programatically consulted that list first.

So if an application or notification is not covered in the user defaults, Growl would still go to its tickets?

> As for knowing what would be registered in advance, yes, there'd have to be a "notification firewall" that would suppress any application alerts, regardless of registration…

Eh?

[Christopher Forsythe]

Since "check for updates" would be in the preferences file, that should be taken care of pretty easily right?

I think you misread things here. Nobody is dismissing things automatically, Peter and I are both just talking about the technical aspects within Growl.

That said, I don't think Growl fits entirely with the network manager view. Growl is so that the *user* can control what notifications they get. If the user isn't able to control that, it's annoying. 

[Peter Hosey]

On May 17, 2010, at 15:26:07, Christopher Forsythe wrote:
> If the user isn't able to control that, it's annoying.

To the user, specifically.

[Christopher Forsythe]

On Mon, May 17, 2010 at 5:28 PM, Peter Hosey <p...@growl.info> wrote:

On May 17, 2010, at 15:26:07, Christopher Forsythe wrote:
> If the user isn't able to control that, it's annoying.

To the user, specifically.

Right, sorry, I needed to be specific.

So the things that users need to have controlled by admins, like Start/Stop of Growl, check for updates, etc etc are all things which are preferences. Even the default display should be in the preferences file.

Since this is the case, do admins really need to be able to configure per application notifications? Especially since we advocate and recommend sane defaults to app devs?

Chris 

[sourcehound]

On May 17, 5:51 pm, Christopher Forsythe <ch...@growl.info> wrote:
> On Mon, May 17, 2010 at 5:28 PM, Peter Hosey <p...@growl.info> wrote:
> > On May 17, 2010, at 15:26:07, Christopher Forsythe wrote:
> > > If the user isn't able to control that, it's annoying.
>
> > To the user, specifically.
>
> Right, sorry, I needed to be specific.
>
> So the things that users need to have controlled by admins, like Start/Stop
> of Growl, check for updates, etc etc are all things which are preferences.
> Even the default display should be in the preferences file.
>
> Since this is the case, do admins really need to be able to configure per
> application notifications? Especially since we advocate and recommend sane
> defaults to app devs?
>
> Chris

The answer is yes, many admins feel the need to be able to control
specifically what dialogs, notifications, alerts, popups, etc. appear
in front of the user. Each unexpected alert is at times considered "an
error" by the end user in many environments and can cause trouble for
the admin who has to take a call, close a ticket, 'splain. There's a
school that says "a silent system is the best system." However, some
admins would want to allow Cyberduck to use Growl notifications, but
might want to disallow Mail.app from using Growl notifications. So I
guess what I'm advocating here is a blacklist / whitelist approach
with the relevant preferences being in /Library/Preferences -
something that overrides the user experience for non-admin (Standard,
Managed, Mobile, Network) user accounts. Essentially, Growl would
check the whitelist / blacklist and act appropriately - skipping the
alert if the rule told it to.

For example, I know of one admin who wrote a very nice emergency
notification system that used Growl to display alerts on computers in
case of fire, flood, etc. However, he had to abandon it when he found
that he was getting lots of calls / complaints about Growl alerts from
other apps on the system.

As far as the Adobe thing goes, sure Adobe was lazy and stupid in
distributing Growl without notice or cleanup. However, it does
highlight the point that Growl in and of itself is not a welcome
citizen on many managed networks and as a fan of Growl, I'd like to
see the developers embrace the challenge of changing that perception
by offering management options.

If admins were able to configure per-computer Growl settings (or per
group settings), they would likely evaluate Growl as a gift rather
than view it as a nuisance. A simple whitelist approach limits the
notifications to "blessed" apps. So if you're an admin that wants
Growl, but doesn't necessarily want alerts blooming all over the
screen, prompting unnecessary questions, then your current choices are
to manage each apps preferences individually (hard) or invest a lot of
time and energy into end-user training (also hard and often
fruitless).

On the other hand, if you are an admin that subscribes to the KISS
method of management (keep it simple stupid) then the solution is to
keep Growl off your standard image.

Some end users might find it annoying that the admins might be
managing their alerts settings. These users also might find it
annoying that their network, energy saver and sharing settings are
locked down too. But whether the admin wins or the user wins is
dependent on a discussion that has nothing to do with whether Growl is
manageable. Many admins will shy away from tools that don't allow
manageability as they have waged hard-fought battles to get the rights
to manage the user experience in the first place. Whether the user
wins that fight or the admin wins that fight is really irrelevant. If
the Developers of Growl give admins manageability, then Growl won't be
considered annoyanceware, which is currently is by more than a few in
the Mac Manager community.

I could go on about Sparkle too, since many admins would rather
repackage their own patches and use whatever tool they have at their
disposal rather than let Sparkle be the agent of updating.

Dean

BTW: should you want to implement something like this, I will be happy
to test it thoroughly for you.

[Chris Forsythe]

A white list is a fine idea. Except that for end users who know what
Growl is would then be calling in.

I think we should have 3 things:

1) Allowed list
2 ) Denied list
3) Overide preference

All of these hidden prefs we document.

However, unless one of the current devs feels like doing this, it'll
require someone submitting a patch. File a ticket on our google code
page, it's a valid concern.

Chris

[Peter Hosey]

On May 17, 2010, at 16:32:50, sourcehound wrote:
> There's a school that says "a silent system is the best system." However, some admins would want to allow Cyberduck to use Growl notifications, but might want to disallow Mail.app from using Growl notifications.

The existing solution to that specific example would be to simply not install GrowlMail. ☺

> A simple whitelist approach limits the notifications to "blessed" apps.

Sounds good. Here's my proposal:

A preference, named in the manifest, whose value (if set) is an array of application names. If this preference is set, it is a white list; Growl will accept registrations from other applications but ignore their notifications. It should also show other applications' names in strike-through type in the preference pane.

[i.aten...@gmail.com]

On 18 May 2010, at 03:28, Peter Hosey wrote:

> On May 17, 2010, at 16:32:50, sourcehound wrote:
>> There's a school that says "a silent system is the best system." However, some admins would want to allow Cyberduck to use Growl notifications, but might want to disallow Mail.app from using Growl notifications.
>
> The existing solution to that specific example would be to simply not install GrowlMail. ☺
>
>> A simple whitelist approach limits the notifications to "blessed" apps.
>
> Sounds good. Here's my proposal:
>
> A preference, named in the manifest, whose value (if set) is an array of application names. If this preference is set, it is a white list; Growl will accept registrations from other applications but ignore their notifications. It should also show other applications' names in strike-through type in the preference pane.
>

I haven’t completely thought this through, particularly with regard to existing installations & registrations (perhaps another pref var ‘resetToWhiteList’ or something), but possibly the aforementioned whitelist could merely denote that all new app registrations apart from those listed default to having their notifications disabled (i.e. when writing the new growlTicket, all notifications have enabled unchecked)?
Then users like me who don’t like to be told how to use their computer by their admin still have full control over their notifications (provided they can reach the prefpane/know how to dive into the ticket).

[Peter Hosey]

On May 18, 2010, at 00:33:34, i.aten...@gmail.com wrote:
> Then users like me who don’t like to be told how to use their computer by their admin still have full control over their notifications (provided they can reach the prefpane/know how to dive into the ticket).

That depends on whether we should uphold our own long-standing policy of users having ultimate control, or let admins use the whitelist to override them.

[Christopher Forsythe]

On Tue, May 18, 2010 at 2:36 AM, Peter Hosey <p...@growl.info> wrote:

On May 18, 2010, at 00:33:34, i.aten...@gmail.com wrote:
> Then users like me who don’t like to be told how to use their computer by their admin still have full control over their notifications (provided they can reach the prefpane/know how to dive into the ticket).

That depends on whether we should uphold our own long-standing policy of users having ultimate control, or let admins use the whitelist to override them.

I think we should maintain this, and can maintain it, while adding the white list feature.

What I think we should do is have the strike through like Peter mentions, and the white list. Add in the "ignore my admin" hidden default, and I think that solves the problem i.atent.dead has.

The only other thing we need to do is make sure it's apparent that this is what's happening, so that the user knows what is going on, if they are like  i.atent.dead.

I don't like the disable everything on registration, because then it's a lot of work to get it back to how users like things, if they know enough to know they want to enable it all. It'd be easier for them to get going with a quick defaults command.

Chris

[Evan Schoenberg, M.D.]

On May 18, 2010, at 9:04 AM, Christopher Forsythe wrote:

> I think we should maintain this, and can maintain it, while adding the white list feature.
>
> What I think we should do is have the strike through like Peter mentions, and the white list. Add in the "ignore my admin" hidden default, and I think that solves the problem i.atent.dead has.
>
> The only other thing we need to do is make sure it's apparent that this is what's happening, so that the user knows what is going on, if they are like i.atent.dead.
>
> I don't like the disable everything on registration, because then it's a lot of work to get it back to how users like things, if they know enough to know they want to enable it all. It'd be easier for them to get going with a quick defaults command.

Does this need to be hidden? Is it possible for Growl to know that it's being overridden at an administrator level? If so, could we just reveal a checkbox, or popup a window when the Growl preferences open, giving the opportunity to override that?

-Evan

[Christopher Forsythe]

On Tue, May 18, 2010 at 9:15 AM, Evan Schoenberg, M.D. <eva...@dreskin.net> wrote:

On May 18, 2010, at 9:04 AM, Christopher Forsythe wrote:

> I think we should maintain this, and can maintain it, while adding the white list feature.
>
> What I think we should do is have the strike through like Peter mentions, and the white list. Add in the "ignore my admin" hidden default, and I think that solves the problem i.atent.dead has.
>
> The only other thing we need to do is make sure it's apparent that this is what's happening, so that the user knows what is going on, if they are like  i.atent.dead.
>
> I don't like the disable everything on registration, because then it's a lot of work to get it back to how users like things, if they know enough to know they want to enable it all. It'd be easier for them to get going with a quick defaults command.

Does this need to be hidden?  Is it possible for Growl to know that it's being overridden at an administrator level? If so, could we just reveal a checkbox, or popup a window when the Growl preferences open, giving the opportunity to override that?

That's a good point. No, not hidden. I just didn't want people who aren't under this restriction to have to see this checkbox and then ping us asking what it was.

Magical unhiding preference is a great idea.

How much work does this white list, strike through, and this disappearing/reappearing preference take to accomplish?

Chris

[sourcehound]

On May 17, 9:28 pm, Peter Hosey <p...@growl.info> wrote:
> On May 17, 2010, at 16:32:50, sourcehound wrote:
>
> > There's a school that says "a silent system is the best system." However, some admins would want to allow Cyberduck to use Growl notifications, but might want to disallow Mail.app from using Growl notifications.
>
> The existing solution to that specific example would be to simply not install GrowlMail. ☺
>
> > A simple whitelist approach limits the notifications to "blessed" apps.
>
> Sounds good. Here's my proposal:
>
> A preference, named in the manifest, whose value (if set) is an array of application names. If this preference is set, it is a white list; Growl will accept registrations from other applications but ignore their notifications. It should also show other applications' names in strike-through type in the preference pane.
>

Peter,

I think you've nailed it perfectly. This would be just the ticket for
managing which applications can send growl alerts at the computer
level. I think with this option, many more Mac Managers would consider
including Growl on their standard images.

[sourcehound]

On May 18, 9:04 am, Christopher Forsythe <ch...@growl.info> wrote:
> On Tue, May 18, 2010 at 2:36 AM, Peter Hosey <p...@growl.info> wrote:

> > On May 18, 2010, at 00:33:34, i.atent.d...@gmail.com wrote:
> > > Then users like me who don’t like to be told how to use their computer by
> > their admin still have full control over their notifications (provided they
> > can reach the prefpane/know how to dive into the ticket).
>
> > That depends on whether we should uphold our own long-standing policy of
> > users having ultimate control, or let admins use the whitelist to override
> > them.
>
> I think we should maintain this, and can maintain it, while adding the white
> list feature.
>
> What I think we should do is have the strike through like Peter mentions,
> and the white list. Add in the "ignore my admin" hidden default, and I think
> that solves the problem i.atent.dead has.
>
> The only other thing we need to do is make sure it's apparent that this is
> what's happening, so that the user knows what is going on, if they are like
>  i.atent.dead.
>
> I don't like the disable everything on registration, because then it's a lot
> of work to get it back to how users like things, if they know enough to know
> they want to enable it all. It'd be easier for them to get going with a
> quick defaults command.
>
> Chris
>

OK, if you add a white list feature, it should not be able to be
overridden by end user in any case. You cannot share control in a
managed environment. When Growl detects the presence of the white list
key and the array of allowed apps, it should simply inform the end
user that the notifications are being managed by their administrator -
and such a convention for System Preferences already exists - add a
"Lock" and use the Security Framework to require authentication to
change any settings in Growl. Now wait before you lose your lunch....

If the managed preference and whitelist do not exist, any user can
unlock the lock, or it is unlocked by *default*. However, if the
management key is in place, the lock is locked by default, and
requires an admin user to authenticate to unlock the
system.preferences right in /etc/authorization.

It's really simple.

1) Growl is working in unmanaged mode, lock is unlocked standard users
can change settings
2) Growl is working in managed mode, lock is locked, admin username/
password required to change any settings or start / stop the Growl
Helper App (simply enable all the controls once the lock is unlocked)
3) Additionally, the whitelist array should support other keys, such
as stickness and alerts style so the admins can control those with
granularity as well

I think using the SFAuthorizationView lock just works, no explanation
or hidden preferences needed - and any user would be able to
understand what was going on.

[Chris Forsythe]

This overrides one of our main goals, giving users the control. I'm ok
with a white list, but the end user must have control.

[sourcehound]

On May 18, 11:22 pm, Chris Forsythe <ch...@growl.info> wrote:

What do you mean by control here? A whitelist implies that the admin
decides which applications can use Growl. I'm not really understanding
here. Please clarify. Are you saying that

a) Admins should be set a whitelist of allowed apps but a standard
user can override that whitelist on their own?

or

b) End users cannot add alerts for additional apps on their own, but
can customize the alerts settings for predefined whitelisted apps

In any case, please consider extending the white list to provide
alerts style and sticky settings for the whitelist so the admin can
set those for consistency throughout the organization.

That way, the admin an use the existing MCX settings to deny access to
the Growl System Preference altogether, but still manage the alerts
through MCX as well. That would work, and require no compromise in the
project's foundational goals.

> > For more options, visit this group athttp://groups.google.com/group/growldiscuss?hl=en

[Peter Hosey]

On May 18, 2010, at 07:15:01, Evan Schoenberg, M.D. wrote:
> Is it possible for Growl to know that it's being overridden at an administrator level?

Growl itself would be doing the application-ignoring, pursuant to the whitelist pref. There's not really any reason for it to care whether it's set by Workgroup Manager or not, since it's not something a user would ordinarily set.

[Peter Hosey]

On May 18, 2010, at 21:22:20, Chris Forsythe wrote:
> This overrides one of our main goals, giving users the control. I'm ok with a white list, but the end user must have control.

I think the rules are different in a managed environment. It's not the user's computer, it's (effectively) the admin's, so it's the admin who should have control.

The user needs to have *some* control, such as the ability to disable certain notifications and to customize their display to their taste, but when there is an admin, the admin should have the power to set whatever limits they see fit, including an exclusive list of applications allowed to post Growl notifications. Allowing the user to override such a list undermines that power.

So, I think Growl should simply obey the whitelist, at least when it is enforced, and display (one way or another) that there is one.

[Peter Hosey]

On May 18, 2010, at 20:18:20, sourcehound wrote:
> … add a "Lock" and use the Security Framework to require authentication to change any settings in Growl. …
>
> It's really simple.

I assure you that implementing authorization for anything is the opposite of simple.

As far as I can tell from the docs, this feature is impossible. Quoth the CF Preferences Utilities documentation:

> [CFPreferencesAppValueIsForced returns] true if value of the key cannot be changed by the user, otherwise false.

“cannot be changed”. This implies that it is flat-out impossible for the user to change any preference that is set from on high.

[sourcehound]

On May 19, 2:53 am, Peter Hosey <p...@growl.info> wrote:
> On May 18, 2010, at 20:18:20, sourcehound wrote:
>
> > … add a "Lock" and use the Security Framework to require authentication to change any settings in Growl. …
>
> > It's really simple.
>
> I assure you that implementing authorization for anything is the opposite of simple.
>
> As far as I can tell from the docs, this feature is impossible. Quoth the CF Preferences Utilities documentation:
>
> > [CFPreferencesAppValueIsForced returns] true if value of the key cannot be changed by the user, otherwise false.
>
> “cannot be changed”. This implies that it is flat-out impossible for the user to change any preference that is set from on high.
>

Peter,

since you can disable a System Preference Pane entirely as part of the
standard feature set of Workgroup Manager, then it's not really
necessary for the Growl Dev Team to do anything except implement the
white list and notify the user. I agree with you that, once in place,
the whitelist should not be overridden by managed users. The
suggestion to use SFAuthorizationView was unnecessary, sorry.

[Derik DeLong]

Not that I should butt in, but I don't see the point of disallowing
users from using Growl with applications other than the whitelisted
applications. I could understand an admin wanting a white list that
limits the number of Growl alerts, reducing user tickets.

However, if a Growl supporting application is installed in the system
(which I would expect would require administrator access to install in
the first place), what's the reasoning behind restricting a user from
viewing its Growl alerts? The information it would publish via Growl
is just accessible within the application itself, so the only thing
you'd accomplish is making it harder for users to be informed about
data they already have access to.

Unless I'm missing something. (This is all from the perspective of
someone who regularly works in managed environments.)

[sourcehound]

On May 19, 8:54 am, Derik DeLong <ddel...@gmail.com> wrote:
> Not that I should butt in, but I don't see the point of disallowing
> users from using Growl with applications other than the whitelisted
> applications.  I could understand an admin wanting a white list that
> limits the number of Growl alerts, reducing user tickets.
>
> However, if a Growl supporting application is installed in the system
> (which I would expect would require administrator access to install in
> the first place), what's the reasoning behind restricting a user from
> viewing its Growl alerts?  

Like I said, it doesn't really matter because with the whitelist in
place, if an admin wants to block access to Growl entirely but
maintain the white listed alerts, it's just a matter of blocking
access to the Growl Preference Pane, which is trivial and takes the
burden off of the Developers, leaving it up to the admin to decide
whether they want the user to be able to configure more Growl
settings. So no, I don't disagree with you Derik. However, I would
advocate that the whitelist allow for setting the alert style and
stickiness so that if the admin does decide to block access to the
Growl System Preference Pane they can also ensure that the alerts are
consistent from user to user (or that they can change the style or
stickiness centrally without having to touch each machine).

As far as apps that support Growl being installed by an admin - let's
just say that some apps support Growl alerts in a meaningful way,
others in an annoying and distracting way (this is all subjective of
course). All it takes is one essential app with a poor Growl
implementation (Adobe) and therefore it's easy to turn thumbs down on
Growl as a whole. For example, there's some apps that will literally
fill your screen with sticky Growl alerts of a repeated message. Bad
behavior. As an admin, I'd like to keep that app, but manage its
ability to use Growl. If the app were essential, and I had to choose
between it and Growl, I'd probably choose the app. That's the whole
point of this discussion / feature request- not to have Growl fall
victim to one vendor or programmer's poor use of it.

[Christopher Forsythe]

I mean that in the end, the end user can decide what they get notified for.

If the admin decides to notify for something which is quite not in the interest of the end user, and the end user knows enough about Growl to get around the admins control, then they should be allowed to do that.

[Christopher Forsythe]

On Wed, May 19, 2010 at 2:59 AM, Peter Hosey <p...@growl.info> wrote:

On May 18, 2010, at 21:22:20, Chris Forsythe wrote:
> This overrides one of our main goals, giving users the control. I'm ok with a white list, but the end user must have control.

I think the rules are different in a managed environment. It's not the user's computer, it's (effectively) the admin's, so it's the admin who should have control.

It's not the admins either, it's effectively the companies. The admin is paid to maintain it. The motivation here is that the admin doesn't want to get support requests, from my understanding of having been an admin, supporting them, and also my reading of sourcehounds emails.

 

The user needs to have *some* control, such as the ability to disable certain notifications and to customize their display to their taste, but when there is an admin, the admin should have the power to set whatever limits they see fit, including an exclusive list of applications allowed to post Growl notifications. Allowing the user to override such a list undermines that power.

What sourcehound is advocating is that the admin be able to set *all* preferences, *all* application settings, and not give the user any control, whatsoever.

If the user knows enough about how to use the defaults command, and finds our documentation on the website about how to disable the whitelist, imho then they will not be contacting the admin to file support requests.

I don't know of any admin who would care about that level of control, other than to not get support tickets about it.

 

So, I think Growl should simply obey the whitelist, at least when it is enforced, and display (one way or another) that there is one.

 

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
To post to this group, send email to growld...@googlegroups.com.
To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.

[Christopher Forsythe]

All it takes is one overzealous admin to make the wrong choice and annoy 500 end users, who would then have 0 control to turn it off themselves or change things, per what you are advocating.

The problem can go both ways.

Chris 

[i.aten...@gmail.com]

On 19 May 2010, at 23:36, Christopher Forsythe wrote:

> > OK, if you add a white list feature, it should not be able to be
> > overridden by end user in any case.
>
> This overrides one of our main goals, giving users the control. I'm ok  
> with a white list, but the end user must have control.

What do you mean by control here?

I mean that in the end, the end user can decide what they get notified for.

If the admin decides to notify for something which is quite not in the interest of the end user, and the end user knows enough about Growl to get around the admins control, then they should be allowed to do that.

Exactly. 

For a regular user of growl, the admin’s set of notifications I expect would be quite limited (as they are aiming for “don’t upset or confuse unaware users”). So for me as a regular user, I would almost certainly want to be able to at least enable any others I like. I can see a reasonable argument for not being able to disable those notifications whitelisted (especially if they’re being used eg. to push notifications by the admin as previously mentioned), although I’d rather expect that the admin could rely on aware users to behave themselves in this respect, rather than force things.

From my point of view, this comes down to what we want to achieve:

Do we want to allow admins to blanket apply a default set of notifications and configurations thereof, to stop support cases from unaware users (and other benefits)?

or

Do we want to give admins absolute power over everything? (because they like the taste? i don’t really know what a good reason is, but then i’m not exactly sitting on the fence…)

Josh

[sourcehound]

On May 20, 2:28 am, i.atent.d...@gmail.com wrote:
> On 19 May 2010, at 23:36, Christopher Forsythe wrote:
>
> > > > OK, if you add a white list feature, it should not be able to be
> > > > overridden by end user in any case.
>
> > > This overrides one of our main goals, giving users the control. I'm ok  
> > > with a white list, but the end user must have control.
>
> > What do you mean by control here?
>
> > I mean that in the end, the end user can decide what they get notified for.
>
> > If the admin decides to notify for something which is quite not in the interest of the end user, and the end user knows enough about Growl to get around the admins control, then they should be allowed to do that.
>
> Exactly.
> For a regular user of growl, the admin’s set of notifications I expect would be quite limited (as they are aiming for “don’t upset or confuse unaware users”). So for me as a regular user, I would almost certainly want to be able to at least enable any others I like. I can see a reasonable argument for not being able to disable those notifications whitelisted (especially if they’re being used eg. to push notifications by the admin as previously mentioned), although I’d rather expect that the admin could rely on aware users to behave themselves in this respect, rather than force things.

Admins just want the flexibility to manage things.

>
> From my point of view, this comes down to what we want to achieve:
> Do we want to allow admins to blanket apply a default set of notifications and configurations thereof, to stop support cases from unaware users (and other benefits)?

Admins already have this. It's call "Growl isn't going on my systems"

> or
> Do we want to give admins absolute power over everything? (because they like the taste? i don’t really know what a good reason is, but then i’m not exactly sitting on the fence…)

It's not up to you or any of the Growl Developers to make this call.
Admins already do have full control of everything (see my response to
Christopher) including whether or not to allow Growl on the system.

Here's what the admins have control over:

1) Decision to include Growl or not (there's nothing the Dev Team can
do except *encourage* other software to install Growl like Adobe did
and that's not a good strategy). So admins win here.
2) Application registrations. While making the standard image that
goes on all managed machines, the admin can decide which Growl apps
are registered and set alerts styles. If the access to the Growl
System Preference pane is block via Workgroup Manager, the end users
cannot change update the settings. So admins win here.

So, admin control seems pretty absolute to me with the current
situation. Now if a whitelist were implemented then -

3) Admins could managed the allowed applications alerts centrally,
without re-imaging their machines or touching them with a script or
patching them. If the white list were extended to include alert styles
and stickiness, then effectively Growl would get centralized
manageability for *free* and win a lot of warm fuzzies from the
control freak admin community, as well as be able to stop alerts from
rogue installs (cough cough Adobe).

What I guess I'm saying is that the argument of whether admins should
get absolute control is pointless. They already have it. I am
advocating a layer of manageability that would make choice 3) more
amenable than choices 1) which is easy and choice 2) which is a "set
it once and forget it or go back and patch it" scenario.

For everyone involved in this discussion, I am grateful that you are
considering the white list idea. I think it would be a fairly
straightforward change, and would be well-received.

Dean

[sourcehound]

On May 19, 5:43 pm, Christopher Forsythe <ch...@growl.info> wrote:

That is really besides the point. If an admin screws up, it's their
fault. Not Growl's fault. If an admin removes Growl from their
computers because they screwed up, then that's their choice as a
result of their incompetence. If someone else - either an end user or
a vendor introduces something that triggers Growl alerts the admin
doesn't want, Growl will be removed or not included on the next
standard image.

Philosophical arguments aside, I am seeing here a resistance to giving
admins complete control. I really don't understand why. But it doesn't
matter.

Why doesn't it matter?

As a admin on a managed system, I already have the tools to stop the
end user from managing / setting Growl alerts. There's nothing the
Growl Dev Team can do to stop it. I can simply deny access to the
Growl System Preference pane. So I concede that part of the argument.
The Growl Dev team can implement a whitelist while letting the end
user override it in any way, shape or form.

But please, please, allow the white list to also specify alert style
and stickiness settings.

However, if at some point I want to remove a registered app, or change
the alerts style for one app, I don't want to have to reimage all of
my machines or touch them all with a script. Changing the managed
preferences on the server would alter the whitelist and all of the
installed Growl instances would then change their behavior on the next
login or reboot. That's a GOOD thing. That's not something Adobe or
any other vendor can override, even though their products are
installed with local admin access, it is only for the machine, not the
directory where the settings are managed.

So as far as I'm concerned, if you implement the white list, I will
have my cake. As far as a defaults command or end user overrides go,
do what you will.