Add-ons manager should check AMO for updates first, even if an add-on has its own updateURL. This will allow us to override non-AMO hosted add-ons and should give us usage and compat data as well (right?)
Wouldn't that mean that the add-on has also be hosted on AMO? I can't remember that we are supporting handling of non-uploaded add-ons on AMO. Justin, can you please help?
I don't think so....we could look for an update on AMO, not find it, then try updateURL. If we were overriding I don't think we'd need to actually have the bits on our server, just the entry in the database with the compatibility info returned. In any case, I *think* this would get us more data than we have now...don't quote me on that though, we may already have any data this would give us :-)
It'd get us a little more data but not a lot. This is certainly not the route I'd take if we only wanted data. As I mentioned over email I'd like to see a better discussion on what our goals and constraints are before deciding whether this is the right route or not.
Why would you want to do so? Just to gain statistics data while centralizing add-in distribution point even if add-developer explicitly provided his own distribution point? Is it really worth putting the burden of preventing id conflicts (be it malicious or accidental) on reviewers? It is my opinion author's updateURL should be respected and not misused for spying^Wstatistics. However, if statistics is genuinely needed for some reason you can make add-in manager report it to AMO, but still make it possible for user, or an individual add-in to opt-out of the statistics.
I wonder if it would be useful to check AMO for updates if an error occurred when checking with the addon's specified update URL.
This would be a huge security issue. If an add-on was not hosted on AMO at all, anyone could come in, create an AMO entry for that add-on and hijack it. You should not be collecting any data for add-ons that are not hosted on AMO.
Agreed with mkaply on both points. Furthermore, some addons have different variants. For example, an addon included in an official Firefox bundle differs from the version on AMO, because the Firefox bundle contains parts (prefs, search engines) of the addon, while the AMO version needs to work on a standard Firefox.
Why might Mozilla be compelled to do it: - "override non-AMO hosted add-ons" (as an alternative to kill switch?) - "should give us usage and compat data as well (right?)" Why it shouldn't be done: - security: it is bad alternative to kill switch as it not just kills the addon, but opens up a possibility of installing another one (possibly malicious) - privacy: app calling home (to AMO) for no well justified reason, revealing all user's add-ons Add-on kill switch is already in place: http://support.mozilla.org/en-US/kb/add-ons-cause-issues-are-on-blocklist and used: https://addons.mozilla.org/firefox/blocked/ Statistics gathering without compromising security (or privacy?) is already taking place: https://addons.mozilla.org/statistics/ https://addons.mozilla.org/firefox/addon/add-on-compatibility-reporter/statistics/ I propose to reject this and mark the bug as WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.