On 9/20/15 8:26 AM, The Wanderer wrote:
> On 2015-09-15 at 15:57, Mike Connor wrote:
>
>> Hi Dan,
>>
>> Overall, I wouldn't assert that directly distributing malware is
>> the sole consideration in play.
> Eh?
>
> In past discussion here and elsewhere, countering directly-malicious
> extensions has been the _only_ argument I've seen presented in support
> of requiring extensions to be signed at all (much less requiring them to
> be signed by Mozilla) or against suggestions of ways to disable the
> signing requirement in release-channel builds.
>
> If there is another justification for it which would be considered
> enough on its own, to only present that justification _now_ (when things
> are so far along that virtually no counterargument could have enough of
> an impact to change the course) rather than up-front at the start of the
> discussion is - at the very least - a significant case of moving the
> goalposts for a potential counterargument.
While it's been a pleasant lull, since the clock is still ticking, I'd
like to return to this issue. I can't echo this response enough.
Mozilla gave one justification for this scheme, over and over, without
variation: combating malware. To now say that malware isn't "the sole
consideration in play" implies that Mozilla was misleading the community
about its intentions.
Just to set the record straight, let's review some of the comments from
Mozilla folks about this plan:
- From the "Introducing Extension Signing: A Safer Add-on Experience"
blog post [1]: "gives bad actors too much freedom to take advantage of
our users", "malicious developers", "bad add-ons". Jorge, in the
comments: " automated malware check", "We only need to verify the add-on
isn’t malicious on its own", "add-on malware is currently an
uncontrollable mess"
- From the "The Case for Extension Signing" blog post [2]: "The adware
scourge", "unwanted add-ons", "malicious developers", "malicious add-on"
- From the Extension Signing wiki page: "Will this protect users against
all forms of add-on malware? No, there is no perfect solution for this.
Fighting malware requires defenses on many levels… Extension signing is
a big step in protecting Firefox against malicious add-ons"
- Daniel Veditz in June 2014 [3]: "We're doing this because every time
any of us visits our family their Firefox is a toolbar laden crapfest
that we have to clean up, and because the resulting bad performance is
causing us to lose users."
- Jorge even said outright in a comment on the first blog post: "our
purpose is to block malware distribution, not police code quality"
Nowhere in the posts above was it suggested that there was any other
motivation for the change. (Honestly, I looked.) In August 2014 Jorge
even said that "The evidence we have points to silent side-loading as
the main culprit for add-on problems" [4], suggesting that front-loaded
non-AMO extensions were hardly even a problem to begin with.
But if policing "code quality" is indeed part of the goal and Mozilla
wants to assert AMO-style review over every non-trivial extension (or at
least the ones that don't trivially circumvent the scanner), then let's
get that out in the open and have the debate again under honest terms.
(Just to clarify what that looks like: 1) an obviously legitimate
extension like Zotero being rejected, 2) our being given notes for
having variables in the global scope (which they actually weren't), for
a JS file being in the 'skin' directory, for making changes to TinyMCE
to fix incompatibilities with the Zotero UI, for /not/ making changes to
TinyMCE to avoid the use of document.write, for using innerHTML in
shared code that's not even run in Firefox and that was copied verbatim
from the MDN DOMParser documentation, and for a few other harmless
things, 3) our having to explain, over the course of several weeks, why
every one of these issues was innocuous in context, as we always had to
on AMO before we left several years ago, 4) Jorge acknowledging that
there were no actual security issues, and 5) our resubmitting a new
build in which the only changes were a couple unminified TinyMCE plugins
and a few comments saying that the lines that followed weren't actually
security issues. And then a 4+-day wait for every review since.)
If the concern really is malware, though, there's no plausible reason
for forcing an obviously legitimate, unlisted, front-loaded extension
like Zotero to be manually reviewed every single time an update — and
even a beta update — is released. 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.
I said previously that we can't keep developing Zotero as a
full-featured Firefox extension if every update takes days to put out.
Well, a few weeks ago, when Firefox 41 came out, we had to put out four
releases in rapid succession due to major breakage — including an
absolute showstopper — from various undocumented changes in 41. The
biggest breakage we should have caught and somehow missed. The rest was
platform-specific and harder to catch (though the best chance would've
been through more people running daily beta updates, something this
scheme will prevent, since even betas will take days to review).
Fortunately we were able to put out unsigned builds within minutes of
the first reports, keeping most of our users from even seeing the bugs.
If Firefox 41 had enforced extension signing as originally planned, it
would have been disastrous for our users, who rely on Zotero to write
dissertations, submit academic papers, complete homework assignments,
and perform daily research. This sort of thing doesn't usually happen —
minor changes in Firefox don't usually cause major breakage in Zotero,
and we almost always catch compatibility issues in time — but it
underscores why we can't continue developing Zotero if we can't put out
releases quickly.
So if we can't find a solution here, then that's the end of Zotero as a
full-featured Firefox extension. But let's start by being clear about
the purpose of this system.
- Dan
[1]
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
[2]
https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/
[3]
https://groups.google.com/d/msg/mozilla.addons.user-experience/F2ejhP32a0Y/6rWyYX84VLYJ
[4]
https://groups.google.com/d/msg/mozilla.addons.user-experience/qIgLq28aTdI/IyD2p_CFAEUJ
>> There's lots of software out there that I wouldn't necessarily
>> label as malware in itself, but violates our add-on guidelines and
>> best practices in many other ways that lead directly to users
>> moving away from Firefox.
> And that is reason enough not to host such addons on AMO.
>
> It is _not_ reason enough to refuse signing in a central
> signing-is-mandatory paradigm, unless what you are trying to do is not
> to improve security but to increase centralized control.
>
> Under the "countering malware" justification for requiring extensions to
> be signed, the answer to "will we sign this extension?" should be
> exactly the inverse of the answer to "if we saw this extension in the
> wild under the blocklist-based paradigm, would we add it to the
> blocklist?". Anything else turns this from an attempt to improve
> security into an attempt to seize control.
>
> Many people who object to the move to require extensions to be signed
> understand the "need to counter malware" argument, even if they disagree
> that the proposed solution is proportionate, and can grudgingly accept
> that the move might be justifiable on those grounds.
>
> I suspect that _very few_ of those people would be _remotely_ willing to
> accept an assertion of centralized control by Mozilla on the
> less-critical "code quality" argument which you seem to be making.
>
> Such move to centralized control would be counter to the ethos of
> freedom and user control which Firefox and Mozilla have historically at
> least appeared to stand for.
>
>> Security/privacy/stability problems are too common still, as well
>> as notable performance degradation, especially memory. The long
>> term solution is to build a better add-on system, and that work is
>> progressing in parallel. In the meantime, we're raising the bar in
>> general.