Not allowing overrides makes no sense. There are other solutions.

[hostelm...@gmail.com]

If a user is savvy enough to edit about:config to modify xpinstall.signatures.required, then they are savvy enough to take responsibility for their own security.

There seems to be no reason for restricting what people can do with their browsers except to reduce software freedom. Someone inside of Mozilla should speak up about it. This restriction is not reasonable. The problem with these kinds of app stores is that a central authority determines what content and functionality consumers are able to use.

Instead of blocking unsigned extensions, why not allow users to install them via about:config, but put a red warning button on the browser that lets them know that any problems they might be having are possibly due to their unsigned extensions? There are other ways to take care of malware besides restricting users' software freedom.

"Those who surrender freedom for security will not have, nor do they deserve, either one."

[Emiliano Heyns]

Your argument is fatally flawed. Mozilla doesn't police kinds of functionality, "just" kinds of coding, plus they also put out a browser version for your convenience which allows installing anything without restriction. And if that isn't enough, they also provide full source and build instructions.

You're freedom is in no way endangered by this move. The signing proposal is flawed enough as it is; there's no need to bring straw man arguments against it to make it look bad.

[Josh]

On Monday, October 19, 2015 at 1:59:22 PM UTC-7, Emiliano Heyns wrote:
> You're freedom is in no way endangered by this move. The signing proposal is flawed enough as it is; there's no need to bring straw man arguments against it to make it look bad.

It creates a central authority that determines what software can be installed on your computer. By "your", I mean all consumers.

What is Mozilla going to do when people make horribly distasteful "apps" that no sane person would want their name associated with? Either Mozilla signs them, giving the official stamp of approval on some level (bad for PR), or doesn't sign them, and then becomes a censor.

Other companies also create locked down central software distribution, but it's a bad direction for technology freedom:
Apple locked down software on iOS devices.
Microsoft said that developers couldn't use the Metro interface unless their app is distributed though the MS app store.
Tech companies do not allow consumers to have root access to their mobile devices, also "for their own safety".
Now you can't build on top of Firefox unless the software is approved by a central authority, otherwise no one will be able to install your software.

Mozilla is currently a benevolent company, but someday it might not be run by the same people.

I can understand that there is a need to do *something* about the problems, but complete lockdown of consumers' software with no override doesn't seem like a good idea. There should be a way to override it in a safe way (probably not with about:config, as someone else mentioned).

If I am misunderstanding something, let me know.

[Emiliano Heyns]

Except if you want all of that, you can just sign the unbranded version.
You're only beholden to this highly speculative scenario of yours if you
want the Firefox icon in your browser. That's it.

[Emiliano Heyns]

I agree on the one, disagree on the other.

The general public doesn't get Firefox installed, so that's a manual
installation anyhow. Installing unbranded rather than branded doesn't seem
to me too big a deal, and it's what I'm going to recommend my users do.

I agree that Mozilla is currently overstepping the bounds of their own
proposal, and you'll see that the last comment against the ineffective
security theater that is the current signing proposal in the thread you
link to is mine. I think the signing proposal is ham-fisted, ill conceived,
and in effective as in practice an unlisted extension can do pretty much
anything it wants to. The unlisted scanner will blithely sign whatever the
fairly dumb scanner deems OK, which includes paths to execution of
untrusted code loaded from the internet.

On Tue, Oct 20, 2015 at 8:03 AM, Florian Bruhin <m...@the-compiler.org> wrote:

> * Emiliano Heyns <emilian...@iris-advies.com> [2015-10-20 07:44:50
> +0200]:

> > Except if you want all of that, you can just sign the unbranded version.
> > You're only beholden to this highly speculative scenario of yours if you
> > want the Firefox icon in your browser. That's it.
>

> I think Josh's point was - and I agree with him - that *you* and *I*
> can do that, but the "general public" can/will not.
>
> As it seems, the reviews (currently) even reject addons on code
> quality concerns rather than *security* concerns (see [1]).
>
> This is highly concerning, IMHO. Seeing that a legitimate addon which
> exists almost since a decade got rejected based on "code quality" is a
> problem - expecting all users to install an unbranded version of
> Firefox is impossible and seems to defeat the purpose, no?
>
> Florian
>
> [1]
> https://groups.google.com/d/msg/mozilla.addons.user-experience/lU5WZmwS4Qc/i8si8nTTAQAJ
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
> GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
> I love long mails! | http://email.is-not-s.ms/
>

[Florian Bruhin]

[Gervase Markham]

On 20/10/15 00:59, Josh wrote:
> It creates a central authority that determines what software can be
> installed on your computer. By "your", I mean all consumers.

That is already true; Firefox respects Mozilla's addon blacklist. If
Mozilla wants to stop you running an addon, it already technically can.
The fact that this power has not been abused thusfar should give you
some confidence.

Gerv

[Jorge Villalobos]

On 10/20/15 12:03 AM, Florian Bruhin wrote:
> * Emiliano Heyns <emilian...@iris-advies.com> [2015-10-20 07:44:50 +0200]:
>> Except if you want all of that, you can just sign the unbranded version.
>> You're only beholden to this highly speculative scenario of yours if you
>> want the Firefox icon in your browser. That's it.
>
> I think Josh's point was - and I agree with him - that *you* and *I*
> can do that, but the "general public" can/will not.
>
> As it seems, the reviews (currently) even reject addons on code
> quality concerns rather than *security* concerns (see [1]).
>
> This is highly concerning, IMHO. Seeing that a legitimate addon which
> exists almost since a decade got rejected based on "code quality" is a
> problem - expecting all users to install an unbranded version of
> Firefox is impossible and seems to defeat the purpose, no?
>
> Florian
>
> [1] https://groups.google.com/d/msg/mozilla.addons.user-experience/lU5WZmwS4Qc/i8si8nTTAQAJ
>

Zotero hasn't been approved due to security concerns. I have no reason
to believe there's any malicious intent, and I don't know if the current
issues are exploitable. All we're asking from them is that they
gradually move to coding practices that make it easier for us to assess
its safety. It's certainly a code quality issue, but it has a security
motivation.

Jorge

[Emiliano Heyns]

On Tuesday, October 20, 2015 at 4:40:52 PM UTC+2, Jorge Villalobos wrote:

> Zotero hasn't been approved due to security concerns. I have no reason
> to believe there's any malicious intent, and I don't know if the current
> issues are exploitable. All we're asking from them is that they
> gradually move to coding practices that make it easier for us to assess
> its safety. It's certainly a code quality issue, but it has a security
> motivation.

This is a really weird argument. "We do not forbid their coding style in theory, just in practice". Can you really claim with a straight face that *Zotero* raises security concerns, rather than "coding-like-Zotero-has"?

You *know* the Zotero crew, and you *know* their intent. I think they've proven over the years that they can put out a stable and safe product that their users appreciate. It has had how many security incidents over the years?

To have this crew prove their worthiness at substantial cost (effort) for zero gain is... well, I have no decent words. What odds do you give it that after a long wait and substantial effort on *both* sides the conclusion of the review process is "yep, just as we thought, nothing wrong"? I think I like those odds.

I am well aware of the fairness/slippery slope/whatever argument, but that deals with the aggregate, not with particulars such as Zotero. What it boils down to is that you're willing to let the proven-innocent suffer for the bad. The time reviewing Zotero is much better spent elsewhere.

I applaud the security motivation, but the results are disastrous for groups like Zotero and devs like me. We suddenly have to prove our innocence at our own cost. I don't think that whitelisting established players (perhaps not me, but certainly Zotero) is unreasonable against the odds that the Zotero crew would suddenly turn dark.

[Dan Stillman]

On 10/20/15 10:40 AM, Jorge Villalobos wrote:
> On 10/20/15 12:03 AM, Florian Bruhin wrote:

>> As it seems, the reviews (currently) even reject addons on code
>> quality concerns rather than *security* concerns (see [1]).
>>
>> This is highly concerning, IMHO. Seeing that a legitimate addon which
>> exists almost since a decade got rejected based on "code quality" is a
>> problem - expecting all users to install an unbranded version of
>> Firefox is impossible and seems to defeat the purpose, no?
>>
>> Florian
>>
>> [1] https://groups.google.com/d/msg/mozilla.addons.user-experience/lU5WZmwS4Qc/i8si8nTTAQAJ
>>

> Zotero hasn't been approved due to security concerns. I have no reason
> to believe there's any malicious intent, and I don't know if the current
> issues are exploitable. All we're asking from them is that they
> gradually move to coding practices that make it easier for us to assess
> its safety. It's certainly a code quality issue, but it has a security
> motivation.

Um, this is a lie.

Jorge, Zotero *is* signed, so there are no "current issues". You know
this because you yourself acknowledged that every issue raised in the
initial review was innocuous in context and said Zotero could be
approved, which it was without our making any actual changes. The only
thing you had us do is unminify two trivial TinyMCE plugins and add
comments explaining why lines weren't actually issues (e.g., why code
using innerHTML that we copied verbatim from MDN was safe). AMO has
never identified an actual security issue in Zotero, and every single
time something has been flagged in a review, we've had to explain why it
was safe in context, and in many cases why, despite generic AMO
guidelines, it was the only way something could be coded.

Second, it's disingenuous to suggest that Zotero simply needs to change
"coding practices", since�you yourself told us that Zotero "will
probably have to go through manual review every time it is submitted",
and that's the whole reason we're having this discussion. Zotero exists
as a Firefox extension specifically because we use all sorts of
low-level functionality that Mozilla makes available (nsIProcess,
js-ctypes, and more), but that code is what prevents us from ever being
accepted without whitelisting. We could waste a month updating hundreds
of thousands of lines of code (that AMO has already approved as safe
many times over the years) to please the validator, but it wouldn't make
a difference in terms of our ability to be automatically signed.

Suggesting publicly that Zotero has known potentially exploitable issues
because you can't defend your broken scheme any other way is totally
inappropriate. When we're forced to discontinue Zotero for Firefox when
Firefox 43 comes out, it will be on you, Jorge, not us. All we want to
do is continue serving our users like we've done for 9 years.

[Josh]

On Tuesday, October 20, 2015 at 2:27:26 AM UTC-7, Gervase Markham wrote:
> That is already true; Firefox respects Mozilla's addon blacklist. If
> Mozilla wants to stop you running an addon, it already technically can.
> The fact that this power has not been abused thusfar should give you
> some confidence.

Blocking individual programs that are known to be malicious is *much* different than blocking all software by default and whitelisting approved ones.

I don't have confidence that tech companies will always maintain integrity, because someday they will be run by different people. We're at a point in history where we are probably laying the groundwork of technology philosophy for the next few hundred years. The invention of a global information network (the Internet) is as important to human history as the discoveries of fire and electricity. For the sake of the next generations, software distribution should not exclusively be controlled by central authorities. Companies like Apple, Microsoft, and Google are doing it the wrong way.

I know that someone can download an alternate version of the browser, but most people won't, and therefore a blocking of a specific program or content by a central authority will have the practical effect of censorship in the long run, otherwise Mozilla will have to "approve" extremely distasteful things. It seems like people are thinking only one step ahead and not two.

[WaltS48]

Isn't the block list a fix after the damage has been done to the user,
while signing is a blocking before the damage is done solution. Thus
negating the need for the block list.

There is always going to be resistance to change, but at some point you
have to accept it and move on.

I'd be burying myself into learning WebExtensions, if I was an extension
developer instead of just a common user.

--
Linux Mint 17.2 "Rafaela" | KDE 4.14.2 | Thunderbird 42.0b2
One users useless feature, is a useful feature to another
Go Blue Jays! Go Pens! Go Sabres! Go Pitt!
[Visit Pittsburgh]<http://www.visitpittsburgh.com/>
[Coexist · Understanding Across Divides]<https://www.coexist.org/>

[Jorge Villalobos]

Oh, sorry about that, I guess I lost track of the pending issues at some
point. I recall our email discussion but didn't remember us reaching a
resolution.

> Second, it's disingenuous to suggest that Zotero simply needs to change
> "coding practices", since�you yourself told us that Zotero "will
> probably have to go through manual review every time it is submitted",
> and that's the whole reason we're having this discussion.

The reason it will need manual review every time has to do with those
coding practices. Some of them can be flagged so they don't come up in
future reviews, but others can't, especially if they're widespread.
Having said that, an add-on of that size and complexity is likely to
bring up these flags every time it's submitted, yes. I don't think that
completely whitelisting the add-on is an appropriate solution, though.

> Zotero exists
> as a Firefox extension specifically because we use all sorts of
> low-level functionality that Mozilla makes available (nsIProcess,
> js-ctypes, and more), but that code is what prevents us from ever being
> accepted without whitelisting. We could waste a month updating hundreds
> of thousands of lines of code (that AMO has already approved as safe
> many times over the years) to please the validator, but it wouldn't make
> a difference in terms of our ability to be automatically signed.
>
> Suggesting publicly that Zotero has known potentially exploitable issues
> because you can't defend your broken scheme any other way is totally
> inappropriate. When we're forced to discontinue Zotero for Firefox when
> Firefox 43 comes out, it will be on you, Jorge, not us. All we want to
> do is continue serving our users like we've done for 9 years.

I said specifically I didn't know if they were exploitable. They are
security issues to the extent that we can't ensure they are safe without
a very meticulous inspection of all of the code that leads to those
particular flagged code sections, which isn't feasible due to the size
and complexity of the code.

Jorge

[Gijs Kruitbosch]

(Full disclosure: I work for Mozilla, and I was a volunteer AMO reviewer
a long time ago. I work on Firefox now. In the more than 10 years I have
been part of the Mozilla project, I have seen (and in some cases fixed)
a number of security issues in add-ons and Firefox. I also used to use
Zotero, years back, for research I did as part of my BSc and MSc.)

Or, you know, you leave in code with comments that say something like
"AMO Reviewer: This code is here but is never run when it's used by
Firefox", and presumably the reviewers then just have to take your word
for it, and not think too hard about how the vulnerable code could
perhaps still be used by an attacker (even if it's not normally run
inside Zotero).***

Why don't you just remove those files / that code? Why is it even in the
Firefox add-on?

It seems disingenuous to complain about validation issues due to
insecure practices when at least some of those are completely under your
(trivial) control, and not "necessary" at all.

It's fine to have a healthy discussion about the limits of validation,
but I don't think it's fair for you to be putting all the blame on the
AMO team when there is plenty Zotero could be doing to make reviews
quicker and make the validator put up fewer positives (false or not).

On 16/10/2015 09:53, Dan Stillman wrote:
> It's wildly disproportionate to insist
> on that because of one supposedly legitimate extension years ago that
> started injecting ads. It's also not my job to figure out what the
> criteria are for whitelisting, but it's Mozilla's job to ensure that
> legitimate extensions that empower users can continue to exist.

This is likewise not a very productive argument to be making. You're saying:

- of course you shouldn't trust everybody (that one add-on? Why didn't
you see that coming?)
- you should trust us, though, we are obviously not corruptible
- I'm not going to try to figure out by what criteria we are trustworthy
and that other add-on shouldn't (have) been

This is a serious issue. How would you build a "trusted publisher" (or
add-on) scheme like the one you're requesting? Who qualifies? Why? What
kind of auditing should they be submitted to? When do they get removed?

Just as you suggest it's essentially 'unfair' for Mozilla to have
requirements for signing add-ons, it doesn't seem particularly helpful
to say "You need to implement this thing, we won't help you to actually
work out the details, but we'll still insist you do it, even if it makes
your users objectively less safe" [which a 'trusted add-on' scheme
without adequate safeguards clearly would].

~ Gijs


*** fwiw, I found the code and comment in question by going to your
website, downloading and unzipping the XPI, and looking for "innerHTML",
because you mentioned it in your earlier message.

[Dan Stillman]

On 10/20/15 2:04 PM, Jorge Villalobos wrote:
> On 10/20/15 9:52 AM, Dan Stillman wrote:

>> Second, it's disingenuous to suggest that Zotero simply needs to change

>> "coding practices", since...you yourself told us that Zotero "will

>> probably have to go through manual review every time it is submitted",
>> and that's the whole reason we're having this discussion.

> The reason it will need manual review every time has to do with those
> coding practices. Some of them can be flagged so they don't come up in
> future reviews, but others can't, especially if they're widespread.
> Having said that, an add-on of that size and complexity is likely to
> bring up these flags every time it's submitted, yes.

You just directly contradicted yourself. If an add-on of Zotero's size
and complexity will be flagged every time, then it's not because of our
"coding practices" — unless the coding practice in question is "writing
a lot of complex code". As I said, if we could just rewrite a bunch of
(perfectly safe) setTimeout() or on* calls to please the validator, we'd
do it, but that wouldn't be sufficient, as you've just acknowledged.
When I upload the Zotero XPI, it complains about things like js-ctypes
and nsIProcess, which can't be removed unless we remove a huge amount of
functionality from Zotero. (At least, I think it mentions those. At the
moment it just hangs, as it did for years. The review process literally
cannot support an extension like Zotero.)

> I don't think that completely whitelisting the add-on is an appropriate solution, though.

Can you explain why not? What threat are you preventing by not
whitelisting Zotero? What possible good are you performing for the
Mozilla community by delaying Zotero updates for a minimum of 4 days
every time we want to put out a bug fix? What actual security flaw has
AMO ever identified in Zotero?

>> Zotero exists
>> as a Firefox extension specifically because we use all sorts of
>> low-level functionality that Mozilla makes available (nsIProcess,
>> js-ctypes, and more), but that code is what prevents us from ever being
>> accepted without whitelisting. We could waste a month updating hundreds
>> of thousands of lines of code (that AMO has already approved as safe
>> many times over the years) to please the validator, but it wouldn't make
>> a difference in terms of our ability to be automatically signed.
>>
>> Suggesting publicly that Zotero has known potentially exploitable issues
>> because you can't defend your broken scheme any other way is totally
>> inappropriate. When we're forced to discontinue Zotero for Firefox when
>> Firefox 43 comes out, it will be on you, Jorge, not us. All we want to
>> do is continue serving our users like we've done for 9 years.

> I said specifically I didn't know if they were exploitable. They are
> security issues to the extent that we can't ensure they are safe without
> a very meticulous inspection of all of the code that leads to those
> particular flagged code sections, which isn't feasible due to the size
> and complexity of the code.

I explained them — including some that couldn't be rewritten any other
way — and you said "OK" to each one. So you either you approved an
extension with potentially exploitable security vulnerabilities or you
recognized that they don't actually pose a threat. Either way, it
undermines the argument that the review process is anything more than
security theater.

And again, this entire scheme was sold to the community on the grounds
that it would protect users from malware, not that it would be used to
enforce generic and highly debatable AMO coding rules on all extensions.

[Kaply Consulting]

On 10/20/15 1:32 PM, Gijs Kruitbosch wrote:
>
> This is a serious issue. How would you build a "trusted publisher" (or
> add-on) scheme like the one you're requesting? Who qualifies? Why?
> What kind of auditing should they be submitted to? When do they get
> removed?
>
>

Trusted publisher is the model that is used for every other signing
mechanism, so I'm not sure how you could argue that it's not possible to
do. You simply provide a low cost barrier to entry to verify identity.

One of the main arguments for Mozilla's way is that it has a zero cost
barrier to entry, but that could have been overcome.

Trusted publisher would have avoided all these issues.

Mike



--
Mike Kaply - Kaply Consulting in Austin, TX
Sign up for my newsletter - http://mike.kaply.com/email/
http://mike.kaply.com | http://www.linkedin.com/in/mkaply

[Gijs Kruitbosch]

On 20/10/2015 20:24, Kaply Consulting wrote:
> On 10/20/15 1:32 PM, Gijs Kruitbosch wrote:
>>
>> This is a serious issue. How would you build a "trusted publisher" (or
>> add-on) scheme like the one you're requesting? Who qualifies? Why?
>> What kind of auditing should they be submitted to? When do they get
>> removed?
>>
>>
> Trusted publisher is the model that is used for every other signing
> mechanism, so I'm not sure how you could argue that it's not possible to
> do. You simply provide a low cost barrier to entry to verify identity.
>
> One of the main arguments for Mozilla's way is that it has a zero cost
> barrier to entry, but that could have been overcome.
>
> Trusted publisher would have avoided all these issues.

I don't see why there would be any correlation between "has X dollars
(or not)" and "takes the security of our users seriously (or not)"

~ Gijs

[Emiliano Heyns]

Since you're apparently not an extension developer I'm a little confused on
why you think that these complaints are trivial when you don't know the
field.

[Dan Stillman]

On 10/20/15 2:32 PM, Gijs Kruitbosch wrote:
> Or, you know, you leave in code with comments that say something like
> "AMO Reviewer: This code is here but is never run when it's used by
> Firefox", and presumably the reviewers then just have to take your
> word for it, and not think too hard about how the vulnerable code
> could perhaps still be used by an attacker (even if it's not normally
> run inside Zotero).***
>
> Why don't you just remove those files / that code? Why is it even in
> the Firefox add-on?

Because Zotero shares large sections of code between the Zotero for
Firefox, Zotero Standalone, and several browser extensions, and
maintaining totally separate versions would be difficult and error-prone.

For this example, if you look further up you'll see that this is
actually the example that's straight from MDN, using
document.implementation.createHTMLDocument("") and .innerHTML to parse —
but not load — HTML when DOMParser isn't available.

In any case, we didn't ask to be on AMO again, so it's a little rich to
blame us for writing totally safe code that requires reviewers to have
to think a little bit. The alternative would be to acknowledge that we
know what we're doing, that AMO has never found a legitimate security
issue in Zotero, and that we take the security of Zotero far more
seriously than any else is going to.

> It seems disingenuous to complain about validation issues due to
> insecure practices when at least some of those are completely under
> your (trivial) control, and not "necessary" at all.

If you're going to accuse Zotero of "insecure practices", please point
to evidence and explain exactly how they can be exploited. Calling
"setTimeout(Zotero_Preferences.Sync.verifyStorageServer, 1);" isn't
insecure, even if the validator complains about it. Yes, we could spend
a lot of time rewriting — and testing — lines like this scattered
throughout hundreds of thousands of lines of code, but there would be
absolutely no benefit to users, and as Jorge has said it wouldn't result
in our being automatically signed anyway, so those lines are beside the
point.

If the editors had identified an actual security vulnerability in
Zotero, 1) we would have fixed it immediately and 2) the editors
wouldn't have approved the extension.

> It's fine to have a healthy discussion about the limits of validation,
> but I don't think it's fair for you to be putting all the blame on the
> AMO team when there is plenty Zotero could be doing to make reviews
> quicker and make the validator put up fewer positives (false or not).

This is a red herring. Rewriting some setTimeout() calls isn't going to
cause Zotero to be automatically signed, and it's not going to cause it
to be reviewed appreciably quicker. We submitted a version with a few
lines of changes, and it took a week to be approved.

Even a hypothetical reduction from 4 days to 2 days wouldn't make a
difference for us. If we can't release updates — like the critical ones
I described in the other thread the other day — immediately, as we've
done for nearly a decade, we can't ask people to rely on Zotero for
important work. It's that simple.

> On 16/10/2015 09:53, Dan Stillman wrote:
> > It's wildly disproportionate to insist
> > on that because of one supposedly legitimate extension years ago that
> > started injecting ads. It's also not my job to figure out what the
> > criteria are for whitelisting, but it's Mozilla's job to ensure that
> > legitimate extensions that empower users can continue to exist.
>
> This is likewise not a very productive argument to be making. You're
> saying:
>
> - of course you shouldn't trust everybody (that one add-on? Why didn't
> you see that coming?)
> - you should trust us, though, we are obviously not corruptible
> - I'm not going to try to figure out by what criteria we are
> trustworthy and that other add-on shouldn't (have) been
>

> This is a serious issue. How would you build a "trusted publisher" (or
> add-on) scheme like the one you're requesting? Who qualifies? Why?
> What kind of auditing should they be submitted to? When do they get
> removed?
>

> Just as you suggest it's essentially 'unfair' for Mozilla to have
> requirements for signing add-ons, it doesn't seem particularly helpful
> to say "You need to implement this thing, we won't help you to
> actually work out the details, but we'll still insist you do it, even
> if it makes your users objectively less safe" [which a 'trusted
> add-on' scheme without adequate safeguards clearly would].

First, this is blurring the lines again — is the issue malicious
developers, or is it "code quality"? You can't expect people to suggest
alternatives if the entire premise used to sell this scheme has turned
out to be false.

But as we've all been saying repeatedly, this isn't our scheme. It's
Mozilla's. We're telling you it's broken if it can't support a
9-year-old extension produced by a large research university,
recommended by nearly every university in the world, funded by major
philanthropic foundations, and even distributed in a Firefox bundle by
Mozilla itself, with no history of security issues or user-hostile
behavior. And that's just an extreme case, ignoring all the other
complex extensions by conscientious developers who don't have the
benefit of our backing (say, Emiliano's extension).

If you can't figure out a way to support those, then maybe the whole
scheme is broken and shouldn't be put in place until you figure out how
to do so. Whitelisting obviously legitimate, responsible, front-loaded
extensions that are having trouble with the validator would be an easy
place to start.

[Kaply Consulting]

On 10/20/15 2:41 PM, Gijs Kruitbosch wrote:
> On 20/10/2015 20:24, Kaply Consulting wrote:

>> On 10/20/15 1:32 PM, Gijs Kruitbosch wrote:
>>>
>>> This is a serious issue. How would you build a "trusted publisher" (or
>>> add-on) scheme like the one you're requesting? Who qualifies? Why?
>>> What kind of auditing should they be submitted to? When do they get
>>> removed?
>>>
>>>
>> Trusted publisher is the model that is used for every other signing
>> mechanism, so I'm not sure how you could argue that it's not possible to
>> do. You simply provide a low cost barrier to entry to verify identity.
>>
>> One of the main arguments for Mozilla's way is that it has a zero cost
>> barrier to entry, but that could have been overcome.
>>
>> Trusted publisher would have avoided all these issues.
>

> I don't see why there would be any correlation between "has X dollars
> (or not)" and "takes the security of our users seriously (or not)"

No, it has to do with identity verification which is what everyone else
focuses on because that's a better stick to use.

If you screw up, we revoke your ability to publish extensions completely
and block you from using our platform.

The Mozilla process chooses to put all the burden on the front end which
is very difficult to manage unless you have hundreds of people to throw
at the problem.

Mike


>
> ~ Gijs

[Lemon Juice]

On 2015-10-20 20:04, Jorge Villalobos wrote:

> The reason it will need manual review every time has to do with those
> coding practices. Some of them can be flagged so they don't come up in
> future reviews, but others can't, especially if they're widespread.
> Having said that, an add-on of that size and complexity is likely to
> bring up these flags every time it's submitted, yes. I don't think that
> completely whitelisting the add-on is an appropriate solution, though.

Jorge, but in this process you (and Mozilla) are beginning to lose track
of the main motive behind the signing process, which is to prevent
malicious add-ons from being side loaded into Fx. Do you think Zotero
will release a malicious version of their add-on and someone will try to
side-load it with an installer of another program? Sure, a possible
scenario but very unlikely. Who will benefit from the constant scanning
of every Zotero release by the reviewers and explaining why some code
pieces are safe and necessary by the authors? Because these releases are
very frequent it's a whole lot of added work for both the AMO reviewers
and the Zotero programmers - and tell us honestly - who will benefit
from this all? The benefit is next to zero while the difficulties in for
the developers are enormous. People will spend lots of man hours doing
work that no one really needs and only puts obstacles. I think it's time
to review the whole mechanism.

Just whitelist add-on IDs and allow the devs to publish versions at
their own pace. The editors may (and should) still review the add-ons
but not delay the process in cases where this is really detrimental.

[Gijs Kruitbosch]

On 20/10/2015 21:15, Dan Stillman wrote:
> On 10/20/15 2:32 PM, Gijs Kruitbosch wrote:
>> Or, you know, you leave in code with comments that say something like
>> "AMO Reviewer: This code is here but is never run when it's used by
>> Firefox", and presumably the reviewers then just have to take your
>> word for it, and not think too hard about how the vulnerable code
>> could perhaps still be used by an attacker (even if it's not normally
>> run inside Zotero).***
>>
>> Why don't you just remove those files / that code? Why is it even in
>> the Firefox add-on?
>
> Because Zotero shares large sections of code between the Zotero for
> Firefox, Zotero Standalone, and several browser extensions, and
> maintaining totally separate versions would be difficult and error-prone.

If the file is unused, just don't include it in the add-on. Not sure why
that would be difficult. In any case, it's in a subdir called "xpcom" so
it's also not clear where that'd be used if not in the firefox add-on...

> For this example, if you look further up you'll see that this is
> actually the example that's straight from MDN, using
> document.implementation.createHTMLDocument("") and .innerHTML to parse —
> but not load — HTML when DOMParser isn't available.

The link the comment gives is outdated (that is, I can't find a snippet
like that on the DOMParser page). My best guess for a source is:

https://developer.mozilla.org/en-US/Add-ons/Code_snippets/HTML_to_DOM#Parsing_Complete_HTML_to_DOM

which doesn't make the safety guarantees you mention.

It's also not clear from the surrounding code where the content comes
from, which makes a big difference for how safe this is/isn't. Assigning
to innerHTML with unsanitized content is an "unsafe practice", yes. If
all you're doing is loading a DOM from disk (say), and you have chrome
privileges, I don't really know why you need a fallback for DOMParser
anyway. When wouldn't it be available?

Lots of "the reviewer has to think a little bit" adds up, and it's
certainly not fair to say that it's in any way "obvious" this code is
harmless.


I don't really follow your discussion about "code quality". The reply
you keep basing this on specifically called out "There's lots of
software out there that I wouldn't necessarily label as malware in
itself, but violates our add-on guidelines"

That has little to do with "code quality" and everything to do with the
"no surprises" policy and such. Doesn't seem related to setTimeout and
the other things you called out.

~ Gijs

[Jorge Villalobos]

On 10/20/15 3:34 PM, Lemon Juice wrote:
> On 2015-10-20 20:04, Jorge Villalobos wrote:
>

>> The reason it will need manual review every time has to do with those
>> coding practices. Some of them can be flagged so they don't come up in
>> future reviews, but others can't, especially if they're widespread.
>> Having said that, an add-on of that size and complexity is likely to
>> bring up these flags every time it's submitted, yes. I don't think that
>> completely whitelisting the add-on is an appropriate solution, though.
>

> Jorge, but in this process you (and Mozilla) are beginning to lose
> track of the main motive behind the signing process, which is to
> prevent malicious add-ons from being side loaded into Fx. Do you think
> Zotero will release a malicious version of their add-on and someone
> will try to side-load it with an installer of another program? Sure, a
> possible scenario but very unlikely.

It's unlikely, yes. However, not being to verify, for example, the
origin of JS or HTML strings that are being evaluated in the code of an
add-on means there are many risks being overlooked. One is the
possibility that there's malicious code in the add-on, which isn't so
far-fetched for a very large project with many developers. Another one
is that some of that code being evaluated comes from outside sources
like APIs or even shared local files that could be intercepted.
Depending on how that code is evaluated, it could lead to privilege
escalations that could put all users at risk. That the add-on is very
respected and widely-used makes this risk higher, not smaller.

Now, there *are* ways to change this code, at least in the majority of
instances, so that it doesn't pose that risk. Which is what we're asking
to be changed. It's clear that changing so much code is not practical in
the short term, which is why we told the developers it was okay to make
these changes gradually. I know it's still a significant effort, but
it's something that *will* save them review time in the future.

> Who will benefit from the constant scanning of every Zotero release by
> the reviewers and explaining why some code pieces are safe and
> necessary by the authors? Because these releases are very frequent
> it's a whole lot of added work for both the AMO reviewers and the
> Zotero programmers - and tell us honestly - who will benefit from this
> all? The benefit is next to zero while the difficulties in for the
> developers are enormous. People will spend lots of man hours doing
> work that no one really needs and only puts obstacles. I think it's
> time to review the whole mechanism.

Since the flags will continue to be there, we will probably need to
re-evaluate them. And this has to do with the fact that the main problem
with these flags is that the origin of their inputs may be far removed
from where they are used. In the cases where it's straightforward that
there's no problem and there's still a flag, we can remove it for
followup reviews. By allowing the ones that aren't as clear, we are
giving the developer some level of trust, but we will need to revisit
those assumptions to try to mitigate some of the risk.

> Just whitelist add-on IDs and allow the devs to publish versions at
> their own pace. The editors may (and should) still review the add-ons
> but not delay the process in cases where this is really detrimental.

We tried whitelisting on AMO before, and it was an absolute failure. It
leads to code getting significantly worse over time because there's no
external party reviewing it. It took months to get all the previously
"trusted" add-ons back on track, including several that had exploitable
security holes.

Jorge

[Emiliano Heyns]

On Tue, Oct 20, 2015 at 11:59 PM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:

>
>> Because Zotero shares large sections of code between the Zotero for
>> Firefox, Zotero Standalone, and several browser extensions, and
>> maintaining totally separate versions would be difficult and error-prone.
>>
>
> If the file is unused, just don't include it in the add-on. Not sure why
> that would be difficult. In any case, it's in a subdir called "xpcom" so
> it's also not clear where that'd be used if not in the firefox add-on...
>

That *piece* of code is not used. The whole is.

>
> For this example, if you look further up you'll see that this is
>> actually the example that's straight from MDN, using
>> document.implementation.createHTMLDocument("") and .innerHTML to parse —
>> but not load — HTML when DOMParser isn't available.
>>
>
> The link the comment gives is outdated (that is, I can't find a snippet
> like that on the DOMParser page). My best guess for a source is:
>
>
> https://developer.mozilla.org/en-US/Add-ons/Code_snippets/HTML_to_DOM#Parsing_Complete_HTML_to_DOM
>
> which doesn't make the safety guarantees you mention.
>

I think Dan should be safe in his assumption that if sample code is given
on the MDN site, Mozilla deems it OK to use.

[Dan Stillman]

On 10/20/15 5:59 PM, Gijs Kruitbosch wrote:
> On 20/10/2015 21:15, Dan Stillman wrote:

>> On 10/20/15 2:32 PM, Gijs Kruitbosch wrote:
>>> Or, you know, you leave in code with comments that say something like
>>> "AMO Reviewer: This code is here but is never run when it's used by
>>> Firefox", and presumably the reviewers then just have to take your
>>> word for it, and not think too hard about how the vulnerable code
>>> could perhaps still be used by an attacker (even if it's not normally
>>> run inside Zotero).***
>>>
>>> Why don't you just remove those files / that code? Why is it even in
>>> the Firefox add-on?
>>
>> Because Zotero shares large sections of code between the Zotero for
>> Firefox, Zotero Standalone, and several browser extensions, and
>> maintaining totally separate versions would be difficult and
>> error-prone.
>

> If the file is unused, just don't include it in the add-on. Not sure
> why that would be difficult. In any case, it's in a subdir called
> "xpcom" so it's also not clear where that'd be used if not in the
> firefox add-on...

I didn't say the file is unused — I said this is shared code. That
conditional block doesn't get run when DOMParser is available, so it
doesn't get run in Firefox.

>> For this example, if you look further up you'll see that this is
>> actually the example that's straight from MDN, using
>> document.implementation.createHTMLDocument("") and .innerHTML to parse —
>> but not load — HTML when DOMParser isn't available.
>

> The link the comment gives is outdated (that is, I can't find a
> snippet like that on the DOMParser page).

https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

"DOMParser HTML extension for other browsers"

var doc = document.implementation.createHTMLDocument("");
[...]
doc.body.innerHTML = markup;

You're welcome to try to get JavaScript to execute from the above code.

> It's also not clear from the surrounding code where the content comes
> from, which makes a big difference for how safe this is/isn't.
> Assigning to innerHTML with unsanitized content is an "unsafe
> practice", yes.

No, it's not, if it's just building a DOM and the document isn't
actually loaded.

> If all you're doing is loading a DOM from disk (say), and you have
> chrome privileges, I don't really know why you need a fallback for
> DOMParser anyway. When wouldn't it be available?

In other browsers, as I've said.

> Lots of "the reviewer has to think a little bit" adds up, and it's
> certainly not fair to say that it's in any way "obvious" this code is
> harmless.

1) The code is from MDN. 2) It's safe, as far as we know. 3) We didn't
ask for it to be reviewed. This shouldn't be our problem.

> I don't really follow your discussion about "code quality". The reply
> you keep basing this on specifically called out "There's lots of
> software out there that I wouldn't necessarily label as malware in
> itself, but violates our add-on guidelines"
>
> That has little to do with "code quality" and everything to do with
> the "no surprises" policy and such. Doesn't seem related to setTimeout
> and the other things you called out.

Huh? As I and others have said repeatedly, every single argument that's
come out of Mozilla over the last 1.5 years has cited malware and
malicious developers as the sole reason for this change. It wasn't until
Zotero — which obviously isn't malware — was rejected for things like,
yes, setTimeout() usage that anyone started claiming this was about
anything else. Jorge said a few hours ago that this was indeed about
"code quality".

I also have no idea what "no surprises" "and such" policy you're talking
about. The only mentions the add-on guidelines or the review policy make
of surprises are in regards to not deceiving users. Are we now making up
even more, vaguer policies that unlisted extensions are supposed to
abide by in order to get approved? Are we now not supposed to surprise
AMO editors by writing functional, safe code that they don't understand?

[Dan Stillman]

On 10/20/15 6:18 PM, Jorge Villalobos wrote:
> On 10/20/15 3:34 PM, Lemon Juice wrote:
>> On 2015-10-20 20:04, Jorge Villalobos wrote:
>>

>>> The reason it will need manual review every time has to do with those
>>> coding practices. Some of them can be flagged so they don't come up in
>>> future reviews, but others can't, especially if they're widespread.
>>> Having said that, an add-on of that size and complexity is likely to
>>> bring up these flags every time it's submitted, yes. I don't think that
>>> completely whitelisting the add-on is an appropriate solution, though.

>> Jorge, but in this process you (and Mozilla) are beginning to lose
>> track of the main motive behind the signing process, which is to
>> prevent malicious add-ons from being side loaded into Fx. Do you think
>> Zotero will release a malicious version of their add-on and someone
>> will try to side-load it with an installer of another program? Sure, a
>> possible scenario but very unlikely.
> It's unlikely, yes. However, not being to verify, for example, the
> origin of JS or HTML strings that are being evaluated in the code of an
> add-on means there are many risks being overlooked. One is the
> possibility that there's malicious code in the add-on, which isn't so
> far-fetched for a very large project with many developers.

Great, so now the justification for extension signing has gone from
guarding against malicious side-loaded add-ons to guarding against
projects that are so successful their developers won't notice malicious
code being inserted by third-parties.

Jorge, what's more likely, that the core Zotero developers — who review
every line that goes into Zotero, and have a vested interest in keeping
Zotero users safe — will find and catch malicious code inserted by
hypothetical evil contributors, or that an AMO editor who has no idea
how our code works will find malicious code that we overlooked? You're
grasping at straws here.

> Another one
> is that some of that code being evaluated comes from outside sources
> like APIs or even shared local files that could be intercepted.
> Depending on how that code is evaluated, it could lead to privilege
> escalations that could put all users at risk. That the add-on is very
> respected and widely-used makes this risk higher, not smaller.

And we're the ones who are responsible for knowing when that might be
the case, because we're responsible to our users and for the good name
of Zotero. Other than the dumb things that the validator catches, you
have no idea what's going on in the rest of our code base and can't
possibly be responsible for it. Nor has anyone asked you to be — that's
why they're downloading extensions from our site. This isn't the problem
you set out to solve, and for good reason.

> Now, there *are* ways to change this code, at least in the majority of
> instances, so that it doesn't pose that risk. Which is what we're asking
> to be changed. It's clear that changing so much code is not practical in
> the short term, which is why we told the developers it was okay to make
> these changes gradually. I know it's still a significant effort, but
> it's something that *will* save them review time in the future.

That's not what you said a few hours ago. You said that Zotero is so
large and complex that we'll likely never be automatically validated.

And as I said, saving us review time doesn't help, unless that review
time is measured in minutes, including on the nights and weekends when
we frequently put out new versions. The point isn't that we don't like
waiting days for updates, though obviously we don't — it's that we're
not able to put out important fixes right away if every release has to
be manually reviewed. We're not going to jeopardize Zotero's reputation
by being unable to put out updates when things are broken, and that
means we have no choice but to discontinue our full-featured Firefox
extension. There's nothing we can do on our end to change that.

>> Who will benefit from the constant scanning of every Zotero release by
>> the reviewers and explaining why some code pieces are safe and
>> necessary by the authors? Because these releases are very frequent
>> it's a whole lot of added work for both the AMO reviewers and the
>> Zotero programmers - and tell us honestly - who will benefit from this
>> all? The benefit is next to zero while the difficulties in for the
>> developers are enormous. People will spend lots of man hours doing
>> work that no one really needs and only puts obstacles. I think it's
>> time to review the whole mechanism.
> Since the flags will continue to be there, we will probably need to
> re-evaluate them. And this has to do with the fact that the main problem
> with these flags is that the origin of their inputs may be far removed
> from where they are used. In the cases where it's straightforward that
> there's no problem and there's still a flag, we can remove it for
> followup reviews. By allowing the ones that aren't as clear, we are
> giving the developer some level of trust, but we will need to revisit
> those assumptions to try to mitigate some of the risk.

Again, that's our job, not yours, and we're the only ones who can do it
effectively.

>> Just whitelist add-on IDs and allow the devs to publish versions at
>> their own pace. The editors may (and should) still review the add-ons
>> but not delay the process in cases where this is really detrimental.
> We tried whitelisting on AMO before, and it was an absolute failure. It
> leads to code getting significantly worse over time because there's no
> external party reviewing it. It took months to get all the previously
> "trusted" add-ons back on track, including several that had exploitable
> security holes.

You never had unlisted add-ons before, so this doesn't make any sense.
You haven't been reviewing Zotero for years, so Zotero has in effect
been whitelisted. Are you suggesting that, in this time, Zotero has been
a failure? Has it become a threat to Firefox users? (Apparently not,
since you accepted an essentially unchanged version a month ago.) If it
hasn't, then that undermines your whole argument. The notion that code
that's not reviewed by AMO editors somehow inherently gets worse over
time is laughably absurd, not to mention offensive to responsible
developers of unlisted add-ons.

In any case, if you sign extensions — which most of us aren't objecting
to — there's nothing preventing you from reviewing extensions after the
fact while still allowing legitimate developers to release timely
updates to their users. If you find genuine exploitable holes, any
responsible developer will fix them and be grateful for the extra eyes —
and if they don't then they can lose whitelist privileges. How is that
possibly not sufficient?

[Mike Connor]

On 20 October 2015 at 16:33, Dan Stillman <dsti...@zotero.org> wrote:

>
> You never had unlisted add-ons before, so this doesn't make any sense. You
> haven't been reviewing Zotero for years, so Zotero has in effect been
> whitelisted. Are you suggesting that, in this time, Zotero has been a
> failure? Has it become a threat to Firefox users? (Apparently not, since
> you accepted an essentially unchanged version a month ago.) If it hasn't,
> then that undermines your whole argument. The notion that code that's not
> reviewed by AMO editors somehow inherently gets worse over time is
> laughably absurd, not to mention offensive to responsible developers of
> unlisted add-ons.
>

AMO had a set of add-ons that were whitelisted, which meant those add-ons
were auto-approved and hosted on AMO. Not unlisted, but unreviewed by
AMO. The program was ended because the majority of developers failed to
maintain appropriately high standards, and users quite often blamed Mozilla
for problems they couldn't isolate to a bad add-on. Introducing product
quality issues for developer convenience is a pretty poor tradeoff, overall.

For every developer who's building good add-ons, there's probably 2-3 who
don't have the knowledge or desire to maintain code to our standards.
That's a ballpark estimate, but ultimately we've spent a ton of time
helping people get up to speed in the last six months. With professionally
written add-ons, that ratio was even worse. At least 2-3 major add-ons by
install base required months of rewrites.

So... no, I don't think it's laughably absurd, or offensive. It's the
facts. Zotero being an exemplary citizen doesn't change the reality of our
ecosystem. And hard cases make bad law.

> In any case, if you sign extensions — which most of us aren't objecting to
> — there's nothing preventing you from reviewing extensions after the fact
> while still allowing legitimate developers to release timely updates to
> their users. If you find genuine exploitable holes, any responsible
> developer will fix them and be grateful for the extra eyes — and if they
> don't then they can lose whitelist privileges. How is that possibly not
> sufficient?

Closing the barn door after the horse has bolted is a pretty poor horse
retention strategy. Opening the door only when the horse isn't going to
bolt is a lot better. Less convenient for sure, but it's a tradeoff.
(I'll note that you made no mention of the potential impact on users.)

I missed the origin of this thread, but overall it's pretty much summed up
as "this is stupid, and your reasons are obviously wrong" vs. "what we've
seen in practice makes us unwilling to repeat past issues with
whitelisting." I can't imagine a positive resolution coming out of this
thread, so I'd encourage everyone to take a deep breath and take a step
back.

I'll also add that accusing people of lying or otherwise acting in bad
faith is a surefire way to block forward progress, so I'd encourage people
to try to assume good faith. I don't think anyone here is trying for
anything other than what they think is best for their users.

-- Mike

[Dan Stillman]

On 10/20/15 8:26 PM, Mike Connor wrote:
> On 20 October 2015 at 16:33, Dan Stillman <dsti...@zotero.org

> <mailto:dsti...@zotero.org>> wrote:
>
>
> You never had unlisted add-ons before, so this doesn't make any
> sense. You haven't been reviewing Zotero for years, so Zotero has
> in effect been whitelisted. Are you suggesting that, in this time,
> Zotero has been a failure? Has it become a threat to Firefox
> users? (Apparently not, since you accepted an essentially
> unchanged version a month ago.) If it hasn't, then that undermines
> your whole argument. The notion that code that's not reviewed by
> AMO editors somehow inherently gets worse over time is laughably
> absurd, not to mention offensive to responsible developers of
> unlisted add-ons.
>
>
> AMO had a set of add-ons that were whitelisted, which meant those
> add-ons were auto-approved and hosted on AMO. Not unlisted, but
> unreviewed by AMO. The program was ended because the majority of
> developers failed to maintain appropriately high standards, and users
> quite often blamed Mozilla for problems they couldn't isolate to a bad
> add-on.

I understand that, but I still don't see how it's relevant. We're not
talking about extensions on AMO. We're talking about Zotero and other
extensions that have been unhosted for years without problems. People
have downloaded them directly from websites, they've trusted the
developers, and the developers have honored their trust. Nothing has
changed to affect the quality or security of those add-ons. So why is
Mozilla insisting on punishing Zotero out of existence for the past
behavior of a few hosted add-ons when none of the factors that have
guided Zotero's development up until now have changed?

> Introducing product quality issues for developer convenience is a
> pretty poor tradeoff, overall.

This isn't an issue of developer convenience — this is an issue of
Zotero no longer existing as a Firefox extension, because, as I
explained in the original whitelisting thread, we can't be in a
situation where we can't release a critical update to our users
immediately. For most extensions it might not be a big deal if there's a
major bug for a few days. For Zotero it's a huge deal.

> For every developer who's building good add-ons, there's probably 2-3
> who don't have the knowledge or desire to maintain code to our standards.

So don't whitelist those. Save whitelisting for developers who have
demonstrated that they're knowledgeable and responsible and for whom the
normal review process clearly does more harm than good.

> That's a ballpark estimate, but ultimately we've spent a ton of time
> helping people get up to speed in the last six months. With
> professionally written add-ons, that ratio was even worse. At least
> 2-3 major add-ons by install base required months of rewrites.
>
> So... no, I don't think it's laughably absurd, or offensive. It's the
> facts. Zotero being an exemplary citizen doesn't change the reality of
> our ecosystem. And hard cases make bad law.

Again, I'm talking about Zotero and other unhosted add-ons, which
despite not having the magical guiding powers of AMO haven't become
"significantly worse over time", as Jorge claimed invariably happens —
that's what I'm saying is absurd and offensive, because it's
demonstrably untrue. Mozilla distributing extensions from AMO that turn
rogue is Mozilla's problem. It shouldn't be ours.

>
> In any case, if you sign extensions — which most of us aren't
> objecting to — there's nothing preventing you from reviewing
> extensions after the fact while still allowing legitimate
> developers to release timely updates to their users. If you find
> genuine exploitable holes, any responsible developer will fix them
> and be grateful for the extra eyes — and if they don't then they
> can lose whitelist privileges. How is that possibly not sufficient?
>
>
> Closing the barn door after the horse has bolted is a pretty poor
> horse retention strategy. Opening the door only when the horse isn't
> going to bolt is a lot better.

Can we not just agree that Zotero is a horse that probably isn't going
to bolt? Certainly an extension being reviewed is no guarantee that it
won't, since it's easy to bypass the automatic validator, and we could
trivially insert malicious code in Zotero that made it past a review if
we wanted. Whether you like it or not, you still have a system built
largely on trust.

> Less convenient for sure, but it's a tradeoff. (I'll note that you
> made no mention of the potential impact on users.)

Well, I'm most concerned about Zotero's users, who will no longer be
able to use Zotero in Firefox. That seems like a pretty big impact to me.

But yes, I value the continued existence of high-quality extensions for
Firefox over futilely trying to prevent every manner of theoretical harm
that might befall a Firefox user, instead of accepting the reasonable
compromise of going after the side-loaded malware that was the target of
this scheme to begin with.

> I missed the origin of this thread, but overall it's pretty much
> summed up as "this is stupid, and your reasons are obviously wrong"
> vs. "what we've seen in practice makes us unwilling to repeat past
> issues with whitelisting." I can't imagine a positive resolution
> coming out of this thread, so I'd encourage everyone to take a deep
> breath and take a step back.

The origin of this thread was my whitelisting thread, where I said that
we'll have to discontinue Zotero (or somehow convince all our users to
install the unbranded build) come Firefox 43 if we can no longer release
immediate updates to our users. So I'm afraid we don't have the luxury
of taking a step back.

> I'll also add that accusing people of lying or otherwise acting in bad
> faith is a surefire way to block forward progress, so I'd encourage
> people to try to assume good faith. I don't think anyone here is
> trying for anything other than what they think is best for their users.

I believe that Mozilla folks are trying to do what they think is best
for their users. It's the complete disregard for our users that I have a
problem with. Beyond that, I don't appreciate the repeated, baseless
accusations today that Zotero has security issues or "insecure
practices" in an attempt to defend this broken system.

Finally, it's frustrating that no one from Mozilla will even acknowledge
that the entire premise of this scheme has changed drastically from what
was sold to the community. Just suddenly claiming that there are a range
of other concerns besides malware doesn't change the record we have of
the last 1.5 years. It's hard to make forward progress when we can't
even acknowledge the documented past.

- Dan

[Emiliano Heyns]

On Wednesday, October 21, 2015 at 5:58:18 AM UTC+2, Dan Stillman wrote:

> > Introducing product quality issues for developer convenience is a
> > pretty poor tradeoff, overall.
>

> This isn't an issue of developer convenience -- this is an issue of

> Zotero no longer existing as a Firefox extension, because, as I
> explained in the original whitelisting thread, we can't be in a
> situation where we can't release a critical update to our users
> immediately. For most extensions it might not be a big deal if there's a
> major bug for a few days. For Zotero it's a huge deal.

Besides that -- the idea that this trade being made at all is beyond ridiculous.

I have submitted pull requests to Zotero. I happen to know the codebase very well. It was *not* easy to get a pull request into Zotero. The incoming code is being looked at in much more detail, for code style and *actual impact on the code* to a fairly annoying degree I can tell you. The idea that the Zotero folks are going to let one slip by just tells me that the utterer hasn't actually tried.

And people use the term "product quality" like they know what they're talking about. You know what affects product quality? Not being able to address a potential non-accessibility or even data loss bug because Zotero must wait until a reviewer who has *no clue* about how Zotero works and what does or does not affect its security assesses some generic coding practices. And the fallout of such a problem will land on Zotero, *and on its users*, who will have to deal with with having their work stalled while the reviewer gets educated about Zotero, *again*. And the review process will catch exactly zero of these problems, extrapolating from the amount of insight that has been shown so far.

Security includes more than "introduction of malicious code". The review process seems to be geared towards extensions that add fluffy-bunny fun to Firefox but where non-accessibility (of the program or the data) is a minor inconvenience a user might or might not notice. This is *not* the case for Zotero and most of its extensions. The review process poses a live security risk to my users.

[Gijs Kruitbosch]

MDN is a wiki, everyone can change it. It is not some kind of
authoritative source of secure, complete and correct code, and as has
been noted several times now, a lot depends on the source of the data
and the context (chrome, content, cross-site or not) in which it is
evaluated.

The example there actually uses XMLHttpRequest. If that's done over SSL
and all you're doing is loading a normal HTML document into a visible
content-type iframe, fine. If you're loading over HTTP and inserting
into a chrome document, not so much.

For simplicity's sake, a lot of code on MDN isn't "safe" or lacks proper
error handling (that example, for instance, doesn't at all deal with the
XHR failing) - it illustrates concepts, not "here's a complete solution".

~ Gijs

[Gervase Markham]

On 21/10/15 01:26, Mike Connor wrote:
> AMO had a set of add-ons that were whitelisted, which meant those add-ons
> were auto-approved and hosted on AMO. Not unlisted, but unreviewed by
> AMO. The program was ended because the majority of developers failed to
> maintain appropriately high standards, and users quite often blamed Mozilla
> for problems they couldn't isolate to a bad add-on.

Sounds like we had a bad system for choosing who was on the whitelist,
or for deciding when people came off it. That doesn't mean a whitelist
or a trusted developer program is a bad idea.

> For every developer who's building good add-ons, there's probably 2-3 who
> don't have the knowledge or desire to maintain code to our standards.
> That's a ballpark estimate, but ultimately we've spent a ton of time
> helping people get up to speed in the last six months. With professionally
> written add-ons, that ratio was even worse. At least 2-3 major add-ons by
> install base required months of rewrites.
>
> So... no, I don't think it's laughably absurd, or offensive. It's the
> facts. Zotero being an exemplary citizen doesn't change the reality of our
> ecosystem. And hard cases make bad law.

Can we please think about the actual threat model here? The problem we
are guarding against is malicious extensions. How is that problem made
any worse by giving the Zotero developers the ability to sign their own
builds?

* Someone might steal their signing key
-- so, as long as the list of trusted developers is manageable, we
can just stop trusting it; we can have requirements for key storage,
and this wouldn't be a frequent occurrence. The incentives are
aligned for developers to take good care of their keys.

* Someone might sneak malicious code into Zotero
-- and this wouldn't be spotted by the Zotero developers, but would
by an AMO reviewer? Assuming we trust them, given their track record
(and if we don't, we might as well just come out and say it) then
they are again incentivised not to let this happen.

* Someone might put a security hole in Zotero
-- you've changed threat models. But also: this could be true of any
extension, signed or not. We don't offer full security auditing as
part of the signing process.

I don't get why we are being so insistent on sticking to this, in the
face of what seem like reasonable and rational arguments, that we would
rather maintain our position and have Zotero leave the Firefox ecosystem
than think a bit more creatively about how we can support what they are
doing.

Zotero used to be a major differentiating feature for Firefox. I believe
it's now available in other places, but I'm sure people still use
Firefox because they wanted to use Zotero. Why are we treating these
people like the enemy?

Not all add-ons are the same. There are a few of high popularity, and a
few of great complexity. I see no reason why special arrangements should
not be put in place to support such extensions. We don't have to offer
the same options to everyone.

Gerv

[Gijs Kruitbosch]

On 21/10/2015 14:30, Gervase Markham wrote:
> On 21/10/15 01:26, Mike Connor wrote:
>> AMO had a set of add-ons that were whitelisted, which meant those add-ons
>> were auto-approved and hosted on AMO. Not unlisted, but unreviewed by
>> AMO. The program was ended because the majority of developers failed to
>> maintain appropriately high standards, and users quite often blamed Mozilla
>> for problems they couldn't isolate to a bad add-on.
>
> Sounds like we had a bad system for choosing who was on the whitelist,
> or for deciding when people came off it. That doesn't mean a whitelist
> or a trusted developer program is a bad idea.

> Not all add-ons are the same. There are a few of high popularity, and a
> few of great complexity. I see no reason why special arrangements should
> not be put in place to support such extensions. We don't have to offer
> the same options to everyone.

For sure (to both of these), but we do need a sane model for how and who
to whitelist. Nobody has proposed something as yet, despite repeated
requests to flesh out the suggestion. All we've heard so far is "lack of
a whitelist system will doom Firefox", and "clearly your previous
whitelist was dumb", and "we're not interested in thinking along about
how to run a successful whitelist, we just want to be on it".

The only serious suggestion has been "charge money to be on it", which
I'm fairly sure we don't want to do.

That's no way to have a productive discussion and has nothing to do with
unwillingness to consider a whitelist as such.

Running a whitelist isn't trivial. It'd be nice if we had an actual
serious discussion about how people claim it *would* work. You, for
instance, seem to be thinking we'd let other people sign things, whereas
I was thinking we would just whitelist particular add-on IDs in the AMO
upload system and allow uploads for them to not be blocked by reviews.
That's the technical side, and the financial side has also been
discussed - but the hot potato of "what policy/rules would you want to
should be on the whitelist and why" is being avoided by everyone. :-\


How about add-ons with all of:
- more than 100,000 active daily users
- at least 1 year of history without serious review issues as indicated
by the AMO reviewer team
- rapid releases (figure out some way to measure this, vis-a-vis review
latency)
- source code that's publicly available elsewhere than just via the AMO
viewer itself, and a public issue tracker (bugzilla, github issues,
whatever)
- no AMO policy violations

can apply to be on it, with the caveat that the whitelist isn't a
"right" and the AMO team can remove add-ons that start violating any of
these, even if they weren't when they were "admitted" to the whitelist.

I don't remember offhand what the previous system's requirements were,
and how this compares, but maybe having a concrete proposal will help
foster more discussion.

~ Gijs

[Kaply Consulting]

On 10/21/15 10:49 AM, Gijs Kruitbosch wrote:
>
>
>
> How about add-ons with all of:
> - more than 100,000 active daily users
> - at least 1 year of history without serious review issues as
> indicated by the AMO reviewer team
> - rapid releases (figure out some way to measure this, vis-a-vis
> review latency)
> - source code that's publicly available elsewhere than just via the
> AMO viewer itself, and a public issue tracker (bugzilla, github
> issues, whatever)
> - no AMO policy violations
>
> can apply to be on it, with the caveat that the whitelist isn't a
> "right" and the AMO team can remove add-ons that start violating any
> of these, even if they weren't when they were "admitted" to the
> whitelist.
>
> I don't remember offhand what the previous system's requirements were,
> and how this compares, but maybe having a concrete proposal will help
> foster more discussion.

This is a great start.

I don't think that active daily users should be a valid metric for this
purpose, especially given that you don't even have that data for
unlisted addons.

I think there needs to be some personal accountability for this purpose,
even if it's something as simple as identify verification via a copy of
an ID or something like that.
>
> ~ Gijs
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience

[Kaply Consulting]

I think the big disconnect in all this (and what is being pointed out)
is that there was an expectation that unlisted add-ons wouldn't have to
go through the same pain as AMO reviews.

Let's be honest - if the AMO review process was less painful, there
wouldn't be as much of a need for unlisted add-ons (except for special
situations).

But what's happening is that some unlisted add-ons seem to be held to
exactly the same standard as AMO and that's causing a great deal of
confusion.

What needs to be made clear here is exactly what the policy is.

Is there any difference between the review criteria for an unlisted
add-on and for a listed add-on? What can an unlisted add-on do that a
listed add-on can't?

Mike Kaply

[Gervase Markham]

On 21/10/15 17:53, Kaply Consulting wrote:
> I don't think that active daily users should be a valid metric for this
> purpose, especially given that you don't even have that data for
> unlisted addons.

Do we have any metrics at all on the popularity of unlisted addons?

> I think there needs to be some personal accountability for this purpose,
> even if it's something as simple as identify verification via a copy of
> an ID or something like that.

You could add that, I guess, but if this becomes an important metric
we've already lost.

The team have, AIUI, considered and (correctly) rejected a code-signing
mechanism where you just give a random CA your ID, get a cert, and start
using it. Because getting new certs is too easy.

So I'd say we need a system where Mozilla issues certs, issues them to a
handful of top developers with key requirements (absolute max, say, 50
or 100), and does so based on a track record of competence and having an
addon which has unusual requirements and is popular. Thing is, how to
measure that stuff.

Gerv

[Mike Connor]

On 21 October 2015 at 06:30, Gervase Markham <ge...@mozilla.org> wrote:

> On 21/10/15 01:26, Mike Connor wrote:

> > AMO had a set of add-ons that were whitelisted, which meant those add-ons
> > were auto-approved and hosted on AMO. Not unlisted, but unreviewed by
> > AMO. The program was ended because the majority of developers failed to
> > maintain appropriately high standards, and users quite often blamed
> Mozilla
> > for problems they couldn't isolate to a bad add-on.
>

> Sounds like we had a bad system for choosing who was on the whitelist,
> or for deciding when people came off it. That doesn't mean a whitelist
> or a trusted developer program is a bad idea.

Sure, not necessarily. But it points to the obvious failure states, and
raises the bar for a similar program, in the sense that we need to find a
way to be confident that we won't repeat the same mistakes. Gijs' ideas
are a decent start for an objective measure.

> > For every developer who's building good add-ons, there's probably 2-3 who
> > don't have the knowledge or desire to maintain code to our standards.
> > That's a ballpark estimate, but ultimately we've spent a ton of time
> > helping people get up to speed in the last six months. With
> professionally
> > written add-ons, that ratio was even worse. At least 2-3 major add-ons
> by
> > install base required months of rewrites.
> >
> > So... no, I don't think it's laughably absurd, or offensive. It's the
> > facts. Zotero being an exemplary citizen doesn't change the reality of
> our
> > ecosystem. And hard cases make bad law.
>

> Can we please think about the actual threat model here? The problem we
> are guarding against is malicious extensions. How is that problem made
> any worse by giving the Zotero developers the ability to sign their own
> builds?
>

I think malware was a tipping point, and the reason why we finally moved to
a system with centralized control. However, we've also had strong
standards, violation of which was always subject to blocklisting, and
centralization allows us to enforce those more consistently, rather than
relying on post-hoc detection.

> * Someone might steal their signing key
> -- so, as long as the list of trusted developers is manageable, we
> can just stop trusting it; we can have requirements for key storage,
> and this wouldn't be a frequent occurrence. The incentives are
> aligned for developers to take good care of their keys.
>

Keys get stolen and abused all too frequently, often without detection. In
fact, a developer would have a strong disincentive to self-report, because
all add-ons signed with a revoked key would be blocked immediately. I
certainly can't think of a case where a third party has self-reported
security issues and asked for us to block those versions. Especially for
add-ons seeking certification for sideloading (i.e. anything bundled with
native software will want this), this type of cert compromise would
absolutely be used for abuse. Why take that risk?

On top of that, it's all but certain that a compromised add-on would block
updates and cert revocation. It's a one-way street in a failure state. A
cert compromise would be a serious problem until someone catches it. This
just isn't the right way to solve the problem.

* Someone might sneak malicious code into Zotero
> -- and this wouldn't be spotted by the Zotero developers, but would
> by an AMO reviewer? Assuming we trust them, given their track record
> (and if we don't, we might as well just come out and say it) then
> they are again incentivised not to let this happen.
>

Without naming names, if you go back four years we had a major,
well-trusted add-on start injecting ads. You probably remember those
threads. That got fixed, but it's an example of how even people we would
otherwise trust deeply may make an error in judgement. That's less likely
to happen with multiple people involved, but we can't guarantee that the
Zotero team of today will be the same team in a year or two.

> * Someone might put a security hole in Zotero
> -- you've changed threat models. But also: this could be true of any
> extension, signed or not. We don't offer full security auditing as
> part of the signing process.
>
> I don't get why we are being so insistent on sticking to this, in the
> face of what seem like reasonable and rational arguments, that we would
> rather maintain our position and have Zotero leave the Firefox ecosystem
> than think a bit more creatively about how we can support what they are
> doing.
>

Like I said, hard cases make bad law.

> Zotero used to be a major differentiating feature for Firefox. I believe
> it's now available in other places, but I'm sure people still use
> Firefox because they wanted to use Zotero. Why are we treating these
> people like the enemy?
>

Let's avoid inflammatory statements here, please. Everything is a
tradeoff, and it may be possible.

> Not all add-ons are the same. There are a few of high popularity, and a
> few of great complexity. I see no reason why special arrangements should
> not be put in place to support such extensions. We don't have to offer
> the same options to everyone.
>

We don't, but without some highly objective standards in place it will
cause just as much (if not more) developer backlash.

On a personal level, I can't attest to Zotero (or really any organization)
being a trustable organization. How do we do this, in a fair and balanced
way? If there's a strong policy proposal put forth, I think we'd consider
it, but I don't have any ideas that don't potentially put our users at
significantly greater risk.

On 21 October 2015 at 06:30, Gervase Markham <ge...@mozilla.org> wrote:

> On 21/10/15 01:26, Mike Connor wrote:

> > AMO had a set of add-ons that were whitelisted, which meant those add-ons
> > were auto-approved and hosted on AMO. Not unlisted, but unreviewed by
> > AMO. The program was ended because the majority of developers failed to
> > maintain appropriately high standards, and users quite often blamed
> Mozilla
> > for problems they couldn't isolate to a bad add-on.
>

> Sounds like we had a bad system for choosing who was on the whitelist,
> or for deciding when people came off it. That doesn't mean a whitelist
> or a trusted developer program is a bad idea.
>

> > For every developer who's building good add-ons, there's probably 2-3 who
> > don't have the knowledge or desire to maintain code to our standards.
> > That's a ballpark estimate, but ultimately we've spent a ton of time
> > helping people get up to speed in the last six months. With
> professionally
> > written add-ons, that ratio was even worse. At least 2-3 major add-ons
> by
> > install base required months of rewrites.
> >
> > So... no, I don't think it's laughably absurd, or offensive. It's the
> > facts. Zotero being an exemplary citizen doesn't change the reality of
> our
> > ecosystem. And hard cases make bad law.
>

> Not all add-ons are the same. There are a few of high popularity, and a
> few of great complexity. I see no reason why special arrangements should
> not be put in place to support such extensions. We don't have to offer
> the same options to everyone.
>

> Gerv
>
>

[Emiliano Heyns]

On Wed, Oct 21, 2015 at 8:25 PM, Mike Connor wrote:

>
> Like I said, hard cases make bad law.
>

You did say that. Here's another tidbit: A witty saying proves nothing. If
you're very fond of legal analogies, then a) look up the controversy around
that statement (you treat it like it's a well-accepted truism in law -- it
is not, and it's opposite has plenty support), and b) read some Dworkin and
you'll perhaps understand why not all of us deem the current proposal
well-balanced.

> > Zotero used to be a major differentiating feature for Firefox. I believe
> > it's now available in other places, but I'm sure people still use
> > Firefox because they wanted to use Zotero. Why are we treating these
> > people like the enemy?
> >
>
> Let's avoid inflammatory statements here, please. Everything is a
> tradeoff, and it may be possible.
>

Yes, it may be, but to call Zotero a security hazard is just as
inflammatory. And Zotero *is* quite explicitly lumped in with the enemy
(expect them to turn any day now!), and their users are asked to "take one
for the team" where they were previously not on that team at all, and may
have no desire to be on that team.

> On a personal level, I can't attest to Zotero (or really any organization)
> being a trustable organization.

Exactly. EXACTLY. And neither can any of the AMO reviewers. But Zotero's
users *can*. So why is a body that by its own admission cannot make a
sensible statement about the trustworthiness of Zotero interjecting itself
in the dialog between Zotero and its users? Because of the general case,
yes. But the so-called "hard cases", even if you go by that creed, still
give judges freedom in applying the law reasonably rather than blithely.
The current proposal is admittedly simple from an application point of
view. Simple does not mean correct, or even fair. Here, another pithy
quote: For every complex problem there is an answer that is clear, simple,
and wrong.

> How do we do this, in a fair and balanced
> way? If there's a strong policy proposal put forth, I think we'd consider
> it, but I don't have any ideas that don't potentially put our users at
> significantly greater risk.

And which does not put the Zotero users at significantly greater risk. Being denied service is also a quality risk, and this problem does not get any kind of acknowledgement at all in the debate.

[Mike Connor]

On 21 October 2015 at 14:00, Emiliano Heyns <emilian...@iris-advies.com>
wrote:

> On Wed, Oct 21, 2015 at 8:25 PM, Mike Connor wrote:
>
> >

> > Like I said, hard cases make bad law.
> >
>

> You did say that. Here's another tidbit: A witty saying proves nothing. If
> you're very fond of legal analogies, then a) look up the controversy around
> that statement (you treat it like it's a well-accepted truism in law -- it
> is not, and it's opposite has plenty support), and b) read some Dworkin and
> you'll perhaps understand why not all of us deem the current proposal
> well-balanced.
>

I'm not treating it as a truism in law, I'm saying it as a shorthand for
"trying to craft a policy based on exceptional cases is generally a bad
idea" rather than getting into the larger controversy. The current plan
isn't well-balanced, it skews hard on erring on the side of caution, and on
the side of protecting users.

> > > Zotero used to be a major differentiating feature for Firefox. I
> believe
> > > it's now available in other places, but I'm sure people still use
> > > Firefox because they wanted to use Zotero. Why are we treating these
> > > people like the enemy?
> > >
> >
> > Let's avoid inflammatory statements here, please. Everything is a
> > tradeoff, and it may be possible.
> >
>

> Yes, it may be, but to call Zotero a security hazard is just as
> inflammatory. And Zotero *is* quite explicitly lumped in with the enemy
> (expect them to turn any day now!), and their users are asked to "take one
> for the team" where they were previously not on that team at all, and may
> have no desire to be on that team.
>

I've said nothing about Zotero, so I'd again ask for people to stop
fuelling that particular fire.

> > On a personal level, I can't attest to Zotero (or really any
> organization)
> > being a trustable organization.
>

> Exactly. EXACTLY. And neither can any of the AMO reviewers. But Zotero's
> users *can*. So why is a body that by its own admission cannot make a
> sensible statement about the trustworthiness of Zotero interjecting itself
> in the dialog between Zotero and its users? Because of the general case,
> yes. But the so-called "hard cases", even if you go by that creed, still
> give judges freedom in applying the law reasonably rather than blithely.
> The current proposal is admittedly simple from an application point of
> view. Simple does not mean correct, or even fair. Here, another pithy
> quote: For every complex problem there is an answer that is clear, simple,
> and wrong.

So what's your solution?

The current model has been abused by lots and lots of bad actors. A huge
proportion of user complaints come from bad add-ons. That's not good for
anyone. How do we distinguish between a good actor and a bad one? How do
we ensure the former don't turn into the latter? I've been shocked on
multiple occasions by the authors who've gone rogue, or even just sold
their add-on listing to rogue actors.

I'm not opposed to a whitelist, but I'm opposed to a weak one that relies
on blind trust and has no major consequences. So we need something better.

> > How do we do this, in a fair and balanced
> > way? If there's a strong policy proposal put forth, I think we'd
> consider
> > it, but I don't have any ideas that don't potentially put our users at
> > significantly greater risk.
>

> And which does not put the Zotero users at significantly greater risk.
> Being denied service is also a quality risk, and this problem does not get
> any kind of acknowledgement at all in the debate.

Let's get to the point: if an add-on gets a 0-day, or just finds a critical
flaw, there should be a way to flag that for urgent approval. In the
absence of a mechanical solution, it's not like the people capable of
escalating things aren't well-known individuals reachable by email. Yes,
that adds a bit of latency, but an early heads up that an urgent submission
is coming is hardly an excessive burden so we can arrange for a quick
turnaround. We've done that for years for AMO-hosted add-ons, it's very
rarely created a significant delay in rolling out a fix to affected users.

-- Mike

[Dan Stillman]

On 10/21/15 7:58 PM, Mike Connor wrote:
> On 21 October 2015 at 14:00, Emiliano Heyns <emilian...@iris-advies.com>
> wrote:
>> On Wed, Oct 21, 2015 at 8:25 PM, Mike Connor wrote:

>>> Like I said, hard cases make bad law.

>> You did say that. Here's another tidbit: A witty saying proves nothing. If
>> you're very fond of legal analogies, then a) look up the controversy around
>> that statement (you treat it like it's a well-accepted truism in law -- it
>> is not, and it's opposite has plenty support), and b) read some Dworkin and
>> you'll perhaps understand why not all of us deem the current proposal
>> well-balanced.
>>
> I'm not treating it as a truism in law, I'm saying it as a shorthand for
> "trying to craft a policy based on exceptional cases is generally a bad
> idea" rather than getting into the larger controversy.

The point is that you're repeating "hard cases make bad law" as if
Mozilla's hands are tied here. Zotero may be an exceptional case, but
Mozilla has the power to make exceptions.

> The current plan
> isn't well-balanced, it skews hard on erring on the side of caution, and on
> the side of protecting users.

The current plan protects absolutely nobody by forcing Zotero to be
discontinued. And it causes permanent harm to the users who rely on
Zotero and have done so for 9 years. The casual disregard with which
you'd wipe out an extension that has been nothing but a highlight of the
Firefox ecosystem is shocking and sad.

>>>> Zotero used to be a major differentiating feature for Firefox. I
>> believe
>>>> it's now available in other places, but I'm sure people still use
>>>> Firefox because they wanted to use Zotero. Why are we treating these
>>>> people like the enemy?
>>>>
>>> Let's avoid inflammatory statements here, please. Everything is a
>>> tradeoff, and it may be possible.
>>>

>> Yes, it may be, but to call Zotero a security hazard is just as
>> inflammatory. And Zotero *is* quite explicitly lumped in with the enemy
>> (expect them to turn any day now!), and their users are asked to "take one
>> for the team" where they were previously not on that team at all, and may
>> have no desire to be on that team.
>>
> I've said nothing about Zotero, so I'd again ask for people to stop
> fuelling that particular fire.

Jorge and Gijs both baselessly accused Zotero of having insecure coding
practices yesterday, Jorge suggested that we might not be responsible
enough to adequately review the code that goes into Zotero and catch
malicious code, and you suggested a few hours ago that in two years time
Zotero might turn rogue. We're not the ones fanning the flames here.

An appropriate, non-inflammatory response would be to say, yes, of
course Zotero — a leading, open-source, non-profit research tool that's
recommended by universities worldwide — is a valued asset to the Firefox
ecosystem that should be allowed to continue development under any
reasonable scheme, and let's work together to figure out a whitelist
policy that we can extrapolate to other extensions.

> So what's your solution?

Why do Mozilla people, who devised and forced on the community a plan to
combat malware, keep suggesting that the onus is on others to come up
with an alternative that allows software that's obviously not malware to
continue to exist and thrive? You put this broken plan into motion.

But we have the beginnings of a whitelist framework from Gijs, so why
don't we just focus on that?

> The current model has been abused by lots and lots of bad actors. A huge
> proportion of user complaints come from bad add-ons. That's not good for
> anyone. How do we distinguish between a good actor and a bad one? How do
> we ensure the former don't turn into the latter? I've been shocked on
> multiple occasions by the authors who've gone rogue, or even just sold
> their add-on listing to rogue actors.

Zotero doesn't have an add-on listing. We have a website, zotero.org, to
which people have come of their own volition for the last 9 years. Do
you understand that if Zotero somehow turned rogue, as you and others
keep suggesting we might, Mozilla would be the least of our problems? We
would be sued out of existence.

The current model, of Zotero attracting users to its own website and
earning their trust, has been abused by nobody.

But Zotero aside, let's keep in mind here that we're talking solely
about front-loaded, unhosted extensions, which up until now have been
subject to no review process and, by Jorge's own admission [1], have not
been a major cause of concern. So any theoretical harm here is roughly
circumscribed by the amount of harm that those specific extensions
currently cause. Any errors in whitelisting would be limited to a tiny
subset of a select group of a minority of problematic extensions, and if
it seems like different guidelines could have prevented those errors,
the guidelines can be adjusted.

If you have concerns about Gijs's whitelist proposal due to the past
behavior of certain front-loaded, unhosted extensions, let's review the
evidence so we can make good decisions going forward. You keep declining
to name names, but I don't see the point of deference to formerly bad
actors — public recognition should be one consequence of a breach of trust.

Add-ons on AMO or that were side-loaded that breached trust aren't
really relevant to the current discussion, but it may be helpful to
review the identities of some of those to get a sense of the threat model.

> I'm not opposed to a whitelist, but I'm opposed to a weak one that relies
> on blind trust and has no major consequences. So we need something better.

The major consequence of a whitelisted developer failing to respond to a
demonstrable security issue would be temporary blocklisting and
revocation of whitelist privileges. The major consequence of a trusted
developer suddenly distributing malware would be immediate ejection from
the Firefox ecosystem and quite possibly legal action.

There's a gray area in there — I'm not sure where add-on guideline
violations such as ad injection would fall — but this seems like a
starting point.

> Let's get to the point: if an add-on gets a 0-day, or just finds a critical
> flaw, there should be a way to flag that for urgent approval. In the
> absence of a mechanical solution, it's not like the people capable of
> escalating things aren't well-known individuals reachable by email. Yes,
> that adds a bit of latency, but an early heads up that an urgent submission
> is coming is hardly an excessive burden so we can arrange for a quick
> turnaround. We've done that for years for AMO-hosted add-ons, it's very
> rarely created a significant delay in rolling out a fix to affected users.

Extensions on AMO have different requirements — I think you're going to
need to accept that if we're going to get anywhere here. Extensions that
aren't on AMO aren't on AMO for a reason.

When we had a critical compatibility flaw with Firefox 41, every minute
that went by meant that hundreds more people were going to end up on a
bad version, possibly for days. If a user is experiencing an issue,
we'll often have a beta version available with a fix within minutes so
they can get back to work. If you think we're going to put ourselves in
a situation where we're emailing Jorge at 3 a.m. on a Saturday night
begging for a (pointless) review, you're deeply mistaken. We've earned
our users' trust over the last decade by being responsible and
responsive, and we're not going to let Mozilla ruin that trust.

- Dan

[1]
https://groups.google.com/forum/#!msg/mozilla.addons.user-experience/qIgLq28aTdI/IyD2p_CFAEUJ

[Emiliano Heyns]

On Thursday, October 22, 2015 at 5:49:52 AM UTC+2, Dan Stillman wrote:
> On 10/21/15 7:58 PM, Mike Connor wrote:
> > The current model has been abused by lots and lots of bad actors.

So how many of these "lots and lots" bad actors had an extension with active development and a track record of being responsive to users logging issues, all out in the open?

> The major consequence of a whitelisted developer failing to respond to a
> demonstrable security issue would be temporary blocklisting and
> revocation of whitelist privileges.

And the idea that one would be forced back on the review queue should be ample deterrent.

> > Let's get to the point: if an add-on gets a 0-day, or just finds a critical
> > flaw, there should be a way to flag that for urgent approval.

My standards for "critical flaw" include performance issues that interfere with a user getting their work done.

> When we had a critical compatibility flaw with Firefox 41, every minute
> that went by meant th