On 8/20/19 1:31 PM, Mike Kaply wrote:
We have a new ExtensionSettings policy that will allow you to enable
extensions by ID.
Thanks for this change, but I think this will allow someone to create an
extension with using an internally developed id, ask Mozilla to sign it,
and then use it on managed machines?
I still think whitelisting signer hashes is a good idea.
Note: Just as a reference of other tools that do this, the defunct Java
Web Start technology has this to allow whitelisting applications
https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_rules.html#CIHEFCEC
this will be in the next ESR update and Firefox 69 (It was in 68 but had
some bugs so I didn't release it)
Mike
On Tue, Aug 20, 2019 at 12:24 PM Robert Marcano
<[email protected] <mailto:[email protected]>> wrote:
On 8/19/19 12:31 PM, Mike Kaply wrote:
> The Firefox ESR has always supported turning off extension
signing so
> you can install local extensions.
I wish it wasn't an on or off switch, but more a list of allowed
certificates (hashes?), and be able to disable Mozilla's certificates
That way you can allow your users to use approved internal extensions
without giving them the privilege to usa any Mozilla approved ones or
install random XPIs without signatures
>
> Mike
>
> On Sun, Aug 18, 2019 at 10:58 AM Paul Kosinski via Enterprise
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> As a long-time Firefox user, I went to ESR because I prefer
stability to
> new features, and I especially don't like gratuitous changes
to the User
> Interface. The move to Tabs on Top was ugly: I think Google
started it
> so that users would view the Web (and hence Google) as their
computing
> environment, rather than Windows et al. But at least Classic
Theme
> Restorer could fix that.
>
> The move to Quantum killed much of the ability to make
Firefox look the
> way the user wanted and was used to. This has meant that
users had to
> learn the new interface rather than doing useful work (sort
of like
> The Microsoft Office "Ribbon" debacle). And the modern fad of
replacing
> text-labeled icons with pure icons means that no one can know
for sure
> what they mean, no matter what language they speak. (Plus,
"hovering"
> over the icon to get the tool-tip wastes more time.) Not all
users have
> to make do with tiny smartphone screens which don't have the
space for
> labeled icons.
>
> The move to Quantum also required some really critical
add-ons, such as
> NoScript, to be totally reimplemented, and made many other
add-ons
> (such as Classic Theme Restore) apparently impossible. In the
case of
> NoScript, there may have been a period where the overall
security of
> using Firefox suffered in spite of the more secure internal
structure
> of Quantum.
>
> And speaking of security, although the idea of requiring
add-ons to be
> signed by Mozilla (only!) may be good for the consumer
versions of
> Firefox, it is totally inappropriate for the *Enterprise* version
> (ESR). It means that any organization that wants add-ons that
*need* to
> be kept private can't use Firefox at all. The notion that
they could
> use a local build or an unofficial build (daily etc.) could
mean that
> they are violating some other corporate or government regulation
> concerning what software they are allowed to use. And how
would one
> even *find* the daily etc. build that is essentially
identical to the
> release build?
>
> Since ESR is for enterprise use, surely it should be possible
to allow
> enterprise-private add-ons to be loaded in ESR if their
*hash* is signed
> by Mozilla. (Mozilla should not be in the business of trying
to protect
> enterprises from software they themselves write.) In other
words, an
> enterprise would just submit a hash of the add-on XPI to
Mozilla the
> way they now can submit the whole XPI. Then if so configured
(e.g., via
> about:config) the ESR version of Firefox would allow the
add-on to be
> loaded iff its hash passed the signature test. To add to "public
> safety", Firefox could display a caveat stating that the
add-on belongs
> to XYZ Corp. and is in no way certified by Mozilla. Plus, of
course,
> such hash-signed add-ons would never be hosted by Mozilla.
>
>
>
>
>
> On Sat, 17 Aug 2019 00:54:28 +0000
> Ramkrishna Reddy D S <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> > Hi Mike,
> >
> > Less major updates would be good as it's hard for us to
manage.
> >
> > Regards,
> > Ram
> >
> > Sent from Workspace ONE Boxer
> >
> > On 17-Aug-2019 12:16 AM, Mike Kaply <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
> > I know this is generally considered a support list, but I
have a
> > couple things I'd like to let you know about. Going
forward, if you'd
> > like to continue to receive these kind of updates, you can
follow the
> > instructions at the end of this email.
> >
> > Legacy Browser Support for Windows now
> >
>
available!<https://protect2.fireeye.com/url?k=0ab11a4d-5665120e-0ab15ad6-86a1150bc3ba-e41f2431dfb71a8b&q=1&u=https%3A%2F%2Fgithub.com%2Fmozilla%2Flegacy-browser-support%2Freleases%2Ftag%2Fv1.0>
> >
> > It is quite possible that you still require the use of
websites and
> > apps running ActiveX, Java, or Silverlight that need a
legacy browser
> > for it to work. You can now get Legacy Browser Support
which will
> > allow you to easily switch between Firefox and your legacy
browser of
> > choice. You can add websites to the policy and when your
users try to
> > access the site via the URL bar or a link, it will open in
the legacy
> > browser automatically. Legacy Browser Support requires a
native
> > component installed via MSI as well as an extension.
> >
> > Share your thoughts on ESR Release Cadence
> >
> > We would love your feedback in our current cadence of Firefox
> > Extended Support releases.
> >
> > Today, an ESR life cycle spans between 9 months to a year.
We would
> > like to understand if a shorter life cycle, with more
releases each
> > year, would help meet the needs of you and your organization.
> >
> > We believe faster cycles will allow more flexibility to
back port
> > features and functionality to the ESR and will reduce
occurrence of
> > web app compatibility issues that arise due to the ESR
being too
> > outdated. While the ESR helps lower QA overhead through
less frequent
> > updates, would a biannual release bring more benefits to
you? Please
> > chime in on this feedback
form<https://forms.gle/jdwWYKQ3inqP3jwL9>.
> >
> > Want to receive enterprise news?
> >
> > This is our second note to you in the past few weeks and
we would
> > like to share more news about our enterprise work as new
features and
> > offerings are developed. If my recent emails have been
helpful, I’d
> > love to have you complete this brief
> >
form<https://www.mozilla.org/en-US/firefox/enterprise/signup/> to
> > receive periodic news from our enterprise team.
> >
> > Thanks
> > [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
> > Mike Kaply
> > Technical Lead, Enterprise Firefox
> _______________________________________________
> Enterprise mailing list
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[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]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> with a subject of "unsubscribe"
>
>
> _______________________________________________
> Enterprise mailing list
> [email protected] <mailto:[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]
<mailto:[email protected]> with a subject of "unsubscribe"
>
_______________________________________________
Enterprise mailing list
[email protected] <mailto:[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]
<mailto:[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"
