Sites I've never visited got allowed to install add-ons

[barbaz]

Was just going through about:data > Permissions on this machine, and noticed something very disturbing: two websites which I've never visited in my life were listed as allowed to install add-ons. I'm certain they weren't listed at all last time I checked.
The sites in question were marketplace.firefox.com and (I think) downloads.mozdev.org. I get all my addons from addons.mozilla.org, noscript.net, and local files; so those erroneous permissions have now been removed.

I don't check my permissions very often, so I have no idea how long those have been there. Any idea why they would have got added without notifying me and without my consent, and anyone else (other pre-release users?) seeing that?

[therube]

Ditto.

Have to assume they are defaults carried over from the FF end?
(The mozdev entry is particularly odd, IMO, as I would not think that would be included from the FF end. Don't know that I've ever particularly looked for this before? SQLite db? If so, maybe [but probably not] they log mod date change per entry?)

dom.mozApps.signed_apps_installable_from;https://marketplace.firefox.com

[barbaz]

Oh good, it's not just me. Think I'd get anywhere filing a bug asking for notification to the user of all such changes to install add-ons permissions?

[therube]

Create a new, clean Profile in both SeaMonkey & Firefox.
Open Data Manager & see if anything is populated, by default.
Visit https://addons.mozilla.org/en-US/seamonkey/ & then http://www.mozdev.org/ & check again.
Click, but do not install, an extension from each site & check again.
(Extension will download, that's expected, even if unwanted.)

[therube]

On a Profile that i /believe/ (but pretty sure) has only seen up to 2.33.1, for mozilla.org, i see addons.mozilla.org (no marketplace) & no mozdev at all.
(Actually i copied permissions.sqlite from that < 2.34 Profile into existing "dumy" Profile.)


Might also try toggling Software Installation (& back again, perhaps even restarting in between) & see if that might make any difference, as perhaps something in there could be triggering...?

There have been times I may have had Software Installation off, completely.
At times only extensions blocked from updating.
And then at times, only particular extensions blocked from updated (through Addons Manager).

So possible (only surmising) that if you had FlashBlock installed, but updates for it disabled (& even though you had never "allowed" mozdev [aka flashblock.mozdev.org], that on re-enabling updates for FlashBlock, that may have triggered mozdev.org to be added?

[therube]

(looking at SeaMonkey 2.39, ATM...)

omni.ja -> defaults -> permissions
(shortcut: resource:///defaults/permissions)

Code: Select all

# This file has default permissions for the permission manager.
# The file-format is strict:
# * matchtype \t type \t permission \t host
# * Only "host" is supported for matchtype
# * type is a string that identifies the type of permission (e.g. "cookie")
# * permission is an integer between 1 and 15
# See nsPermissionManager.cpp for more...

# XPInstall
host   install   1   addons.mozilla.org
host   install   1   marketplace.firefox.com
host   install   1   downloads.mozdev.org

# Remote troubleshooting
host   remote-troubleshooting   1   input.mozilla.org
host   remote-troubleshooting   1   support.mozilla.org

Perhaps nsPermissionManager.cpp points to the trigger, as to when & what may cause those entries to be added - as they do not initially show up in a new, clean Profile.

[TPR75]

Perhaps nsPermissionManager.cpp points to the trigger, as to when & what may cause those entries to be added - as they do not initially show up in a new, clean Profile.

... and what is more important will our rules of blocking (if somebody wants it) override default "permission settings"?

[barbaz]

So I've been talking to therube on IRC and done some testing: this isn't happening until SeaMonkey '2.36pre' (based on Firefox 39.0), and these entries are sitting in the "resource:///defaults/permissions" file, which is dumped in the user's permissions database by ImportDefaults().
(Thank you so much Mozilla for making it easy to change the list of added permissions. )

(I wonder where the two "remote-troubleshooting" enries are and if they even got added?)

Anyway, this confirms that the entries are "legitimate", but I still don't like that they are added to an existing profile with no indication to the user, so I'm going to look into filing a bug to ask for some kind of notification if permissions were changed during ImportDefaults().

[barbaz]

... and what is more important will our rules of blocking (if somebody wants it) override default "permission settings"?

Well in any case at least it is possible to configure the default permissions URL: about:config > permissions.manager.defaultsUrl

[barbaz]

https://bugzilla.mozilla.org/show_bug.cgi?id=1190233

(I wonder where the two "remote-troubleshooting" enries are and if they even got added?)

Looks like they don't get added in SM 2.36pre but they do get added in the Aurora build I used for the purpose of coming up with STR for the bug.

[therube]

Was the same happening with FF?
If so, then maybe move Product: to Core or something like that?

[rsx11m]

It's "inherited" from Firefox due to a core change, but the whitelist itself is per application:

• Bug 1072751 - Switch SeaMonkey from xpinstall.whitelist.add to using a default permissions file.

[rsx11m]

Code: Select all

# Remote troubleshooting
host   remote-troubleshooting   1   input.mozilla.org
host   remote-troubleshooting   1   support.mozilla.org

This seems especially troublesome as I doubt that the Firefox-specific *.mozilla.org sites are equipped to deal with anything other than Firefox...

[therube]

Oh, OK, & knowing that Bug, it makes sense that resource:///defaults/permissions is invalid in SeaMonkey 2.33.1 .

[rsx11m]

I've posted an ad-hoc patch to remove marketplace and the remote-troubleshooting sites from the list, but IanN apparently wants to wait for some feedback from the core devs given that those settings should only be used for new profiles and not for those updating from an earlier version. Anyway, I'd still think that removing the Firefox-only sites from the SeaMonkey defaults makes sense.