On Fri, Jul 20, 2012 at 9:31 PM, Kris Maglione <[email protected]> wrote: > On 07/20/2012 06:33 AM, Henri Sivonen wrote: >> >> On Fri, Jul 20, 2012 at 2:27 AM, Jorge Villalobos<[email protected]> >> wrote: >>> >>> * Add-ons must be installed either using the add-on install system or the >>> >>> install opt-in dialog >>> >>> [https://blog.mozilla.org/addons/2011/08/11/strengthening-user-control-of-add-ons/]. >> >> ... >> >>> Per blocklisting policy [https://wiki.mozilla.org/Blocklisting], Mozilla >>> will do their best to contact the developer and provide a reasonable time >>> frame for the problems to be corrected before a block is put in place. >>> The >>> only exception to this are add-ons that are considered to be malicious or >>> whose developers have proven to be unreachable or unresponsive. >> >> >> To me, it makes sense to give "a reasonable timeframe for the problems >> to be corrected before a block is put in place" before blocking >> extensions over accidental violations. Violations of the installation >> guideline typically seem obviously intentional. I don't see why we >> should give extension developers who violate the installation >> guideline in a way that looks intentional the benefit of the doubt and >> wait before blocklisting. > > Because it's quite often not done with malicious intent.
Well, even if extensions authors who do that think they don't have malicious intent, surely it has to be clear to them that they are deliberately circumventing a mechanism that Mozilla has put in place to ensure that the user user is in control. > External > installers, especially from things like anti-virus software, but often > enough from sites that for some reason make you download a .exe installer > rather than just installing the XPI directly, very often ask users whether > they want the add-on installed (though opt-out rather than opt-in) and then > bypass about:newaddon because they feel that confirmation is enough. We > disagree, which is why we give them the opportunity to fix it before we > simply block their add-ons. It also doesn't help that quite a lot of users > will be upset by having add-ons disabled after they've asked that they be > there. I think we shouldn't be giving add-ons that circumvent our mechanism like that the benefit of the doubt. Therefore, I suggest we eliminate the doubt by making identifiers used by our implementation obviously self-documenting. I suggest we rename extensions.enabledScopes to add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.enabledScopes, extensions.autoDisableScopes to add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.autoDisableScopes and similarly prefixing other prefs or file names used for tracking the add-on installation state. This way, we'd have no excuse to wait before blocklisting add-ons that circumvent the mechanism that puts users in control of add-on installation. -- Henri Sivonen [email protected] http://hsivonen.iki.fi/ _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
