On 10/21/15 7:58 PM, Mike Connor wrote:
> On 21 October 2015 at 14:00, Emiliano Heyns <emilian...@iris-advies.com
>> 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
> 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
>>>> 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
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 , 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
> 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.