On Fri, Nov 1, 2019 at 10:39 AM Stephen Dowdy <[email protected]> wrote:

> On 11/1/19 9:21 AM, Mike Kaply wrote:
> > You can deploy extensions as a part of Firefox by putting them in the
> distribution/extensions directory and then locking them via policy.
> >
> > This has always been a better way then putting them in system
> directories where they might not get updated properly.
>
> Mike, i composed the below before this current response from you came out,
> but it
> sounds like, firefox will STILL support APPDIR extensions deployment, but
> not user
> PROFDIR deployments  (this changes the extensions.*scopes preferences
> functionality
> i would assume.)   So, is there a guide on how the old-school stuff should
> now be
> done with Policies?
>

The thing that is going away is the concept of sideloading where you put
extensions in a central location and they get loaded into Firefox and the
user can't remove them (they can only disable them).

You will still be able to put extensions into distribution/extensions
because they simply get installed into Firefox as normal extensions.


>
> To be blunt:  I really still am puzzled by the entire Policies thing, as
> the autoconfig
> stuff (to me) seems to be more useful/functional and stuff like
> locking/defaulting
> Policies was bolted on after it was discovered they didn't offer the same
> functionality
> of defaultPref() lockPref() etc...  (i.e. it seems to be playing catchup
> rather than
> offering me something of value.  Security? Maintainability? ?)
>

autoconfig for setting/locking preferences continues to be available and
will always be available. The only thing being locked down in autoconfig on
release (not ESR) is the fact that you could use autoconfig to bypass
Firefox security and access everything in Firefox (this is how the CCK2
works).

The reason I haven't made every preference available in policy is:

1. There are way too many preferences.
2. Folks change a ton of preferences without having any idea what they do.

I still ponder this every so often, but then I see some of the preferences
people change and bang my head against a wall.

If there are prefs you need, please let me know.


>
> There seems to be a lot of chaos for what i don't see as a benefit.  It
> appears a lot
> of us are getting frustrated over having to bang our heads on just
> maintaining status-quo
> operations, and if there is some well-defined reasoning, getting some
> better P.R.
> out on that might help.  (for me, the camel that broke my back was
> removing 'user.js'
> functionality for one freakin' stat() call of "performance".  this is just
> insane)
> (i have been cursing Mozilla for the past year over these types of things,
> though)
>

I don't think user.js has been removed yet, has it?

user.js isn't just about performance. We've seen malware using user.js to
do some serious hijacking of Firefox.

A lot of what we do is in the interest of protecting users. Folks don't see
all the terrible ways these various mechanisms are used to ruin user
experience.

By moving to policies, we can have a standard way to do things and stop the
hodgepodge we had before (which I largely created).



>
> I really appreciate you *personally* being so engaged and responsive,
> however. So
> a big Thank You for that.
>

Thanks

Mike


>
> --stephen
>
>
> -----  (previously composed message) -----
>
> This is totally unclear to me what's happening (from the blog post). Does
> this
> apply to the APPDIR 'extensions' folders? (it seems clear it applies to
> PROFDIR
> extensions folders). If so, PLEASE tell me how i am supposed to support an
> enterprise install that has preloaded extensions in a SYSADMIN controlled
> space?
> (at least for linux)
>
> I don't presently do this for *firefox*, but i do for 'thunderbird' (yeah,
> the announcement doesn't say tbird, but i presume it'll hit there
> sometime) I
> load 'mailredirect' because thunderbird fails to offer that function. (into
> /usr/local/thunderbird/extensions/{..}.xpi) and presently, until
> 'enigmail' is
> replaced by builtin PGP functionality, i add that, too.
>
> Replacing a programmatic install with site-selected addons with
> a request for interactive action:
>      "Hey, user, please go to A.M.O. and download this addon
>       after you start the app the first time",
> is totally untenable.
>
>
> thanks,
> --stephen
> _______________________________________________
> Enterprise mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/enterprise
>
> To unsubscribe from this list, please visit
> https://mail.mozilla.org/listinfo/enterprise or send an email to
> [email protected] with a subject of "unsubscribe"
>
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
[email protected] with a subject of "unsubscribe"

Reply via email to