Prevent system-installed add-on from opening new tab on first launch of Firefox

[The Wanderer]

TL;DR: How can we administer and control the internal configuration of
WebExtensions we didn't write ourselves, the way we used to be able to
use e.g. autoconfig to set extension-specific preferences?



At my workplace, we're currently testing out a situation in which
computers have both Firefox (ESR 91.4) and Adobe Acrobat Professional DC
(named-user licensing) preinstalled.

On a computer with Adobe Acrobat Professional DC installed, the first
time Firefox is launched with a given profile, a tab opens to a URL
touting an extension shipped with Acrobat DC which provides some
potentially useful functionality. If knowing the URL involved or the
exact identity of the extension would be helpful, I can provide that
information.

On subsequent launches, this tab does not appear.


We deploy configuration to specify a predefined home page in Firefox,
and to configure Firefox to come up with that page by default. We also
deploy various shortcuts which are intended to open Firefox to a
specific page. We therefore want to make sure that when Firefox is
launched, it comes up with the specified page as the one that is visible.

With this extension in place (because Acrobat Professional DC is
installed), what happens instead is that before the user can see and
react to the specified page, the new tab opens, and the browser switches
to it in place of the one which we wanted to display. From the user's
perspective, the browser has just opened to this page, instead of the
one they expected.

It is not uncommon for us to have people moving between computers, and
thus, launching Firefox on a computer where they have never before
logged in. This will give them a clean Windows profile, and therefore a
new Firefox profile, and therefore lead to this extension opening this
new tab on the first launch. As a result, this isn't something we can
just discount on the grounds that it will only happen once per user.

This extension could be useful to have available. I don't want to
disable it outright, as I believe can be easily done through
policies.json or the Group Policy equivalent; I would prefer to leave it
in place, so that our users can take advantage of it when they see fit.
I just want to be able to handle the notification and education for it
via organization-internal channels, rather than via this automatic
pop-up - especially because that pop-up will continue to appear on new
computers, even when the user has already seen it on another computer.


In the pre-WebExtensions world, this extension would have used the
Firefox preferences system (which is user-visible through about:config)
to store its record of the fact that the first-run tab had been
displayed. We would therefore have been able to use some appropriate
mechanism (such as autoconfig) to pre-set the appropriate pref, and
prevent the tab from appearing.

In the WebExtensions world, however, the extension instead stores this
record in the local storage made available via the storage API. I have
dug into the JS code of the extension itself, and identified exactly
where the tab opening work is done; it is conditioned only on a value
retrieved from local storage. I can provide the exact code (with
irrelevant parts elided) if desired.


Is there any reasonable / practical way we can access the local storage
which will be used by this extension, to pre-define this setting, and
thereby prevent this extension from opening this new tab?

If not, is there any other way we can potentially get the extension to
not open the tab on first launch, while still keeping the extension
installed and enabled (so that its functionality available for users to
access)?

More generally, what is the intended successor for the ability to manage
extension configuration which used to be provided by the ability to
control the section of Firefox preferences where extensions stored their
configuration settings?

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Mike Kaply]

So we don't have any control over what the extension does.

Extensions can implement policy themselves (https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/) and then you can manage the extension like any other policy.

I would suggest reaching out to the extension provider and asking them to add policy and they can reach out to me if they need any help.

I've worked with other folks to add support (it's quite easy)

Mike

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61BFC721.9060603%40fastmail.fm.

[Mike Kaply]

Apparently other people have complained about this to Adobe as well:

https://community.adobe.com/t5/acrobat-discussions/the-first-time-the-chrome-extension-is-enabled-how-can-i-disable-the-new-tab-pop-up/td-p/10481464

https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/40575055-adobe-chrome-extension-first-run-page-launch

Mike

[The Wanderer]

(Please don't CC me on replies unless you expect that I may miss
noticing the response otherwise and you specifically want to draw my
attention to it. I am subscribed to the mailing list, and I read it, so
replying to the mailing list - as should be the default behavior with
any discussion forum - is enough to put the reply where I can see it.)

(I would also prefer if replies were not top-posted, but rather
interleaved in the way I've done here, but I suspect that that's too
much of a lost cause to even be worth asking for hereabouts.)

On 2021-12-20 at 10:48, Mike Kaply wrote:

> So we don't have any control over what the extension does.

Not unless we can intervene in such a way as to set the contents of the
internal storage which the extension reads to determine whether the tab
has already been opened, much as we used to be able to intervene in such
a way as to set the Firefox preferences which such extensions used to
read for such purposes.

I don't see any inherent reason it shouldn't be possible to grant the
ability to do that, but it doesn't seem to be possible to do it at
present, and I can hypothesize that adding that ability might be
rejected on the grounds that such an ability would be open to abuse by
third parties with malicious intentions. (Though just offhand the
details of how that would be a risk are not clear to me.)

I really do see the loss of ability to manage extension settings, which
came with the move from having extensions store their settings as
Firefox preferences to having them store their settings in a separate
storage space, as a regression. I don't see any way to resolve that
regression without providing the ability to manage the contents of that
separate storage space, much as we could/can manage Firefox preferences.

> Extensions can implement policy themselves (
> https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/)
> and then you can manage the extension like any other policy.
>
> I would suggest reaching out to the extension provider and asking them to
> add policy and they can reach out to me if they need any help.
>
> I've worked with other folks to add support (it's quite easy)

Given that this is Adobe (with everything that implies about
responsiveness to user complaints), and that this extension is installed
as part of Acrobat Professional (with everything that implies about the
intervening lag between the release of an updated version of the
extension and the point when we have it present and can rely on it), I
am not holding my breath or out a lot of hope on this front.

It's important for enterprises to be able to manage extension
configuration without needing cooperation from the extension provider.
The providers can have incentives which are at odds with the interests
of the enterprise or its users.

On 2021-12-20 at 10:51, Mike Kaply wrote:

> Apparently other people have complained about this to Adobe as well:
>
> https://community.adobe.com/t5/acrobat-discussions/the-first-time-the-chrome-extension-is-enabled-how-can-i-disable-the-new-tab-pop-up/td-p/10481464
> https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/40575055-adobe-chrome-extension-first-run-page-launch

I went looking myself, but didn't find these - perhaps because I was
specifically looking for things about the Firefox extension, not a
Chrome extension.

The response in those places - or, rather, mostly the lack thereof -
tends to serve to reinforce my lack of confidence that reaching out to
Adobe about this would accomplish anything.

[Mike Kaply]

On Mon, Dec 20, 2021 at 10:05 AM The Wanderer <wand...@fastmail.fm> wrote:

On 2021-12-20 at 10:48, Mike Kaply wrote:

> So we don't have any control over what the extension does.

Not unless we can intervene in such a way as to set the contents of the
internal storage which the extension reads to determine whether the tab
has already been opened, much as we used to be able to intervene in such
a way as to set the Firefox preferences which such extensions used to
read for such purposes.

I don't see any inherent reason it shouldn't be possible to grant the
ability to do that, but it doesn't seem to be possible to do it at
present, and I can hypothesize that adding that ability might be
rejected on the grounds that such an ability would be open to abuse by
third parties with malicious intentions. (Though just offhand the
details of how that would be a risk are not clear to me.)

First off, there are a couple ways that extensions can store settings (localStorage and chrome.storage.*).

Secondly, a typical person would have no way to take apart the extension and discover the various names of the settings they needed as well as the mechanism that was setting those preferences. Most extensions are so obfuscated, you can't get any information out of them.

I really do see the loss of ability to manage extension settings, which
came with the move from having extensions store their settings as
Firefox preferences to having them store their settings in a separate
storage space, as a regression. I don't see any way to resolve that
regression without providing the ability to manage the contents of that
separate storage space, much as we could/can manage Firefox preferences.

That's why enterprise management of extension settings was introduced.

 

> Extensions can implement policy themselves (
> https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/)
> and then you can manage the extension like any other policy.
>
> I would suggest reaching out to the extension provider and asking them to
> add policy and they can reach out to me if they need any help.
>
> I've worked with other folks to add support (it's quite easy)

Given that this is Adobe (with everything that implies about
responsiveness to user complaints), and that this extension is installed
as part of Acrobat Professional (with everything that implies about the
intervening lag between the release of an updated version of the
extension and the point when we have it present and can rely on it), I
am not holding my breath or out a lot of hope on this front.

It's important for enterprises to be able to manage extension
configuration without needing cooperation from the extension provider.
The providers can have incentives which are at odds with the interests
of the enterprise or its users.

In my experience, extension developers are more than happy to add extension management because it usually means more users of their extension.

I'm reaching out to our Adobe contacts with regards to this.

Mike Kaply

 

On 2021-12-20 at 10:51, Mike Kaply wrote:

> Apparently other people have complained about this to Adobe as well:
>
> https://community.adobe.com/t5/acrobat-discussions/the-first-time-the-chrome-extension-is-enabled-how-can-i-disable-the-new-tab-pop-up/td-p/10481464
> https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/40575055-adobe-chrome-extension-first-run-page-launch

I went looking myself, but didn't find these - perhaps because I was
specifically looking for things about the Firefox extension, not a
Chrome extension.

The response in those places - or, rather, mostly the lack thereof -
tends to serve to reinforce my lack of confidence that reaching out to
Adobe about this would accomplish anything.

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61C0A9A0.3010201%40fastmail.fm.

[The Wanderer]

On 2021-12-20 at 11:23, Mike Kaply wrote:

> On Mon, Dec 20, 2021 at 10:05 AM The Wanderer <wand...@fastmail.fm>
> wrote:
>
>> On 2021-12-20 at 10:48, Mike Kaply wrote:
>>
>>> So we don't have any control over what the extension does.
>>
>> Not unless we can intervene in such a way as to set the contents of
>> the internal storage which the extension reads to determine whether
>> the tab has already been opened, much as we used to be able to
>> intervene in such a way as to set the Firefox preferences which
>> such extensions used to read for such purposes.
>>
>> I don't see any inherent reason it shouldn't be possible to grant
>> the ability to do that, but it doesn't seem to be possible to do it
>> at present, and I can hypothesize that adding that ability might
>> be rejected on the grounds that such an ability would be open to
>> abuse by third parties with malicious intentions. (Though just
>> offhand the details of how that would be a risk are not clear to
>> me.)
>
> First off, there are a couple ways that extensions can store
> settings (localStorage and chrome.storage.*).

Are these implemented differently, then? I kind of thought there'd only
be a need for one backend, regardless of the different APIs for
accessing it.

In this case, based on the function calls that are used to read the
setting (which certainly don't involve anything chrome.*, at least not
visibly), I'm fairly sure it's localStorage.

> Secondly, a typical person would have no way to take apart the
> extension and discover the various names of the settings they needed
> as well as the mechanism that was setting those preferences. Most
> extensions are so obfuscated, you can't get any information out of
> them.

A typical person, probably not - but this sort of analysis and (if
necessary) reverse engineering is a relatively core part of application
deployment in an enterprise, at least if my experience with it over the
past decade or so is any guide; there are far, far too many cases where
it's necessary to deploy an application with something other than its
default settings, and this sort of thing is far too often the only
viable way to do so. There are limits to how far it can reasonably go,
but in many cases it's entirely practical to manage.

When the settings are stored in the Registry, it's not difficult to (in
effect) run a diff on the Registry before and after the change, and
identify where the setting must live. When the settings are stored in
the Firefox preferences system, it's not difficult to (quite literally)
run a diff between the prefs.js before and after the change.

When the setting is in the storage system that's made available to
extensions, it's more difficult to carry out the diff and analyze the
results, but still by no means impossible. I actually found the setting
and where it's stored well before I managed to dig into the extension's
code and confirm that this is actually the relevant setting (because the
name doesn't seem to have anything to do with the behavior involved).

Just because it's difficult in many cases doesn't mean that it's so
niche that it's not worth accommodating.

The obfuscators don't always win the war against the analyzers.

>> I really do see the loss of ability to manage extension settings,
>> which came with the move from having extensions store their
>> settings as Firefox preferences to having them store their settings
>> in a separate storage space, as a regression. I don't see any way
>> to resolve that regression without providing the ability to manage
>> the contents of that separate storage space, much as we could/can
>> manage Firefox preferences.
>
> That's why enterprise management of extension settings was
> introduced.

To me, enterprise management of extension settings would include the
ability to modify extension internal storage values like this, because
that is where extensions store their settings.

I looked through the policies.json documentation (version 3.4, IIRC) for
exactly this, and did not find anything that looked like it would let me
configure extension internal settings. If there's something I've missed,
please do point me to it; I'd be glad to be corrected.

>>> Extensions can implement policy themselves (
>>> https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/
>>> )
>>> and then you can manage the extension like any other policy.
>>>
>>> I would suggest reaching out to the extension provider and asking
>>> them to add policy and they can reach out to me if they need any
>>> help.
>>>
>>> I've worked with other folks to add support (it's quite easy)
>>
>> Given that this is Adobe (with everything that implies about
>> responsiveness to user complaints), and that this extension is
>> installed as part of Acrobat Professional (with everything that
>> implies about the intervening lag between the release of an updated
>> version of the extension and the point when we have it present and
>> can rely on it), I am not holding my breath or out a lot of hope on
>> this front.
>>
>> It's important for enterprises to be able to manage extension
>> configuration without needing cooperation from the extension
>> provider. The providers can have incentives which are at odds with
>> the interests of the enterprise or its users.
>
> In my experience, extension developers are more than happy to add
> extension management because it usually means more users of their
> extension.

I'd expect that of a reasonable community-interacting developer, yes. I
just don't expect it of a corporate ship-the-extension-with-the-program
developer such as Adobe. I expect the incentives in their case to come
down to "well, if we let people disable this pop-up tab then fewer
people will see the notification and know about the extension in order
to use it, so the extension won't get as many users, and we won't get as
much mindshare".

I am *decidedly* cynical about corporate attitudes towards software, and
Adobe has less of my trust than many other corporations might, given
that they've already poisoned the well to some degree by way of their
licensing practices.

> I'm reaching out to our Adobe contacts with regards to this.

I appreciate your taking this up, and if this does go anywhere I'll be
very grateful to you for it.

I just don't have much hope that it will.

[Jason Jackson]

Alternatively, you can do this in your deployment of Acrobat using the Acrobat Customization Wizard DC.  I believe the setting for this is Features > Create Adobe PDF > Acrobat PDFMaker > Mozilla Firefox and Google Chrome > Initial State.

https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/features.html

 

Jason Jackson

 

 

From: enter...@mozilla.org <enter...@mozilla.org> On Behalf Of Mike Kaply
Sent: December 20, 2021 8:24 AM
To: Mozilla.org <enter...@mozilla.org>
Subject: [EXTERNAL] Re: [Mozilla Enterprise] Prevent system-installed add-on from opening new tab on first launch of Firefox

 

 

CAUTION: This email originated from outside of the NVSD44. Do not click on links or open attachments unless you have verified the identity of the sender and know the content is safe. If in doubt, contact xpr...@sd44.ca.

 

On Mon, Dec 20, 2021 at 10:05 AM The Wanderer <wand...@fastmail.fm> wrote:

On 2021-12-20 at 10:48, Mike Kaply wrote:

> So we don't have any control over what the extension does.

Not unless we can intervene in such a way as to set the contents of the
internal storage which the extension reads to determine whether the tab
has already been opened, much as we used to be able to intervene in such
a way as to set the Firefox preferences which such extensions used to
read for such purposes.

I don't see any inherent reason it shouldn't be possible to grant the
ability to do that, but it doesn't seem to be possible to do it at
present, and I can hypothesize that adding that ability might be
rejected on the grounds that such an ability would be open to abuse by
third parties with malicious intentions. (Though just offhand the
details of how that would be a risk are not clear to me.)

 

First off, there are a couple ways that extensions can store settings (localStorage and chrome.storage.*).

 

Secondly, a typical person would have no way to take apart the extension and discover the various names of the settings they needed as well as the mechanism that was setting those preferences. Most extensions are so obfuscated, you can't get any information out of them.

 

I really do see the loss of ability to manage extension settings, which
came with the move from having extensions store their settings as
Firefox preferences to having them store their settings in a separate
storage space, as a regression. I don't see any way to resolve that
regression without providing the ability to manage the contents of that
separate storage space, much as we could/can manage Firefox preferences.

 

That's why enterprise management of extension settings was introduced.

 

> Extensions can implement policy themselves (
> https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/)
> and then you can manage the extension like any other policy.
>
> I would suggest reaching out to the extension provider and asking them to
> add policy and they can reach out to me if they need any help.
>
> I've worked with other folks to add support (it's quite easy)

Given that this is Adobe (with everything that implies about
responsiveness to user complaints), and that this extension is installed
as part of Acrobat Professional (with everything that implies about the
intervening lag between the release of an updated version of the
extension and the point when we have it present and can rely on it), I
am not holding my breath or out a lot of hope on this front.

It's important for enterprises to be able to manage extension
configuration without needing cooperation from the extension provider.
The providers can have incentives which are at odds with the interests
of the enterprise or its users.

 

In my experience, extension developers are more than happy to add extension management because it usually means more users of their extension.

 

I'm reaching out to our Adobe contacts with regards to this.

 

Mike Kaply

 

On 2021-12-20 at 10:51, Mike Kaply wrote:

> Apparently other people have complained about this to Adobe as well:
>
> https://community.adobe.com/t5/acrobat-discussions/the-first-time-the-chrome-extension-is-enabled-how-can-i-disable-the-new-tab-pop-up/td-p/10481464
> https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/40575055-adobe-chrome-extension-first-run-page-launch

I went looking myself, but didn't find these - perhaps because I was
specifically looking for things about the Firefox extension, not a
Chrome extension.

The response in those places - or, rather, mostly the lack thereof -
tends to serve to reinforce my lack of confidence that reaching out to
Adobe about this would accomplish anything.

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61C0A9A0.3010201%40fastmail.fm.

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/CAHueOzBOf%2Bpr6nOGNZ5kHh%2BGF_UKVDSF0-XYzyJ9Et4by7MT2w%40mail.gmail.com.

[The Wanderer]

On 2021-12-22 at 13:04, Jason Jackson wrote:

> Alternatively, you can do this in your deployment of Acrobat using
> the Acrobat Customization Wizard DC. I believe the setting for this
> is Features > Create Adobe PDF > Acrobat PDFMaker > Mozilla Firefox
> and Google Chrome > Initial State.
>
> https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/features.html

Is that still applicable when deploying Acrobat via Adobe Creative
Cloud, for named-user licensing?

I've had the impression that it isn't, and that the only customization
you can do there is what's offered via the online Creative Cloud
package-creation tool, which last I checked didn't seem to offer a
setting for this.

It'd be worth checking again in case I'm misremembering or in case
that's changed, however. Thanks for the suggestion; I'll follow up on
that. (When I return to work; we're currently out for holiday break.)

[Marc Meltzer]

As someone who has way too much experience with this, I can answer.

You can't use the customization wizard if you are installing Acrobat directly from the Cloud. You would have to go into your enterprise's Admin Console and create the Acrobat package to download. Once downloaded, you can then customize the installer with the wizard. Since the default is to use Named User licenses, this works.

Marc

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61C36B8C.7000201%40fastmail.fm.

[The Wanderer]

On 2021-12-23 at 09:11, 'Marc Meltzer' via enter...@mozilla.org wrote:

> As someone who has way too much experience with this, I can answer.
>
> You can't use the customization wizard if you are installing Acrobat
> directly from the Cloud. You would have to go into your enterprise's
> Admin Console and create the Acrobat package to download. Once
> downloaded, you can then customize the installer with the wizard.
> Since the default is to use Named User licenses, this works.

What I'm doing is going to the admin console Website and creating an
"Acrobat package" (which includes Creative Cloud, because there's no way
to omit that) with named-user licensing selected, then using the result
to effectively install both.

I didn't think there was a way to open and modify the package created in
the admin console in order to customize Acrobat; I figured that doing so
would mess up the created install in some way.

Also, I could be misremembering, but I think the last time I looked I
couldn't find an Acrobat Customization Wizard for DC which didn't seem
to be deprecated in favor of the Creative Cloud install approach; I
think I understood the case to be that all customization was now
supposed to be done via that admin console. If I'm misremembering about
that, then I may just need to dig up where to find the right
Customization Wizard.


That said: we also deploy Acrobat Professional DC via shared-device
licensing to some computers (albeit far fewer), so if the extension is
installed and behaves the same way when using shared-device licensing,
we're going to see the same issue there. If the customization-wizard
approach only works with named-user licensing, that's going to leave us
still having the problem. So some kind of method to directly manage this
by policy, rather than having to define it at install time, would still
be useful.

[The Wanderer]

On 2021-12-20 at 11:55, The Wanderer wrote:

> On 2021-12-20 at 11:23, Mike Kaply wrote:
>
>> On Mon, Dec 20, 2021 at 10:05 AM The Wanderer
>> <wand...@fastmail.fm> wrote:

>>> I really do see the loss of ability to manage extension
>>> settings, which came with the move from having extensions store
>>> their settings as Firefox preferences to having them store their
>>> settings in a separate storage space, as a regression. I don't
>>> see any way to resolve that regression without providing the
>>> ability to manage the contents of that separate storage space,
>>> much as we could/can manage Firefox preferences.
>>
>> That's why enterprise management of extension settings was
>> introduced.
>
> To me, enterprise management of extension settings would include the
> ability to modify extension internal storage values like this,
> because that is where extensions store their settings.
>
> I looked through the policies.json documentation (version 3.4, IIRC)
> for exactly this, and did not find anything that looked like it would
> let me configure extension internal settings. If there's something
> I've missed, please do point me to it; I'd be glad to be corrected.

Anything on this?

If there really is a facility for enterprises to manage the settings of
extensions, I'd like to know about it. I haven't been able to find any
thus far; my searches have only led me to information about how to
control what extensions do and do not get installed, which is not at all
the same as managing the settings of those extensions.

If there isn't, then I'd like to know what facility the term "enterprise
management of extension settings" does refer to, so that if nothing else
I can be better informed when discussing the subject.

[Mike Kaply]

The specific policy is called 3rdparty, but it's up to the extension developer to provide documentation and templates.

https://github.com/mozilla/policy-templates#3rdparty

https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/

uBlock origin is an example of an extension that supports this (although these are Chrome examples)

https://deployhappiness.com/deploying-ublock-origin-for-chrome-and-configuring-a-whitelist/

Mike Kaply

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61CB05FB.9020704%40fastmail.fm.

[The Wanderer]

On 2021-12-28 at 12:10, Mike Kaply wrote:

> On Tue, Dec 28, 2021, 6:41 AM The Wanderer <wand...@fastmail.fm>
> wrote:

>> If there really is a facility for enterprises to manage the
>> settings of extensions, I'd like to know about it. I haven't been
>> able to find any thus far; my searches have only led me to
>> information about how to control what extensions do and do not get
>> installed, which is not at all the same as managing the settings of
>> those extensions.
>>
>> If there isn't, then I'd like to know what facility the term
>> "enterprise management of extension settings" does refer to, so
>> that if nothing else I can be better informed when discussing the
>> subject.
>
> The specific policy is called 3rdparty, but it's up to the extension
> developer to provide documentation and templates.
>
> https://github.com/mozilla/policy-templates#3rdparty
>
> https://extensionworkshop.com/documentation/enterprise/adding-policy-support-to-your-extension/

Thanks for the pointer. I think I'd seen that first item before, but had
skipped over it as being irrelevant, because it talks about this as
being something which extensions can add support for.

Reading through the second link and related things which I find based
thereon, I find that this looks promising at first glance, but on deeper
reading I see that it appears to require that the extension use a
separate API (browser.storage.managed.get(), instead of
browser.storage.local.get()) to read settings which are put in place
that way.

If that is correct, then it would only work for settings for which the
extension developer has written the extension to check for managed
versions of the setting. (In the case at hand, the extension shipped
with Acrobat Professional DC, that does not appear to have happened; it
reads the setting using browser.storage.local.get(), so presumably it
will not see the setting if I apply it this way. I'm not going to be in
a position to readily check until probably next week sometime.)

That is not sufficient to be a successor to the old
extension-settings-management capability. It needs to be possible to
manage extension settings without any cooperation from the extension
developer, as long as the developer has not put in place more
obfuscation of the settings than the prospective manage-er is willing to
put in the effort to deobfuscate.

Documentation and templates are nice, as a sign that the developer wants
to cooperate, and as a way of reducing the effort needed to figure out
what settings to apply to produce what effect - but if developer
cooperation is *necessary* in order for it to be possible to manage the
extension's settings, then that's a problem.

[The Wanderer]

On 2021-12-20 at 11:23, Mike Kaply wrote:

It's been more than two weeks (albeit over the holiday period); has
there been any response from your Adobe contacts about this, or any
development towards a way to get this working?

I'm now back in a position where I could test using the managed-storage
interface to apply the setting, but the extension code uses
browser.storage.local.get() rather than browser.storage.managed.get(),
so I don't think the odds of the setting actually being picked up if
applied that way are strong enough for the time and effort of the test
to really be worthwhile.

I reiterate: there really, really needs to be a way to apply and manage
extension settings even if the extension provider does not cooperate,
just as we could do pre-WebExtensions by adjusting the extension's pref
values.

[Mike Kaply]

I have been thinking a lot about this, and I have a couple ideas I'm going to try. I can't make any promises, but I definitely understand the issues and other folks have had similar complaints.

I'm going to investigate either preventing first run pages during install via policy (not sure how reliable that will be) or allowing policy to set preferences if they don't use managed storage.

I can't give a timeline, but hopefully something to report in the next couple months.

Mike

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61D49A7E.2020908%40fastmail.fm.

[The Wanderer]

On 2022-01-14 at 11:45, Mike Kaply wrote:

> I have been thinking a lot about this, and I have a couple ideas I'm
> going to try. I can't make any promises, but I definitely understand
> the issues and other folks have had similar complaints.
>
> I'm going to investigate either preventing first run pages during
> install via policy (not sure how reliable that will be) or allowing
> policy to set preferences if they don't use managed storage.
>
> I can't give a timeline, but hopefully something to report in the
> next couple months.

I'm glad to hear back, and I appreciate what you do on this! I will look
forward to hearing updates, whenever they may come.

(I infer, from the lack of mention otherwise, that either you have not
heard back on this from your Adobe contacts or they have responded in
the negative.)

[Mike Kaply]

FYI, I did finally get a response from Adobe. They are looking into it.

Preventing any first run pages isn't feasible because of the various timing and ways that happens.

I'm still looking at the managed storage stuff.

Mike

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61E1ADBE.1020803%40fastmail.fm.

[The Wanderer]

On 2022-03-01 at 15:25, Mike Kaply wrote:

> FYI, I did finally get a response from Adobe. They are looking into
> it.

That's better than I was expecting, though I still don't hold strong
hopes on that front.

> Preventing any first run pages isn't feasible because of the various
> timing and ways that happens.

Yeah, I didn't really expect that to go much of anywhere, though it
didn't hurt to give it a look.

> I'm still looking at the managed storage stuff.

I'm glad to hear it. I really hope that one does wind up going places,
because it'd enable/facilitate so many useful purposes beyond just
blocking first-run pages...

Thanks for the update, and please do keep us posted about any
developments. (If there wind up being bugs filed about anything related
to this, I'd be interested to know what they are so that I can follow
the discussion; as best I can tell, at this point finding discussion in
the depths of Bugzilla is basically a fool's errand for anyone not tied
in to the internal Mozilla development processes, and in at least some
cases - possibly even most cases - the important discussion may not even
happen *there* much less in any place more publicly visible than that.)

[Jason Jackson]

The "Acrobat Customization Wizard DC" is still supported and you can use it on Shared Device Licensing (SDL) packages as well. Adobe even updated the documentation since my last reply. Here's the bit about the Firefox extension:

https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/advancedconfig.html#pdf-maker-extensions

P.S. If you look inside a new Creative Cloud package with Acrobat made in 2022, you'll see it actually has the Acrobat 2015 installer inside. If you monitor the installation, the setup installs this first, then updates it three times to get it to the DC version. Similarly, this is why the Wizard hasn't been updated since 2015.

Jason Jackson
Systems & Network Administrator
North Vancouver School District

-----Original Message-----
From: enter...@mozilla.org <enter...@mozilla.org> On Behalf Of The Wanderer

Sent: December 23, 2021 6:19 AM
To: enter...@mozilla.org
Subject: Re: [EXTERNAL EMAIL] - Re: [Mozilla Enterprise] Prevent system-installed add-on from opening new tab on first launch of Firefox

On 2021-12-23 at 09:11, 'Marc Meltzer' via enter...@mozilla.org wrote:

> As someone who has way too much experience with this, I can answer.
>
> You can't use the customization wizard if you are installing Acrobat
> directly from the Cloud. You would have to go into your enterprise's
> Admin Console and create the Acrobat package to download. Once
> downloaded, you can then customize the installer with the wizard.
> Since the default is to use Named User licenses, this works.

What I'm doing is going to the admin console Website and creating an "Acrobat package" (which includes Creative Cloud, because there's no way to omit that) with named-user licensing selected, then using the result to effectively install both.

I didn't think there was a way to open and modify the package created in the admin console in order to customize Acrobat; I figured that doing so would mess up the created install in some way.

Also, I could be misremembering, but I think the last time I looked I couldn't find an Acrobat Customization Wizard for DC which didn't seem to be deprecated in favor of the Creative Cloud install approach; I think I understood the case to be that all customization was now supposed to be done via that admin console. If I'm misremembering about that, then I may just need to dig up where to find the right Customization Wizard.


That said: we also deploy Acrobat Professional DC via shared-device licensing to some computers (albeit far fewer), so if the extension is installed and behaves the same way when using shared-device licensing, we're going to see the same issue there. If the customization-wizard approach only works with named-user licensing, that's going to leave us still having the problem. So some kind of method to directly manage this by policy, rather than having to define it at install time, would still be useful.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/61C48564.8090305%40fastmail.fm.