On 11/18/15 12:56 PM, Jorge Villalobos wrote:
> On 11/18/15 1:36 AM, Dan Stillman wrote:
>> What's the rationale for using ADU as a metric? As I noted earlier, an
>> extension with relatively fewer users might still have an appropriately
>> conscientious and dedicated developer and still be critical to users'
>> workflows (e.g., Emiliano's extension), and having a small user base
>> means that the risk of a (very) hypothetical problem is much smaller
> While the risk may be smaller, the potential gain for our users is also
> smaller. I think that keeping a small whitelist is important, and the
> usage metric is a useful and fairly objective filter for this.
The risk and gain are both limited to precisely the number of users of
the extension. It seems like the fair and objective metric here to keep
a small whitelist would be "difficulty in passing automated review",
perhaps with a slightly less objective additional metric of "importance
of timely updates". If someone can already pass automated review, adding
them to a whitelist doesn't seem necessary — if rapid updates are
important, they can add the signing API or offline validator to their CI
pipeline so that they're notified of new failures.
This metric isn't our fight, and I'm actually not sure if Emiliano is
even having trouble passing automated review at the moment, but given
that Zotero and Emiliano are so far the only developers to even come
forward and articulate the need for a whitelist, it's not clear that
more than a small number of developers are in this position.
>> But also, how is seeing this on AMO many times relevant to unlisted
> It's relevant as evidence that this sort of thing happens regularly.
Well, it's not really evidence if you don't provide concrete examples
that we can evaluate against the proposed rules, but at most it's
evidence that these sorts of sales happen regularly for AMO extensions.
I'm arguing that there's much less reason to think they happen regularly
for unlisted extensions, where users need to come to a site and
personally trust a developer.
In any case, I hope we can agree that it's even less likely to happen in
the case of whitelisted extensions, which would pass an even higher bar
of trust and in most cases (by virtue of the public bug tracker
requirement, among other things) have a community around them.
> We have very little historical information about unlisted add-ons. We
> have blocked numerous unlisted, probably front-loaded extensions along
> the years, but they are mostly of malicious nature. I don't recall a
> case of ownership changes being the cause, but it's unlikely we would
> even hear about that. There might be cases in the blocklisted add-ons
> history (https://addons.mozilla.org/firefox/blocked/
), but it's pretty
> long and I don't have the time to dig and search for a concrete example.
OK, but just to be clear, then still no one can provide an example of a
front-loaded, unlisted extension that was legitimate and then became
illegitimate. I'm not denying that there might have been some, or that
it's possible, but I don't think we can draw any conclusion other than
that it's not a problem that merits significant concern — and that
whitelisted extensions would be even less likely to be a problem. We
need to weigh the highly unlikely specter of that against the very real
needs that the whitelist is trying to address.
In any case, other than the ADU metric, the current proposal seems
reasonable to me.