Argument against Mozilla-only signing

[Paolo Inaudi]

I agree with most users on your blog saying that I feel having Mozilla control which extensions are allowed to run in Firefox is against FOSS principles, and FOSS principles are the main reason I choose Firefox as my main browser on all platforms. As you said, if the attacker has root privileges on the machine, then everything is broken anyway, so I don't see why there can't be a setting in a global configuration file where you can add something like "User X [on profile Y] is allowed to run {extension Z|all unsigned extension} {with|without} a big fat warning". And also allow a user to sideload his own certificate.
I don't want either of the two. I want both options. The former allows freedom in installing third party extensions not approved. The latter gives me freedom of installing my own extension, without approval of Mozilla.

You will reply you can submit {the same third party extension with modified id|your own extension} to AMO for approval for redistributing. This is not the same thing. My executable still has to get out of my private network. Might need to be checked from a Mozilla employee (is source code needed for manual review? if so, even worse). I can (and do) trust the Mozilla Foundation, but I may not want to trust every single employee in it.

To end my argument, as also someone else has pointed out, using development version/the unbranded version is not a valid alternative. Development version is unstable, and the unbranded version has the entire signing system, which I might want to partially use, completely disabled. Moreover, it won't be available in linux distributions repositories.

Of course malicious extensions will offer instructions on how to run them. But there is no point in trying to protect people who wants really badly to be compromised.

I hope those arguments will be taken into consideration.

Paolo

[Jorge Villalobos]

On 2/12/15 3:23 AM, Paolo Inaudi wrote:
> I agree with most users on your blog saying that I feel having Mozilla control which extensions are allowed to run in Firefox is against FOSS principles, and FOSS principles are the main reason I choose Firefox as my main browser on all platforms. As you said, if the attacker has root privileges on the machine, then everything is broken anyway, so I don't see why there can't be a setting in a global configuration file where you can add something like "User X [on profile Y] is allowed to run {extension Z|all unsigned extension} {with|without} a big fat warning". And also allow a user to sideload his own certificate.

Users can be compromised in fairly incredible ways. If you open the
Browser Console and open a Facebook page, there's a pretty notable
warning in the console telling users not to run any code there. That's
because malware developers manage to convince users to run arbitrary JS
code in the console. You're right that having the setting in the install
dir would protect users against the kind of malware we *can* protect
against, but that would still leave users as the weak point in the
system. Having said that, I'm not entirely opposed to this idea, and I
will bring it up next time we meet about it.

I don't think that loading your own certs is a good idea, though. That
opens Firefox to potential compromise by an arbitrary number of add-ons.

> I don't want either of the two. I want both options. The former allows freedom in installing third party extensions not approved. The latter gives me freedom of installing my own extension, without approval of Mozilla.
>
> You will reply you can submit {the same third party extension with modified id|your own extension} to AMO for approval for redistributing. This is not the same thing. My executable still has to get out of my private network. Might need to be checked from a Mozilla employee (is source code needed for manual review? if so, even worse). I can (and do) trust the Mozilla Foundation, but I may not want to trust every single employee in it.

We mentioned in the post that there will be a third way to sign add-ons
that aren't intended for the public. We will include details in a followup.

> To end my argument, as also someone else has pointed out, using development version/the unbranded version is not a valid alternative. Development version is unstable, and the unbranded version has the entire signing system, which I might want to partially use, completely disabled. Moreover, it won't be available in linux distributions repositories.

The unbranded and dev versions will have the signing enforcement off by
default, but they will have a setting to turn it on. This setting won't
exist on Beta and Release versions.

> Of course malicious extensions will offer instructions on how to run them. But there is no point in trying to protect people who wants really badly to be compromised.

There's a line after which we definitely have to say "sorry, you're on
your own". But we have a very large and diverse audience to cater to,
and we have to make compromises and push the line as far as we can to
protect the majority of our users. We have been failing at that for
years when it comes to malicious add-ons, and we're trying to rectify
it. I know this sucks for many add-on devs and many Mozilla and FOSS
supporters, but we believe this is a reasonable compromise that
maintains a healthy developer community and significantly raises the bar
for malware add-on developers.

>
> I hope those arguments will be taken into consideration.
>
> Paolo

Thanks,

Jorge

[Mike Connor]

On 12 February 2015 at 04:23, Paolo Inaudi <p91...@gmail.com> wrote:

> I agree with most users on your blog saying that I feel having Mozilla
> control which extensions are allowed to run in Firefox is against FOSS
> principles, and FOSS principles are the main reason I choose Firefox as my
> main browser on all platforms.

It's open source software, you can build your own version without these
restrictions, or use one of the unbranded builds. It'll be a build flag.
I don't believe FOSS principles should be used to justify inaction on
security and abuse issues affecting a significant set of users. For users
not sophisticated enough to know the difference, we're going to do the
right thing for them, but for them to choose to allow unknown add-ons will
require installing a different version, not a different pref.

> As you said, if the attacker has root privileges on the machine, then
> everything is broken anyway,

This doesn't stop truly malicious actors. Its open source software, you
could conceivably replace the entire install with something hacked if you
have admin privs. What this does away with is the grey area where actors
claim to be acting with "user consent" to bypass existing protections and
suppress warnings. If you cross that line to bypass security restrictions
you're obviously malware, and that's where we can work with security
software and OS vendors to block those installers. There's also legal
mechanisms to deal with malicious modification of software.

We're not naive enough to assume this is a magic barrier against
attackers. It's a mechanism that will much more clearly delineate good and
bad actors, and force the good ones to play nice. If we cut abuse in half
we're still miles ahead of where we are.

so I don't see why there can't be a setting in a global configuration file
> where you can add something like "User X [on profile Y] is allowed to run
> {extension Z|all unsigned extension} {with|without} a big fat warning". And
> also allow a user to sideload his own certificate.
>

Anything a user can do, an installer can do, so this is basically "I don't
see why there isn't a simple way to bypass the security restrictions."
Hopefully the above helps clarify what we're hoping to achieve here and
why this would basically preserve the status quo.

> To end my argument, as also someone else has pointed out, using
> development version/the unbranded version is not a valid alternative.
> Development version is unstable, and the unbranded version has the entire
> signing system, which I might want to partially use, completely disabled.
> Moreover, it won't be available in linux distributions repositories.
>

It's not disabled, there's just a pref that can override it in those
versions. The only difference will be that the code that looks for the
pref will be behind an ifdef and thus not included in branded builds.

-- Mike

[Paolo Inaudi]

Thanks for addressing most of my concerns. Some of them were also due to
the fact that I limited myself to reading the blog post.

After reading something on the mailing list I saw your approach to
enterprise extensions.
If I understand correctly, an individual or an organization will be able to
get a key after paying a fee. At that point, they can sign their own
extensions and distribute them out of mozilla addons website, or not
distribute them at all and keep them inside the organization.

I still see the user being able to install his own certificate as a better
option. Seems wrong to me to have to request permission to deploy my own
software in my own organization/computer to a third party.

I think I just came up with a viable idea to archieve both that level of
freedom and address your concerns. You may create an external program, not
bundled with firefox (at least not in the main download page), available to
developers, that does the following.
1) allows the user to specify his own certificate, or creates one for him.
2) sideloads the certificate in firefox, signing with that certificate some
system specific information which is likely to be different in different
systems (better if that information is obtainable only with administrative
privileges) and saving that signed information in a file in some well known
directory.
3) allows the user to sign his extensions with that certificate

what you are archiving is:
*no separate builds of firefox
*no work on the mozilla side to approve non-public extensions
*no need to release paid signing keys
*no risk that said keys will be in future used for malicious purpose, and
you discover that only after weeks when it's too late to revoke the key
*no easy-to-circumvent sideloading: a malicious addon provider cannot
publish his certificate and say copy this file to this location then
install my extension, because the lack of signed system information file
would not allow firefox to load the extension;they have to convince the
user to download, install and run an external software with administrative
privileges, which would break also the current model

The software to sideload certificates should be command line and easily
scriptable, to discourage casual users to run it and to allow easier
enterprise installs: in an enterprise environment, a single certificate is
generated then sideloaded through said software on every machine, so each
addon is only signed once and installed everywhere.

What do you think of this?
Paolo

[luck...@musites.com]

On Thursday, 12 February 2015 22:06:02 UTC, Mike Connor wrote:
> What this does away with is the grey area where actors
> claim to be acting with "user consent" to bypass existing protections and
> suppress warnings. If you cross that line to bypass security restrictions
> you're obviously malware, and that's where we can work with security
> software and OS vendors to block those installers.

I think this is a key point that many commentators on the add-on blog post have missed. Essentially, once an installer starts messing with binary files it's much more likely that a 3rd party anti-malware solution can step in to help protect the user.

The current status-quo gives malware distributors an easy installation pathway which is difficult/impossible for 3rd party software to tell apart from a valid (user-authorised) configuration modification.

Thanks,
Chris

[Philip Chee]

On 13/02/2015 05:43, Jorge Villalobos wrote:

>> To end my argument, as also someone else has pointed out, using
>> development version/the unbranded version is not a valid
>> alternative. Development version is unstable, and the unbranded
>> version has the entire signing system, which I might want to
>> partially use, completely disabled. Moreover, it won't be available
>> in linux distributions repositories.

Ah. A question just occurred to me. Are Linux distros planning to
package Firefox with/without mandatory addon signing?

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Mike Connor]

At present the expectation for Firefox-branded builds, as with all security
features, will be that they take no steps to disable or otherwise interfere
with the feature.

On Feb 13, 2015 1:20 AM, "Philip Chee" <phili...@gmail.com> wrote:

> On 13/02/2015 05:43, Jorge Villalobos wrote:
>

> >> To end my argument, as also someone else has pointed out, using
> >> development version/the unbranded version is not a valid
> >> alternative. Development version is unstable, and the unbranded
> >> version has the entire signing system, which I might want to
> >> partially use, completely disabled. Moreover, it won't be available
> >> in linux distributions repositories.
>

> Ah. A question just occurred to me. Are Linux distros planning to
> package Firefox with/without mandatory addon signing?
>
> Phil
>
> --
> Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.

> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>

[JS]

On 2/13/2015 2:17 AM, Mike Connor wrote:
> At present the expectation for Firefox-branded builds, as with all security
> features, will be that they take no steps to disable or otherwise interfere
> with the feature.

Well, the ability to install and run a private extension is
a security feature. For some users, a very valuable security
feature and one which will outweigh the very low risk of
browser tampering malware getting onto boxes that should be
(and usually are) well secured against malware to begin with.

The future Release breaks this security feature, and it uses
the Firefox name. Other builds with the Firefox name will be
capable of not enforcing the new signing feature. If you
really want to be a stickler on this point, shouldn't you be
removing the Firefox name from them all?

Seriously, why don't you just give this build a proper name.
Firefox Private Edition, Firefox Pro, Firefox Enterprise
Edition, Firefox Flex, whatever. As long as you publish
information about how it differs from the vanilla build, it
will be fine.

Don't treat it like an unwanted step child. Unless that is
what it is and you intend to kick it out the door as soon
as you've pulled off the switcheroo to the locked down
version.

[JS]

On 2/12/2015 4:43 PM, Jorge Villalobos wrote:
> The unbranded and dev versions will have the signing enforcement off by
> default, but they will have a setting to turn it on.

The previous poster mentioned a desire to be able to "partially
use" the signing system. Which suggests an ability to control
it on an extension by extension basis, or at least create
exceptions against the current setting. Could you confirm
for us whether that level of control is planned?

[Mike Connor]

It's not planned, mostly because it'd be a target for abuse (how would you
safely store metadata saying an add-on doesn't need to be signed without
third parties using that to trivially bypass things) and we generally don't
build complex features that are not going to be useful for Beta/Release
users.

On 13 February 2015 at 12:17, JS <js_losxc...@comcast.net> wrote:

> On 2/12/2015 4:43 PM, Jorge Villalobos wrote:
>

>> The unbranded and dev versions will have the signing enforcement off by
>> default, but they will have a setting to turn it on.
>>
>

> The previous poster mentioned a desire to be able to "partially
> use" the signing system. Which suggests an ability to control
> it on an extension by extension basis, or at least create
> exceptions against the current setting. Could you confirm
> for us whether that level of control is planned?
>
>
>

[Paolo Inaudi]

Please check my second email on this very thread. Seems noone actually read it, and contains a proposal for certificate sideloading which I believe should at least be discussed. I can see it on the google groups page, so it was sent.

[Mike Connor]

I'm not going to dive into the depth of this, since there's a high-level
flaw: any installer running with system level privs would be able to:

* generate a cert
* install it into the profile
* sign their add-on
* install their add-on.

That's a pretty trivial bypass of the signing mechanism.

>> have admin privs. What this does away with is the grey area where actors

>> claim to be acting with "user consent" to bypass existing protections and
>> suppress warnings. If you cross that line to bypass security restrictions
>> you're obviously malware, and that's where we can work with security

>> software and OS vendors to block those installers. There's also legal
>> mechanisms to deal with malicious modification of software.
>>
>> We're not naive enough to assume this is a magic barrier against
>> attackers. It's a mechanism that will much more clearly delineate good and
>> bad actors, and force the good ones to play nice. If we cut abuse in half
>> we're still miles ahead of where we are.
>>
>> so I don't see why there can't be a setting in a global configuration
>>> file where you can add something like "User X [on profile Y] is allowed to
>>> run {extension Z|all unsigned extension} {with|without} a big fat warning".
>>> And also allow a user to sideload his own certificate.
>>>
>>
>> Anything a user can do, an installer can do, so this is basically "I
>> don't see why there isn't a simple way to bypass the security
>> restrictions." Hopefully the above helps clarify what we're hoping to
>> achieve here and why this would basically preserve the status quo.
>>
>>

>>> To end my argument, as also someone else has pointed out, using
>>> development version/the unbranded version is not a valid alternative.
>>> Development version is unstable, and the unbranded version has the entire
>>> signing system, which I might want to partially use, completely disabled.
>>> Moreover, it won't be available in linux distributions repositories.
>>>
>>

[Paolo Inaudi]

With current approach, the installer replaces the firefox executable,
then install the add-on, which is even more trivial. Third-party
anti-malware applications can monitor the certificate directory the same
way they monitor the executable, leading to the same level of security.
Paolo

[Mike Connor]

So, the delta here is that "using an approved method to allow a user to
install an unsigned add-on" is an avenue that grey-area installers would
claim to be simple automation of something a user "agreed" to do anyway.
"Install this add-on" by utilizing an alternate signing mechanism is "user
choice" by that argument. Even if it's through misleading or deceptive
tactics.

Replacing the executable is, in contrast, inarguably a malware tactic (and
explicitly illegal in some places, AIUI).

On 13 February 2015 at 13:54, Paolo Inaudi <p91...@gmail.com> wrote:

> With current approach, the installer replaces the firefox executable, then
> install the add-on, which is even more trivial. Third-party anti-malware
> applications can monitor the certificate directory the same way they
> monitor the executable, leading to the same level of security.
> Paolo
>
> Il 13/02/2015 19:36, Mike Connor ha scritto:
>

[Ben Bucksch]

Mike Connor wrote, On 13.02.2015 19:36:
> I'm not going to dive into the depth of this, since there's a high-level
> flaw: any installer running with system level privs would be able to:

.... bypass the system you yourself are proposing
.... using any of the means that I and Kairo already described.

[Paolo Inaudi]

No, I feel that whatever grey-area installers claim, an anti-malware can
always detect that an installer is running and such installer is messing
with firefox certificate directory, and that is malware tactic, full
stop. You feel anti-malware developers won't implement this explicitly
for firefox? well then, instead of a directory, make it an archive and
give it a .dll extension. Anti-malware will check that for modifications.

A legitimate user might need to disable their anti-malware while
sideloading their certificate if this gets implemented. Which is
obviously user choice.

Note that this addresses also the problem many (expecially AMO)
extension developers are pointing out: they are used to release bugfix
versions to bug reporters. The developer could then send his own
certificate along with the extension. The user sideloads it, then
installs the patched extension, then for subsequent testing neither the
developer nor the user won't have to do anything more that what they are
doing now.

Of course the developer has gained the ability to make their testers
install compromised versions of their addons, but this is a non issue
(bug reporters willing to test are a large minority, thus a non-valuable
target, and they trust the developer, who has anyway proved to be 'good'
developing a mozilla-signed version in the first place)

Paolo

Il 13/02/2015 20:01, Mike Connor ha scritto:
> So, the delta here is that "using an approved method to allow a user
> to install an unsigned add-on" is an avenue that grey-area installers
> would claim to be simple automation of something a user "agreed" to do
> anyway. "Install this add-on" by utilizing an alternate signing
> mechanism is "user choice" by that argument. Even if it's through
> misleading or deceptive tactics.
>
> Replacing the executable is, in contrast, inarguably a malware tactic
> (and explicitly illegal in some places, AIUI).
>
> On 13 February 2015 at 13:54, Paolo Inaudi <p91...@gmail.com

> <mailto:p91...@gmail.com>> wrote:
>
> With current approach, the installer replaces the firefox
> executable, then install the add-on, which is even more trivial.
> Third-party anti-malware applications can monitor the certificate
> directory the same way they monitor the executable, leading to the
> same level of security.
> Paolo
>
> Il 13/02/2015 19:36, Mike Connor ha scritto:
>

> I'm not going to dive into the depth of this, since there's a
> high-level
> flaw: any installer running with system level privs would be
> able to:
>
> * generate a cert
> * install it into the profile
> * sign their add-on
> * install their add-on.
>
> That's a pretty trivial bypass of the signing mechanism.
>
> On 12 February 2015 at 18:10, Paolo Inaudi <p91...@gmail.com

> <mailto:mco...@mozilla.com>> ha scritto:

>
>
> On 12 February 2015 at 04:23, Paolo Inaudi

> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org

> <mailto:addons-user...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/addons-user-experience
>
>

[Ben Bucksch]

Mike Connor wrote, On 13.02.2015 20:01:
> Replacing the executable is, in contrast, inarguably a malware tactic (and
> explicitly illegal in some places, AIUI).

You don't even need to replace the Firefox executable (even though
that's an obvious path), just the extensions store or database. However
you store local data, an native EXE can mess with it.

[Mike Connor]

If the only change was at install time, yes. There will be post-install
checks to protect against other forms of tampering.

On 13 February 2015 at 14:34, Ben Bucksch <ben.buck...@beonex.com>
wrote:

> Mike Connor wrote, On 13.02.2015 20:01:

> > Replacing the executable is, in contrast, inarguably a malware tactic
> (and
> > explicitly illegal in some places, AIUI).
>

> You don't even need to replace the Firefox executable (even though
> that's an obvious path), just the extensions store or database. However
> you store local data, an native EXE can mess with it.

[JS]

On 2/13/2015 12:35 PM, Mike Connor wrote:
> It's not planned, mostly because it'd be a target for abuse (how would you
> safely store metadata saying an add-on doesn't need to be signed without
> third parties using that to trivially bypass things)

Well, in any build that provides some level of control over the
signing checks, there will be some type of config pref or data
that can be targeted. I don't think you are eliminating the
potential for abuse by keeping it to a simple on/off.

More importantly, by explicitly installing a special build
with configurable signing checks, the user is communicating
that they consider the risks acceptable. Any doubts about
that can be handled through notice and consent mechanisms.
Who are we to argue with their decision? We know nothing
about their level of knowledge and diligence, their platform
security and related procedures, what if anything they are
putting at risk, and so forth.

> and we generally don't
> build complex features that are not going to be useful for
> Beta/Release users.

If complexity were the concern, you would keep it simple. Do
you think it would be difficult to check for a preference
specifying an extension ID to whitelist before deciding
whether to execute the signature check on an extension?
Switching such code on only in the unbranded builds?

[Mike Connor]

The question is whether building/testing/supporting the feature is worth
the effort. At this point there's no evidence that it's worth doing ahead
of other work with greater impact. At best it'd be a fraction of users who
flip the pref, who will be a fraction of the users on those builds, who
will be a tiny fraction of our overall user base. There are much more
impactful changes we could make instead.

-- Mike

On 13 February 2015 at 15:17, JS <js_losxc...@comcast.net> wrote:

> On 2/13/2015 12:35 PM, Mike Connor wrote:
>

>> It's not planned, mostly because it'd be a target for abuse (how would you
>> safely store metadata saying an add-on doesn't need to be signed without
>> third parties using that to trivially bypass things)
>>
>

> Well, in any build that provides some level of control over the
> signing checks, there will be some type of config pref or data
> that can be targeted. I don't think you are eliminating the
> potential for abuse by keeping it to a simple on/off.
>
> More importantly, by explicitly installing a special build
> with configurable signing checks, the user is communicating
> that they consider the risks acceptable. Any doubts about
> that can be handled through notice and consent mechanisms.
> Who are we to argue with their decision? We know nothing
> about their level of knowledge and diligence, their platform
> security and related procedures, what if anything they are
> putting at risk, and so forth.
>

> > and we generally don't
> > build complex features that are not going to be useful for
> > Beta/Release users.
>

> If complexity were the concern, you would keep it simple. Do
> you think it would be difficult to check for a preference
> specifying an extension ID to whitelist before deciding
> whether to execute the signature check on an extension?
> Switching such code on only in the unbranded builds?
>
>

[Paolo Inaudi]

The question is why an extension should be either installable in all
firefox all over the world, because signed by mozilla, or not installable
at all. There must be a intermediate level. There must be a way to load
your own certificate. Mozilla handling everything is bad.

Let's suppose an organization gets a paid key and deploys extensions inside
itself.
An unhappy employee of said organization who has access to the key releases
a malware addon signed with the organization key.
Said malware will be installable on every firefox all over the world, until
you revoke the certificate. When you do that, ALL internal extensions of
the company will stop working, and at the very least it will take several
days for them to obtain a new key and re-sign and re-install all their
extensions.
The second after that, they'd rather develop their own browser instead of
using firefox again.

With the organization deploying his own certificate that would never happen.

You cannot have that kind of control. You are no microsoft, no apple, no
google. And still, of the three most controlling companies of the world
only apple is using a model which is as strict as yours.

Extension signing is good. Allows additional security. Fine. Sign
extensions on AMO and make difficult to install extensions outside it.
Allow trusting specific certificates and single extensions.

Also signing addons out of AMO is quite bad... how can you be sure that
your automatic test can't be circumvented? They will be, and then Mozilla
will be signing malware. Certifying it. Saying their users it has been
checked as not malware.
And you are doing that because you don't want to provide your users with a
way to specify they trust an entity which is not Mozilla??

Bundling trusted certificates in a file, possibly with a dll extension on
windows, will get the level of security you claim you want to reach (making
clear to an anti-malware application that an installer modifying that is
bad), without many of the restrictions you are putting on your users.

Additionaly, I still would love an on-off switch of some kind on the whole
feature, but for that development versions would be enough to make me happy.

Reading comments on the blog post, and the several other threads in this
mailing list, you will see many other use cases where this system sucks.
There is only one user that benefits, the complete dumbass. They might be
the majority of people, but to provide a bit of a walled garden for them
means a major PITA for developers and enterprise users. Moreover, they are
about to quit using PCs altogether, so why are you bothering so much? on
smartphones and tablets applications are sandboxed, there is no
sideloading, end of the story!Perfectly secure, absolutely non free...

I really want you badly to reconsider this. Sorry for continuously ranting.

Paolo

[JS]

On 2/13/2015 3:22 PM, Mike Connor wrote:
> The question is whether building/testing/supporting the feature is worth
> the effort. At this point there's no evidence that it's worth doing ahead
> of other work with greater impact. At best it'd be a fraction of users who
> flip the pref, who will be a fraction of the users on those builds, who
> will be a tiny fraction of our overall user base. There are much more
> impactful changes we could make instead.

That is an interesting way of talking yourself out of a potentially
trivial change. In the way you will code a new feature that you've
already deemed impactful enough to implement. Which will increase
the cases where extension signatures are checked. Which we should
assume will save some butts.

I would encourage all to reconsider the plan. Particularly for
the nonbranded build. It surely will be used for purposes other
than isolated testing.

[Paolo Inaudi]

I disagree: the most important plan to be reconsidered is the one on the branded build. It's the bad plan there that is going to trigger usage of nonbranded builds for everyday use instead of isolated testing.

If there will be a proper way of loading a non mozilla-signed extension on branded Firefox, then nobody will use unbranded versions other than for isolated testing.

[Paolo Inaudi]

Il giorno venerdì 13 febbraio 2015 20:02:04 UTC+1, Mike Connor ha scritto:
> So, the delta here is that "using an approved method to allow a user to
> install an unsigned add-on" is an avenue that grey-area installers would
> claim to be simple automation of something a user "agreed" to do anyway.
> "Install this add-on" by utilizing an alternate signing mechanism is "user
> choice" by that argument. Even if it's through misleading or deceptive
> tactics.
>
> Replacing the executable is, in contrast, inarguably a malware tactic (and
> explicitly illegal in some places, AIUI).
>

Replacing any file with .dll or .exe extension, not just the main executable (on Windows, which is obviously the platform you are targetting with this feature; on other platforms could be any file with executable permissions) is inarguably a malware tactic; so my idea of packing allowed certificates in an archive with one of those extension should make both of us happy (and countless other people as well).

[JS]

On 2/14/2015 10:52 AM, Paolo Inaudi wrote:
> I disagree: the most important plan to be reconsidered
> is the one on the branded build. It's the bad plan there
> that is going to trigger usage of nonbranded builds for
> everyday use instead of isolated testing.
>
> If there will be a proper way of loading a non
> mozilla-signed extension on branded Firefox, then nobody
> will use unbranded versions other than for isolated
> testing.

Well, I'd like to completely eliminate Mozilla from the
private extension equation. No certs or developer
licenses or agreements or accounts from Mozilla. No
exposing private extension source code to Mozilla. No
info about private extension installation or usage sent
to Mozilla. No way for Mozilla to kill private extensions.
You name it. All for legitimate security reasons, and
the same reasons would apply to every other browser or
platform vendor, mind you.

If a proposal is consistent with that, I'm open to it.
If it can be implemented in the branded build, great.
In which case, I think the unbranded build simply goes
away. What would you need it for?

[Paolo Inaudi]

Il giorno sabato 14 febbraio 2015 18:54:15 UTC+1, JS ha scritto:
>
>
> Well, I'd like to completely eliminate Mozilla from the
> private extension equation. No certs or developer
> licenses or agreements or accounts from Mozilla. No
> exposing private extension source code to Mozilla. No
> info about private extension installation or usage sent
> to Mozilla. No way for Mozilla to kill private extensions.
> You name it. All for legitimate security reasons, and
> the same reasons would apply to every other browser or
> platform vendor, mind you.
>
> If a proposal is consistent with that, I'm open to it.
> If it can be implemented in the branded build, great.
> In which case, I think the unbranded build simply goes
> away. What would you need it for?

I second every word of that.

[Botond Ballo]

On Sun, Feb 15, 2015 at 6:30 AM, Paolo Inaudi <p91...@gmail.com> wrote:
> Il giorno sabato 14 febbraio 2015 18:54:15 UTC+1, JS ha scritto:
>>
>>

>> Well, I'd like to completely eliminate Mozilla from the
>> private extension equation. No certs or developer
>> licenses or agreements or accounts from Mozilla. No
>> exposing private extension source code to Mozilla. No
>> info about private extension installation or usage sent
>> to Mozilla. No way for Mozilla to kill private extensions.
>> You name it. All for legitimate security reasons, and
>> the same reasons would apply to every other browser or
>> platform vendor, mind you.
>>
>> If a proposal is consistent with that, I'm open to it.
>> If it can be implemented in the branded build, great.
>> In which case, I think the unbranded build simply goes
>> away. What would you need it for?
>

> I second every word of that.

As do I!

Regards,
Botond

[Mike Connor]

So you want to create a class of add-ons that Mozilla can't know about or
protect users from in any fashion? And you don't expect that mechanism to
be immediately abused?

On 14 February 2015 at 12:54, JS <js_losxc...@comcast.net> wrote:

> On 2/14/2015 10:52 AM, Paolo Inaudi wrote:
>

>> I disagree: the most important plan to be reconsidered
>>
> > is the one on the branded build. It's the bad plan there
> > that is going to trigger usage of nonbranded builds for
> > everyday use instead of isolated testing.
>
>>
>> If there will be a proper way of loading a non
>>
> > mozilla-signed extension on branded Firefox, then nobody
> > will use unbranded versions other than for isolated
> > testing.
>

> Well, I'd like to completely eliminate Mozilla from the
> private extension equation. No certs or developer
> licenses or agreements or accounts from Mozilla. No
> exposing private extension source code to Mozilla. No
> info about private extension installation or usage sent
> to Mozilla. No way for Mozilla to kill private extensions.
> You name it. All for legitimate security reasons, and
> the same reasons would apply to every other browser or
> platform vendor, mind you.
>
> If a proposal is consistent with that, I'm open to it.
> If it can be implemented in the branded build, great.
> In which case, I think the unbranded build simply goes
> away. What would you need it for?
>

[Botond Ballo]

On Tue, Feb 17, 2015 at 7:27 PM, Mike Connor <mco...@mozilla.com> wrote:
> So you want to create a class of add-ons that Mozilla can't know about or
> protect users from in any fashion? And you don't expect that mechanism to
> be immediately abused?

We're not *creating* such a class of add-ons - they are the status
quo. You can think of this class of add-ons as the equivalent of "all
the Windows software that Microsoft hasn't signed/certified". Do you
think there would not be a backlash against Microsoft if they tried to
take away users' rights to run such software?

It is the introduction of a requirement of vetting by a third party,
that introduces avenues for abuse, not preserving users' rights to run
the software they want.

Regards,
Botond

[Mike Connor]

The status quo sucks for our users. It's great from a "freedom" sense, but
only if you're content to blame the victim, and let them give up on Firefox
because we can't track or effectively block add-ons that ruin their
experience.

On the rights argument, nothing is stopping those users from using an
unbranded version and turning this feature off.

-- Mike

[Mike Connor]

On 13 February 2015 at 18:08, Paolo Inaudi <p91...@gmail.com> wrote:
>
> There is only one user that benefits, the complete dumbass. They might be
> the majority of people, but to provide a bit of a walled garden for them
> means a major PITA for developers and enterprise users. Moreover, they are
> about to quit using PCs altogether, so why are you bothering so much? on
> smartphones and tablets applications are sandboxed, there is no
> sideloading, end of the story!Perfectly secure, absolutely non free...
>

Ah, now we reach the crux of the problem. Mozilla is not about building
for developers and enterprise users, we're about building for as many users
as possible. Abandoning less sophisticated users to abusive tactics means
we're going to lose those users. Most of them will switch to a browser
which doesn't get bogged down by abusive add-ons. That makes Mozilla weaker
because we have less leverage in standards bodies, in public policy
circles, and in public perception.

In the big picture, failing to act on this problem in an effective way is a
threat to Mozilla's ability to fulfill our mission. We've always been
pragmatic when we have needed to be, and this is one of those times where
we have to act in what we believe to be the best interests of the mission.
It's not going to make everyone happy, but it's our belief that it will do
far more good than harm.

-- Mike

[Botond Ballo]

On Tue, Feb 17, 2015 at 7:57 PM, Mike Connor <mco...@mozilla.com> wrote:
> On the rights argument, nothing is stopping those users from using an
> unbranded version and turning this feature off.

Except for awareness and convenience.

If users aren't aware of the unbranded version, then their lack of
awareness is effectively stopping them from using it. This is what I
meant by exposing our users to the possibility of "effective
censorship" in my thread on that topic - a hypothetical abuse of this
centralized signing mechanism to censor an add-on wouldn't
*completely* censor it, as users could still technically use the
unbranded version, but it would *effectively* censor it, because the
expectation is that most users don't know about the unbranded version.

On the convenience side, let's consider an analogy. End-to-end
encryption for email is possible (such as via PGP), but it's
notoriously inconvenient to use. Imagine users complaining to Google
that Google doesn't care about their privacy because Gmail doesn't
have end-to-end encryption built in. Suppose Google responds that
"nothing is stopping users from using PGP encryption manually". Would
you buy that as a convincing argument that Google does in fact care
about their users' privacy?

Regards,
Botond

[Thala Mew]

> Ah, now we reach the crux of the problem. Mozilla is not about building
> for developers and enterprise users, we're about building for as many users
> as possible.

Here's where you are absolutely incorrect. Fx for starters has been about inclusiveness not discriminating against one type or another. You sling the term Mozilla around too much as being the architect when it is actually a small group that is imposing this restriction.

> Abandoning less sophisticated users to abusive tactics means
> we're going to lose those users. Most of them will switch to a browser
> which doesn't get bogged down by abusive add-ons. That makes Mozilla weaker
> because we have less leverage in standards bodies, in public policy
> circles, and in public perception.

This is sensationalism and a fear tactic used by Google and some others quite often. Rather than have free access to open-source Fx is attempting to close-source with permission from a clearly biased support crew. This is a violation of several licensing terms established well before Fx even existed and the Mozilla Foundation.

If Fx wants to cripple development they will pay the price with less users as a whole. I've already converted several hundred machines in the last few days and Fx will continue to lose support including monetary contributions via donations.

[Tyler Downer]

>If users aren't aware of the unbranded version, then their lack of
>awareness is effectively stopping them from using it.

I have a feeling, strongly backed by evidence, that this change will not be
noticed by users, except for the fact that they won't be having to deal
with malware (which they often feel is something built into Firefox by
default, and don't blame it on third-parties). The actual chances that a
user will run into a need to use an unsigned add-on are slim to none.

> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>

--
Tyler Downer
Project Manager, User Advocacy

[Botond Ballo]

On Tue, Feb 17, 2015 at 8:06 PM, Mike Connor <mco...@mozilla.com> wrote:
> Ah, now we reach the crux of the problem. Mozilla is not about building
> for developers and enterprise users, we're about building for as many users

> as possible. Abandoning less sophisticated users to abusive tactics means

> we're going to lose those users. Most of them will switch to a browser
> which doesn't get bogged down by abusive add-ons. That makes Mozilla weaker
> because we have less leverage in standards bodies, in public policy
> circles, and in public perception.

I absolutely agree that something needs to be done to protect the average user.

However, I think we should also keep in mind that power users and
developers are *also* an important segment of our user base - they are
advocates of the brand and product, and, in the case of add-on
developers, they contribute significantly to keeping Firefox
competitive with other browsers (since the availability of add-ons to
do certain things plays a role in browser choice).

I think we should be trying harder to avoid alientating this segment -
and the recent threads on this list indicate to me that the current
direction risks alienating them significantly.

I've seen several reasonable technical proposals put forth on this
list in the past few days, that would significantly reduce the
inconvenience to the power user / add-on developer segment, while
maintaining protections for the average user. I'm seeing them all shot
down on the basis of a seemingly-arbitrary distinction between "things
a determined malware author can 'easily' circumvent" (for any opt-out
mechanism that's a sliver more convenient that the one being proposed,
unbranded builds) and "things we can't protect against anyways" (which
comes up any time someone brings up the possibility of such malware
authors getting the user to use an unbranded build).

I'm not convinced that there is a compelling technical reason why the
line must be drawn precisely where we're proposing to draw it, and
given that, I think we should heed the feedback from the community
that we are drawing it in the wrong place.

Regards,
Botond

[Botond Ballo]

On Tue, Feb 17, 2015 at 8:46 PM, Tyler Downer <tdo...@mozilla.com> wrote:
>>If users aren't aware of the unbranded version, then their lack of
>>awareness is effectively stopping them from using it.
>
> I have a feeling, strongly backed by evidence, that this change will not be
> noticed by users, except for the fact that they won't be having to deal with
> malware (which they often feel is something built into Firefox by default,
> and don't blame it on third-parties). The actual chances that a user will
> run into a need to use an unsigned add-on are slim to none.

Could you point me to this evidence? (To be clear, I'm not doubting
you. I'm genuinely curious.)

Thanks,
Botond

[Tyler Downer]

I don't have any off hand, but the majority of add-ons that users have
installed are already on AMO, or are popular third-party add-ons (Like
Norton Toolbar). These add-ons won't have a problem with Signing. The ones
that will have a problem are the ones that are malicious, that randomly
generate their ID's and are impossible for us to block. These are the
add-ons that won't sign, and that users won't miss once they are gone.
These add-ons number in the millions and are the main source of pain for
our users.

[Thala Mew]

> The actual chances that a
> user will run into a need to use an unsigned add-on are slim to none.

In my nets we use several modified add-ons because the AMO group blatantly ignored multiple reports of spyware added to veteran projects and basically did nothing about it. So this isn't valid in our circles.

This is a bad move with Fx and is above and beyond the realm of any sane project. Without an opt-out/opt-in this will absolutely inhibit contributions thus will lead to the downfall of Fx. I make no assumptions on my users other than possible inexperience which is where I prefer to teach them instead of treating them like second class citizens like this forced signing implies heavily.

Forcing devs to jump through additional hoops is a poor business model. I'll say it again the AMO group is biased. I would prefer to never publish on AMO not to mention AMO will be required to sign non-disclosure agreements for some projects that our entities develop.

When it comes right down to it rebranding will probably be an option but the other parent of Fx has already stated that they will currently not support this foolish procedure.

[Botond Ballo]

On Tue, Feb 17, 2015 at 9:16 PM, Tyler Downer <tdo...@mozilla.com> wrote:
> I don't have any off hand, but the majority of add-ons that users have
> installed are already on AMO, or are popular third-party add-ons (Like
> Norton Toolbar).

Sure - I'd be surprised if it were otherwise. But when it comes to
drawing conclusions and making decisions based on such data, the
devil's in the details.

For example, presumably this data comes from some sort of telemetry
that involves the browser communicating information about what add-ons
are installed to a Mozilla server. Assuming that's the case, it
under-represents segments of the user base that disable such
communication, which includes privacy-conscious users, and corporate
installs where features that communicate with third-party servers
might be disabled as a matter of policy. Incidentally, it is precisely
these segments that are most likely to want to run add-ons whose
source code they are reluctant to submit to Mozilla.

Also, a "majority" isn't saying much in this context. Just by the
80/20 rule, the large majority of add-on installations are likely to
be accounted for by a few popular add-ons, but that doesn't mean that
the long tail of less popular add-ons deserves to be given the short
shrift.

Regards,
Botond

[emilian...@iris-advies.com]

Excuse me? Just because I foresee problems in getting my extension signed I a timely manner, some of which already acknowledged by Jorge, I am automatically a malware author? This is the new strategy then, to demonize those who don't tow the party line?

[JS]

On 2/17/2015 7:27 PM, Mike Connor wrote:
> So you want to create a class of add-ons that Mozilla can't
> know about or protect users from in any fashion?

Think internal-use-only extension. One that is not at
all malicious but it is in some way sensitive. Internal
machines are configured to run the extension and protect
it. Outside parties should not even know of its existence.
Outside parties should not be able to disable it. No one
inside needs protecting. It is approved for use and
actually safe to use. This could be a corporate scenario
but it also could be an individual's scenario.

Somehow, and despite efforts to prevent it, the XPI file
becomes public. Joe User stumbles across it and tries to
install it on his system. This should not work because
his system isn't configured to allow it. His system isn't
configured to protect the extension either. So some form
of data collection has probably made you aware of the event.
Should there be steps that you want to take to deal with
this now in the wild extension, you take those steps.

[Thala Mew]

On Wednesday, February 18, 2015 at 6:32:17 AM UTC-7, JS wrote:
> Think internal-use-only extension. One that is not at
> all malicious but it is in some way sensitive. Internal
> machines are configured to run the extension and protect
> it. Outside parties should not even know of its existence.
> Outside parties should not be able to disable it. No one
> inside needs protecting. It is approved for use and
> actually safe to use. This could be a corporate scenario
> but it also could be an individual's scenario.

node.js/npm uses the `private` bit somewhat to handle this. As far as I am aware AMO via the install.rdf doesn't have anything similar.

This common use scenario also was not addressed in this initial signing requirement discussions. Clearly the path leading up to the signing requirement was hap-hazard and done very ineffectively. It shows the lack of experience on this decision from this team overall.

[Robert Kaiser]

Mike Connor schrieb:

> So you want to create a class of add-ons that Mozilla can't know about or
> protect users from in any fashion? And you don't expect that mechanism to
> be immediately abused?

You know that this sounds just like "How can we defeat terrorism when the NSA can't listen in to each and every communication"?
And I thought we were about users having privacy and controlling their experience and data rather than Mozilla being in control of all our users' installations?

KaiRo

[Mike Connor]

If that's what you're inclined to believe, of course it will. I'd equate
this more to the requirement to have a passport to travel internationally.
I can't enter any other country in the world without at least a passport,
and possibly a visa. If I had a criminal record or a serious communicable
disease, or a border agent decides my intent in entering the country is
illegal, I don't get to enter. We're not trying to know everything about
what users do, but we want to know a minimal amount in order to protect the
greater good.

There's a philosophical choice here. Either Mozilla has a continued role
to play in identifying and resolving real problems for Firefox, or we
don't. I believe we have a moral obligation to do the right thing for
users, while collecting the absolute minimum amount of data required to do
so. The average user can't self-assess whether an add-on can be trusted,
so there's a role for us there as well.

-- Mike

On 18 February 2015 at 16:15, Robert Kaiser <ka...@kairo.at> wrote:

> Mike Connor schrieb:

>
>> So you want to create a class of add-ons that Mozilla can't know about or
>> protect users from in any fashion? And you don't expect that mechanism to
>> be immediately abused?
>>
>

> You know that this sounds just like "How can we defeat terrorism when the
> NSA can't listen in to each and every communication"?
> And I thought we were about users having privacy and controlling their
> experience and data rather than Mozilla being in control of all our users'
> installations?
>
> KaiRo
>

[Mike Connor]

I understand the use-case. The bit you snipped out is the important
question: "And you don't expect that mechanism to be immediately abused?"

How do you prevent bad actors from using this mechanism for hiding their
bad actions and avoiding blocking even after they're discovered?

On 18 February 2015 at 08:33, JS <js_losxc...@comcast.net> wrote:

> On 2/17/2015 7:27 PM, Mike Connor wrote:
>

>> So you want to create a class of add-ons that Mozilla can't
>>
> > know about or protect users from in any fashion?
>

> Think internal-use-only extension. One that is not at
> all malicious but it is in some way sensitive. Internal
> machines are configured to run the extension and protect
> it. Outside parties should not even know of its existence.
> Outside parties should not be able to disable it. No one
> inside needs protecting. It is approved for use and
> actually safe to use. This could be a corporate scenario
> but it also could be an individual's scenario.
>

> Somehow, and despite efforts to prevent it, the XPI file
> becomes public. Joe User stumbles across it and tries to
> install it on his system. This should not work because
> his system isn't configured to allow it. His system isn't
> configured to protect the extension either. So some form
> of data collection has probably made you aware of the event.
> Should there be steps that you want to take to deal with
> this now in the wild extension, you take those steps.
>
>
>
>
>
>
>
>

[Paolo Inaudi]

Well, it's really hard too hear that the new Mozilla mission is to establish and control boundaries on the net, instead of eliminating them. I used to trust Mozilla.
Really, I am not surprised to hear those things in some news concerning Google or Microsoft or Apple. Those companies care about money, not users' freedom. But Mozilla being such impatient about eliminating user choice is really disappointing.

You never addressed the possibility, raised in another thread by Botond Ballo of governments asking Mozilla to censor add-ons. You know that can happen. How can you live with that?

You never spent a word on my last proposal, which appeared at least two or three times on this thread, which would allow to sideload user-provider certificate in an archive with a .dll extension, thus drawing a "bright line" between malicious and non malicious actors, but still providing an user with the possibility of loading that very dangerous class of plugins that "Mozilla knows nothing about". Not completely satisfying for me, since it's still too difficult for a user to install an extension he trusts. But viable.

Why are you providing users with development and unbranded versions then? why are you providing firefox source code? All this can be used by malicious actors.

If the point is that Mozilla wants control over each and every addon installed on each and every Firefox install, then Firefox as free software is dead, and this conversation does not have a point. If the problem is user security, then you really should be listening to us: there is little to no security in your approach.

Nobody answers your question "And you don't expect that mechanism to be immediately abused?". The answer is obvious: it will. You have however been provided with various mechanism as difficult to be abused as the one you are proposing.
So now you answer my question: you don't expect the mechanism of Mozilla as a sole signing authority to be abused as well? We do.

[Thala Mew]

On Wednesday, February 18, 2015 at 3:16:31 PM UTC-7, Mike Connor wrote:
> I believe we have a moral obligation to do the right thing for
> users, while collecting the absolute minimum amount of data required to do
> so. The average user can't self-assess whether an add-on can be trusted,
> so there's a role for us there as well.

Morality is a bad business practice and emotion should be absent from decision makers. Putting in effective means to curtail malware should be the objective.

Again you underestimate the AO public. I have a 70 year old consumer that has mentioned what AMO/Fx is doing is questionable. She has no choice but to drop support for AMO/Fx... and she's one of those less experienced but not stupid as you have just said. Clearly the assumption on this matter is unfounded and not backed up with any empirical data. e.g. a rash, emotional reaction similar to a witch hunt.

[Thala Mew]

Nicely put Paola

[Thala Mew]

On Wednesday, February 18, 2015 at 5:20:25 PM UTC-7, Thala Mew wrote:
> Nicely put Paola

Apologies on the typo... Paolo

[Mike Connor]

On 18 February 2015 at 17:56, Paolo Inaudi <p91...@gmail.com> wrote:

> Well, it's really hard too hear that the new Mozilla mission is to
> establish and control boundaries on the net, instead of eliminating them. I
> used to trust Mozilla.
> Really, I am not surprised to hear those things in some news concerning
> Google or Microsoft or Apple. Those companies care about money, not users'
> freedom. But Mozilla being such impatient about eliminating user choice is
> really disappointing.
>

As I've said many times, I believe this is a necessary choice to preserve
the current add-on model (no sandboxing, no limits on creativity or
functionality) without the abuse that compromises the security and daily
lives of millions of users every day. There's no effective way to
duplicate the current model without it being inherently insecure, so our
options are either to effectively prevent abuse through some other
mechanism or break the model in favour of something more directly
restricted. (Or abdicate responsibility and let users continue to get
hacked, but I don't think anyone's arguing for something that absurd.)

None of these options are great, but the version that minimizes user abuse
while still preserving the power and freedom of our add-ons model is what I
think is best. There's no objectively right answer here, all options have
painful tradeoffs, this is the pain we've chosen. It's the least
disruptive for the most people, and for those who want to opt out they can
run a version that doesn't require signing. I think that's a perfectly
valid solution that allows users to choose.

You never addressed the possibility, raised in another thread by Botond
> Ballo of governments asking Mozilla to censor add-ons. You know that can
> happen. How can you live with that?
>

Right, we talked about it in the office. To be clear, it's never happened
in ten years of having a blocklist. I've got a longer post to write on
censorship/takedowns/etc and what our current policy is, but the short
version is that very little will change here, though I get why some may
perceive this differently.

I have zero doubt that we'd fight any attempt to block or censor legal
content. It'd also be very obvious if something was taken down or
blocklisted, so it's not like we could secretly censor the world.

> You never spent a word on my last proposal, which appeared at least two or
> three times on this thread, which would allow to sideload user-provider
> certificate in an archive with a .dll extension, thus drawing a "bright
> line" between malicious and non malicious actors, but still providing an
> user with the possibility of loading that very dangerous class of plugins
> that "Mozilla knows nothing about". Not completely satisfying for me, since
> it's still too difficult for a user to install an extension he trusts. But
> viable.
>

I don't consider that proposal to be feasible at all, as "add something to
a magic file" is not a bright line, or really anything new. Something that
is okay sometimes, but not okay other times, isn't a bright line. A bright
line has to be objective, i.e. "modifying these files is always
malicious/unacceptable" is what we're going for.

> Why are you providing users with development and unbranded versions then?
> why are you providing firefox source code? All this can be used by
> malicious actors.
>

Because users should have the freedom to make informed choices and run
less-protected software. The same goes with rooting phones, running alpha
software, or what have you. Those who know what they're doing can always
reject our choices. Those who don't, and who trust us to protect them
(which is the vast majority of our users) are the people we are serving
with this approach.

> If the point is that Mozilla wants control over each and every addon
> installed on each and every Firefox install, then Firefox as free software
> is dead, and this conversation does not have a point. If the problem is
> user security, then you really should be listening to us: there is little
> to no security in your approach.
>
> Nobody answers your question "And you don't expect that mechanism to be
> immediately abused?". The answer is obvious: it will. You have however been
> provided with various mechanism as difficult to be abused as the one you
> are proposing.
> So now you answer my question: you don't expect the mechanism of Mozilla
> as a sole signing authority to be abused as well? We do.

On a technical level, every single proposal adds a trivially duplicated
workaround to the add-on model. That's no better than the status quo, and
the status quo has been deemed not acceptable from a product perspective.

At this point, we've gone around in a lot of circles. You have a different
perspective than mine, and our values are not 100% aligned. I think that's
okay, and I appreciate the energy and passion. That said, I don't think
you're going to convince me that there's a better technical solution that
still meets our goals, and I don't think I'm going to convince you that the
tradeoff here is necessary.

-- Mike

[Thala Mew]

On Wednesday, February 18, 2015 at 5:25:11 PM UTC-7, Mike Connor wrote:
> At this point, we've gone around in a lot of circles. You have a different
> perspective than mine, and our values are not 100% aligned. I think that's
> okay, and I appreciate the energy and passion. That said, I don't think
> you're going to convince me that there's a better technical solution that
> still meets our goals, and I don't think I'm going to convince you that the
> tradeoff here is necessary.
>
> -- Mike

Obviously the mind-set is fixated on damaging AMO/Fx reputation further. You will never convince the masses of this being a security improvement. This is indeed a fundamental shift in the paradigm for the charter for Fx... time to abandon that sinking ship imho.

On a side note Mike... please refrain from making threats in my private email inbox. If you can't say something in public then don't say it at all. This is deceptive to the target audience.

[Paolo Inaudi]

Il giorno giovedì 19 febbraio 2015 01:25:11 UTC+1, Mike Connor ha scritto:
> I don't consider that proposal to be feasible at all, as "add something to
> a magic file" is not a bright line, or really anything new. Something that
> is okay sometimes, but not okay other times, isn't a bright line. A bright
> line has to be objective, i.e. "modifying these files is always
> malicious/unacceptable" is what we're going for.
>

I will force myself to stop posting after this. Anyway, also replacing the firefox executable isn't a bright line. Modifying it isn't always malicious/unacceptable. The firefox upgrade process does it all the time.

The issue can be taken from two points of view.
>From the users perspective, to modify the firefox executable or the certificate storage file is acceptable when they are trying to install a non-Mozilla-certified addon they trust, not acceptable when an someone else installes it. So those two approaches are not distinguishable from the users perspective, except that working on the certificate storage is safer and allows a greater level of user control on what is allowed and what is not.

>From the perspective of tools used to prevent malware from attacking systems, what they see is either a process trying to replace the firefox main executable or a process trying to replace a firefox shared library. From their perspective, this is the same level of being malicious. To install your trusted certificate, you may have to disable temporarily your anti-malware application at this point, which is a much clearer indication of 'I trust this' that even installing a different browser.

As I stated before, I will refrain to try to convince you more, and search for free alternatives to Firefox instead. I don't know if I am more scared by the fact you as a single man can dictate the Mozilla policy this way, or by the alternative of all, or the vast majority of, Firefox developers agreeing with you.

[Gervase Markham]

On 18/02/15 22:56, Paolo Inaudi wrote:
> You never addressed the possibility, raised in another thread by
> Botond Ballo of governments asking Mozilla to censor add-ons. You
> know that can happen. How can you live with that?

We already have an addon blocklist; if this is a problem (which I don't
really think it is), then it's already a problem, and this change
doesn't make it any worse.

Gerv

[emilian...@iris-advies.com]

On Thursday, February 19, 2015 at 1:25:11 AM UTC+1, Mike Connor wrote:

> At this point, we've gone around in a lot of circles. You have a different
> perspective than mine, and our values are not 100% aligned. I think that's
> okay, and I appreciate the energy and passion. That said, I don't think
> you're going to convince me that there's a better technical solution that
> still meets our goals, and I don't think I'm going to convince you that the
> tradeoff here is necessary.

Jorge says something substantially different:

> If you're wondering what would it
> take for us to change course completely, then it would either be (1) a
> significant defect in the design that made us reconsider the whole
> approach or (2) an alternate proposal that satisfies our requirements
> with fewer restrictions for developers. We'll publish a blog post soon
> that spells out what those requirements are and what problems we're
> trying to solve, since the initial announcement was light on details.

At least he seems (slightly) open to alternative approaches that meet the same requirements he is going to put up. And if no conceivable argument is going to change your mind, then why did Jorge's blog post end with

>We welcome comments on this post, but if you want to debate the merits of this plan, please do so in the add-ons user experience list

You asked for debate, you git debate.

[JS]

On 2/18/2015 5:29 PM, Mike Connor wrote:
> I understand the use-case. The bit you snipped out is the important
> question: "And you don't expect that mechanism to be immediately abused?"
>
> How do you prevent bad actors from using this mechanism for hiding their
> bad actions and avoiding blocking even after they're discovered?

I broke that question out with the intention to respond, but
when I got to it I really didn't know how to. I think your
focus is:

1) Worst-case users who actively sabotage themselves
2) Machines where malicious software is running as root/admin
and it is specifically designed to exploit related mechanisms
3) Could such a mechanism ever be abused?

where mine is:

1) Best-case users who will play a productive role
2) Machines which are strongly protected against malicious
software in various layered ways
3) Could the overall context be made strong enough that even
with this mechanism the risks remain within acceptable levels?

[Mike Connor]

Where did I say no argument was going to change my mind? Please stop
putting words into my mouth. What I said was that I did not think you were
going to convince me, based on your suggestions and approach so far.

Debate is fine, I don't think anyone can say I've sidestepped the debate,
but there's a point where it's going nowhere. I've read and replied to
most/all of your posts. There's little likelihood that we will agree. At
that point, I think the respectful thing is to acknowledge the difference
of opinion and move forward.

-- Mike

On 19 February 2015 at 12:54, <emilian...@iris-advies.com> wrote:

> On Thursday, February 19, 2015 at 1:25:11 AM UTC+1, Mike Connor wrote:
>

> > At this point, we've gone around in a lot of circles. You have a
> different
> > perspective than mine, and our values are not 100% aligned. I think
> that's
> > okay, and I appreciate the energy and passion. That said, I don't think
> > you're going to convince me that there's a better technical solution that
> > still meets our goals, and I don't think I'm going to convince you that
> the
> > tradeoff here is necessary.
>

> Jorge says something substantially different:
>
> > If you're wondering what would it
> > take for us to change course completely, then it would either be (1) a
> > significant defect in the design that made us reconsider the whole
> > approach or (2) an alternate proposal that satisfies our requirements
> > with fewer restrictions for developers. We'll publish a blog post soon
> > that spells out what those requirements are and what problems we're
> > trying to solve, since the initial announcement was light on details.
>
> At least he seems (slightly) open to alternative approaches that meet the
> same requirements he is going to put up. And if no conceivable argument is
> going to change your mind, then why did Jorge's blog post end with
>
> >We welcome comments on this post, but if you want to debate the merits of
> this plan, please do so in the add-ons user experience list
>
> You asked for debate, you git debate.

[JS]

On 2/18/2015 5:16 PM, Mike Connor wrote:
> If that's what you're inclined to believe, of course it will. I'd equate
> this more to the requirement to have a passport to travel internationally.
> I can't enter any other country in the world without at least a passport,
> and possibly a visa. If I had a criminal record or a serious communicable
> disease, or a border agent decides my intent in entering the country is
> illegal, I don't get to enter.

Perhaps there is a useful concept in there: A user's system is
sovereign territory. It is independent. The user has supreme
power over it, including the right to conduct internal affairs
without interference from outside forces. It sets its own
policies, issue its own passports and visas, enforce its own
health and other standards, and polices its own borders.

I think what Mozilla is trying to do is uncomfortably close to:
promote itself to a position where it is the one that will be
doing such things. This isn't an opt-in feature. You aren't
simply offering to do these things on behalf of sovereigns. You
are literally just assuming that control and doing them.

[Thala Mew]

On Thursday, February 19, 2015 at 1:07:19 PM UTC-7, Mike Connor wrote:
> Debate is fine, I don't think anyone can say I've sidestepped the debate,
> but there's a point where it's going nowhere.

In other threads by self-praise from a few small stakeholders a.k.a the investment pressure. I think everyone can come to that conclusion. You try which is commendable but at the same time side-step just about everything preaching false integrity. This is a factual observation not a judgement.

> At
> that point, I think the respectful thing is to acknowledge the difference
> of opinion and move forward.

Continuance of moving back into the stone age and much closer to the reason why a lot of users/devs/etc left IE in the first place is more like it. Unreasonable comes to mind with some of the replies I have read not just from you. This group should have made this announcement way more public in the planning process and not just dropped a bomb shell on the community. I've had to do a ton more research just to validate any justification for this brazen change. The respectful thing is to start writing your own proposal balancing in the needs of the community versus the pocketbook and start publishing it publicly for transparency. I'm already drafting a pro vs cons on this and so far it's weighted far more towards AMO/Fx than anything. Integration management is an art that isn't just picked up without experience. I told everyone in another thread there is mass disapproval for this change. Some venues are saying that their comments are being ignored, censored (that would be mine from you as well from the mailing list)... How else did you, or your team, think this was going to go down? Not well would be mine especially with the incomplete notice on "we'll address development later" in the initial blog post.

We can agree to disagree but your mind is clearly made up even before things started.

[Thala Mew]

On Thursday, February 19, 2015 at 6:42:33 PM UTC-7, JS wrote:
> Perhaps there is a useful concept in there: A user's system is
> sovereign territory. It is independent. The user has supreme
> power over it, including the right to conduct internal affairs
> without interference from outside forces. It sets its own
> policies, issue its own passports and visas, enforce its own
> health and other standards, and polices its own borders.
>
> I think what Mozilla is trying to do is uncomfortably close to:
> promote itself to a position where it is the one that will be
> doing such things. This isn't an opt-in feature. You aren't
> simply offering to do these things on behalf of sovereigns. You
> are literally just assuming that control and doing them.

Very nice counter analogy.

[Philipp Kewisch]

Including the right to not use Firefox. It is not like Mozilla is
forcing you to use Firefox with extension signing. I totally understand
you don't like the new extension signing concepts and I myself am not a
fan either because I don't yet believe that malware authors won't just
spend a few days to get around the checks. This is getting a little out
of hand, don't you think? Instead of disucssing how devastating the move
may be, lets get back to disucssing alternative proposals that would
help Mozilla fulfill the goals and still make life easy enough for
developers.

Philipp

[Mike Connor]

I think that's a decent summary. I'd add that my #1 focus is protecting
the widest possible number of people who are being abused by these
mechanisms, at the minimum cost to user choice. That group skews to deeply
non-technical users, who generally don't realize why Firefox has changed,
or that they can fix it. They don't connect apps they install to changes
to other apps. They don't even connect unrelated changes made by add-ons.

Those users massively outweigh the number of people using non-AMO add-ons
from authors who simply won't get things signed for principle or overhead
reasons. And those users skew to a demographic that's much more aware of
how their devices work, and are fully capable of making an informed choice
to run builds without the protection. We're creating a relatively small
amount of overhead for those users, and I consider that to be an acceptable
tradeoff if it helps us protect a much larger set of users.

Right now, I think everyone has a viable option if they want it. We're
still figuring out the right answer for the enterprise-type use-case, and
it's more than likely that we'll devise something specifically for ESR
builds that supports that use-case. This won't impact ESR users until
Firefox 45, so we have some time to design something that's viable for
locked-down environments. It's possible that we'll simply class ESR in the
same category as unbranded builds, but we need to talk to the enterprise
users before we decide anything.

On 19 February 2015 at 14:38, JS <js_losxc...@comcast.net> wrote:

> On 2/18/2015 5:29 PM, Mike Connor wrote:
>

>> I understand the use-case. The bit you snipped out is the important
>> question: "And you don't expect that mechanism to be immediately abused?"
>>
>> How do you prevent bad actors from using this mechanism for hiding their
>> bad actions and avoiding blocking even after they're discovered?
>>
>

> I broke that question out with the intention to respond, but
> when I got to it I really didn't know how to. I think your
> focus is:
>
> 1) Worst-case users who actively sabotage themselves
> 2) Machines where malicious software is running as root/admin
> and it is specifically designed to exploit related mechanisms
> 3) Could such a mechanism ever be abused?
>
> where mine is:
>
> 1) Best-case users who will play a productive role
> 2) Machines which are strongly protected against malicious
> software in various layered ways
> 3) Could the overall context be made strong enough that even
> with this mechanism the risks remain within acceptable levels?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[fpi...@gmail.com]

I often patch some add-ons (from AMO or not) to customize them for my own use; I change their appearance or their behavior, or even make them work with the latest release of Firefox.
I will not submit my changes to AMO to be able to run these custom add-ons because I do not want to maintain them. I just want to follow the latest version from the original developer (for this, I do not want to change the ID of the add-on because I want to know when the original add-on is updated).

So please give us a preference or command line option to be able to run such custom add-ons.

Sorry for my English.

[Tyler Downer]

AFAIK you wouldn't have to submit these add-ons, just sign them and use
them. Signing isn't the same as submitting to AMO.

> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>

--
Tyler Downer
Project Manager, User Advocacy

[J. Ryan Stinnett]

On Fri, Feb 20, 2015 at 11:14 AM, Tyler Downer <tdo...@mozilla.com> wrote:
> AFAIK you wouldn't have to submit these add-ons, just sign them and use
> them. Signing isn't the same as submitting to AMO.

Signing is different from being *hosted by AMO for distribution*, yes.

However, it sounds like the objection was about having to submit the
add-on to any Mozilla service whatsoever, which is what's required to
get the add-on signed under the current proposal, so it's similar to
many other objections mentioned by others.

I think AMO here is being used as the term for "a service controlled
by Mozilla", not "the place where the add-on is distributed". The
terminology is confusing, especially if the signing service reuses the
AMO submission workflow, but just with toggle for "don't host my
add-on" or something.

- Ryan

[Gervase Markham]

On 20/02/15 01:43, JS wrote:
> Perhaps there is a useful concept in there: A user's system is
> sovereign territory. It is independent. The user has supreme
> power over it, including the right to conduct internal affairs
> without interference from outside forces. It sets its own
> policies, issue its own passports and visas, enforce its own
> health and other standards, and polices its own borders.

Extending this analogy would suggest that, if Mozilla took your view,
then the correct response to observing that lots of our users had
malicious or search-hijacking extensions installed is "too bad; they are
sovereign on their systems, they should have been more careful."

Is that what you think Mozilla's position should be?

If not, and you think we should try and prevent such nastiness in any
way at all, then you are also arguing for some form of intereference in
user sovereignty. The only debate then is, how much interference?

Gerv

[JS]

On 2/20/2015 11:44 AM, Mike Connor wrote:

> Right now, I think everyone has a viable option if they want it.

At this point I'm inclined to question the viability of the
unbranded build:

- It won't even be an option for those who don't know about it,
and we don't yet know how well it will be hidden.
- It is unclear how the separate build will install and whether
there will be any related migration issues. Does Unbranded
cleanly install over and replace Firefox? Does Firefox cleanly
install over and replace Unbranded?
- The level of control (simple on/off) is not sufficient for
some uses.
- Will there be a way for extension developers to sign their
own extensions and have those signatures checked? This would
be a desirable option not only in private extension scenarios
but also in cases where extensions are distributed through
other parties (including AMO).
- Distribution unknowns: Available in repositories? Available
as a portable app? Available in Google Play and/or any other
applicable stores? Similar questions for any derivative
applications that adopt Mozilla signing.
- There are antivirus, backup, scripting, and other tools that
explicitly test for specific applications. We'd find some
checking for "Firefox" in various strings and locations. An
unbranded build with "Firefox" removed from any of those
places has the potential to break something important.

> We're still figuring out the right answer for the
> enterprise-type use-case, and it's more than likely that
> we'll devise something specifically for ESR builds that
> supports that use-case. This won't impact ESR users until
> Firefox 45, so we have some time to design something that's
> viable for locked-down environments. It's possible that
> we'll simply class ESR in the same category as unbranded
> builds, but we need to talk to the enterprise users before
> we decide anything.

So are you going to hold off on all decisions until you have
solicited ideas from enterprises and acquired a clearer
picture of usage scenarios and design options?

Some of those guys might have valuable input on how to
store configuration options in ways that are most
tamper-resistant. I'd expect some off client solutions,
but maybe there would be some on client solutions as
well. Antivirus programs and various other applications
use techniques to protect their components and/or data
from client side threats. Perhaps there is an enterprise
user that could share some tricks.

If you can find a tolerable solution for that problem,
everything becomes so much simpler. No unbranded build
necessary, users could select the signing options they
want for whatever release, non-release, ESR, non-ESR
build they are running.

[Robert Kaiser]

Mike Connor schrieb:

> I think that's a decent summary. I'd add that my #1 focus is protecting
> the widest possible number of people who are being abused by these
> mechanisms, at the minimum cost to user choice.

All of us in here are in agreement on that, I'd think. My (and I guess others') concern is that the current proposal is actually not "minimum cost to user choice", we in fact see it as mostly taking user choice away.
Examples for that are when it comes to in-development add-ons, or ones with code that is legally not allowed to go outside the premises of some company or organization, or even ones that are illegal in Mozilla's jurisdiction and therefore or for other reasons can't (or won't) be signed by Mozilla but are actually fully fine for and wanted by the respective user.

> Those users massively outweigh the number of people using non-AMO add-ons
> from authors who simply won't get things signed for principle or overhead
> reasons. And those users skew to a demographic that's much more aware of
> how their devices work, and are fully capable of making an informed choice
> to run builds without the protection. We're creating a relatively small
> amount of overhead for those users, and I consider that to be an acceptable
> tradeoff if it helps us protect a much larger set of users.

I don't think that very hard to find builds that are not "Firefox" but some other brand (not even sure we have one for those yet) and completely turning off add-on security on those builds are the right solutions for that.

I agree on the signing itself, I just do not agree on the mechanisms on exceptions: I'd like a general mechanism to very consciously make very specific exceptions but leave the safety mechanism intact otherwise. Ideally we could put that into Firefox proper and not need a separate line of "unbranded and insecure" builds.

KaiRo