Just to give some context here, we've been asking for a "trusted author"
whitelist for three months. Gijs even helpfully proposed specific rules.
The reason things came to this point is that it was still being argued
as of last week that the whitelist was inherently more dangerous by
allowing whitelisted developers to do malicious things and evade
detection. We can now see that's not true — non-whitelisted extensions
can do the same thing, trivially.
We've assumed that Zotero would be whitelisted, but that doesn't help
other legitimate extension developers if the whitelist is designed with
an assumption that a whitelisted extension is more dangerous. The
proposed rules were still going to restrict whitelist status to
extensions with large numbers of users.
Given what we know now, I can't see a justification for not
"whitelisting" (meaning allowing an automated review override) any
demonstrably legitimate developer. In terms of malware, you'd have to
argue that someone who bought, compromised, or developed a legitimate
extension would then be unable or unwilling to rewrite one line to get
code past the validator. In terms of potentially insecure code (e.g.,
innerHTML), you'd have to argue that those patterns posed sufficient
risk to users over the next several days that blocking an extension
update (which possibly contained other important bug fixes that
definitely affected users) made sense, as opposed to AMO reviewers
looking at them after the fact and asking for immediate fixes or
blocklisting depending on severity (and rescinding "whitelist"
privileges if there's a pattern of ignoring issues).
I've gone further and argued that, given the ease of a validator bypass,
just doing an initial manual review for the first release of any
front-loaded unlisted extension would be the meaningful blocking step,
but that's not as important. I just don't want to see obviously
legitimate developers of existing extensions blocked for no reason.
On 11/30/15 2:52 PM, Ehsan Akhgari wrote:
That sounds like a good idea to me as well.
On 2015-11-30 11:25 AM, Gavin Sharp wrote:
That's one of the suggestions Dan Stillman makes in his post, and it
seems like a fine idea to me.
Gavin
On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew <[email protected]>
wrote:
On 30/11/15 15:45, Gavin Sharp wrote:
and it's definitely the wrong thing to do.
Fundamentally the add-on signing system was designed with an important
trade-off in mind: security (ensuring no malicious add-ons are
installed/executed) vs. maintaining a healthy add-on ecosystem
(ensuring
that building and distributing add-ons is as easy as it can be).
If your proposed alternative plan is "get rid of automatic
signing", then
we know that it's going to significantly hamper Mozilla's ability to
maintain a healthy add-on ecosystem, and harm what were considered
some
important add-on use cases. I don't think it strikes the right
balance.
If your proposed alternative plan is something else, maybe it would
help
to
clarify it.
Perhaps if there were a mechanism whereby "trusted" add-on
developers could
have their add-ons -- or even just updates for
previously-reviewed-and-signed add-ons -- automatically signed without
having to jump through the validator/review hoops each time?
How would a developer acquire "trusted" status? By demonstrating a
track
record of producing add-ons that pass AMO review -- which may be a
combination of automatic validation and/or human review.
And of course any add-on developer who is found to have abused their
"trusted" status to sign and deploy malicious code would have that
status
revoked, in addition to the malicious add-on being blocked.
ISTM this would maintain most of the intended benefits of the signing
system, while substantially smoothing the path for developers such
as Dan
who need to deliver frequent updates to their users.
Feasible?
JK
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
