1190233 - "Default" permissions being added to an existing profile without user's consent or awareness

Status: RESOLVED FIXED

(SeaMonkey :: Passwords & Permissions, defect)

Description

[kevink9876543]

(repro directions are for Linux x86_64, but I have seen this in other OSes as well)

Steps to reproduce:
1) Start SeaMonkey 2.33.1 in a new profile
2) Go to about:data, note the permissions
3) Upgrade SeaMonkey to a version based on Firefox 39.0 release or later, say this official Aurora build: https://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2015-08-02-01-30-05-comm-aurora/
4) Start SeaMonkey in the same profile as before, and again note the permissions in about:data


Expected results:
The permissions stay the same.


Actual results:
addons.mozilla.org, marketplace.firefox.com, and downloads.mozdev.org are now suddenly allowed to install add-ons, and support.mozilla.org and input.mozilla.org are given "remote-troubleshooting" permission - all without any signal to the user that any change was made.  Users' existing permissions setups are as they are for a reason, we should be made aware of any change, *especially* a change in the "more permissive" direction, so that we know what our browsers are allowed to do.  And installing add-ons is one of the most significant permissions, as a site allowed to install add-ons is effectively trusted with the privileges of the user running the application.

Possible solutions that I can think of:
 1) Change the default permissions file preference to point to a SeaMonkey-specific file that is a copy of the blank permissions file that was in SeaMonkey 2.33.1, so that there aren't any permissions changes to be made
 2) Throw a confirmation dialog listing the permission change(s) and asking the user whether or not to accept them
 3) Notify the user (perhaps by a doorhanger) that some permission was changed automatically; then if we users care, we go to about:data and find out on our own what changed and deal with it appropriately.


mozillaZine thread: http://forums.mozillazine.org/viewtopic.php?f=40&t=2951459

Comment 1

[rsx11m]

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

> Possible solutions that I can think of:
>  1) Change the default permissions file preference to point to a SeaMonkey-
> specific file that is a copy of the blank permissions file that was in 
> SeaMonkey 2.33.1, so that there aren't any permissions changes to be made

That's suite/app/permissions (apparently copy-pasted from its Firefox counterpart).

Comment 2

[Ian Neal]

As far as I am aware the app/permissions file would only be sourced if there was no permissions database. This would also impact on Firefox, hopefully bsmedberg knows the workings (or knows someone that does).

Comment 3

[rsx11m]

Attachment: Mitigating fix removing SM-unrelated sites

As an ad-hoc fix, preferably for 2.35 already, this patch removes the sites which are intended to be used with Firefox only and are thus not relevant for SeaMonkey to start with (specifically the remote-troubleshooting ones users are likely to object allowing those by default). I'm leaving mozdev.org in as it was added on purpose in bug 1072751.

Comment 4

[rsx11m]

(In reply to Ian Neal from comment #2)
> As far as I am aware the app/permissions file would only be sourced if there
> was no permissions database. This would also impact on Firefox, hopefully
> bsmedberg knows the workings (or knows someone that does).

Ian, reports in the MZ thread indicate that these changes were made to /existing/ profiles used in 2.33.1 already, not just in /new/ ones, so that's apparently not the case and the default permissions should be more conservative.

Comment 5

[Ian Neal]

(In reply to rsx11m from comment #4)
> (In reply to Ian Neal from comment #2)
> > As far as I am aware the app/permissions file would only be sourced if there
> > was no permissions database. This would also impact on Firefox, hopefully
> > bsmedberg knows the workings (or knows someone that does).
> 
> Ian, reports in the MZ thread indicate that these changes were made to
> /existing/ profiles used in 2.33.1 already, not just in /new/ ones, so
> that's apparently not the case and the default permissions should be more
> conservative.

Hence the need-info, as it shouldn't be happening and if it is happening I would expect it to impact on Firefox users too.

Comment 6

[kevink9876543]

No extra permissions are added by SeaMonkey 2.35 here, thus 2.35 is actually unaffected by this bug; I've changed the flags accordingly.

Comment 7

[Magnus Melin [:mkmelin]]

(In reply to Ian Neal from comment #2)
> As far as I am aware the app/permissions file would only be sourced if there
> was no permissions database. This would also impact on Firefox, hopefully
> bsmedberg knows the workings (or knows someone that does).

Per bug 1073095 comment 8 and 9, if you don't want default permissions in affect, you should set the permissions url to be empty. I don't think there's a bug here. The sourced prefs are not persisted.

Comment 8

[kevink9876543]

(In reply to Magnus Melin from comment #7)
> Per bug 1073095 comment 8 and 9, if you don't want default permissions in
> affect, you should set the permissions url to be empty. I don't think
> there's a bug here.
That's fine for single user setups (I'll go do that right now in my user.js).  The bug here is not simply that changes are being made to users' permissions (existing or new), it's that users who don't compulsively check about:data have no idea that their existing permissions have been altered in the "more permissive" direction.

Comment 9

[Philip Chee]

Comment on attachment 8642395 [details] [diff] [review]
Mitigating fix removing SM-unrelated sites

Ayup. My bad. r=me CLOSED TREE

Comment 10

[rsx11m]

Comment on attachment 8642395 [details] [diff] [review]
Mitigating fix removing SM-unrelated sites

Since Phil gave the patch an r+ already, cancelling r? for IanN, but requesting branch approval for 2.36-2.38 (do we want this for 2.35 anyway?).

[Approval Request Comment]
Regression caused by (bug #): bug 1072751
User impact if declined: sites apparently useless for SM given default permissions
Testing completed (on m-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): very low
String changes made by this patch: none

Comment 11

[Benjamin Smedberg]

I don't think you need any more information from me, but in case you do these are default permissions loaded at each startup which can be overridden by user permissions, but they aren't loaded into the user permission database. This is similar to the way default prefs work.

Comment 12

[Ian Neal]

Comment on attachment 8642395 [details] [diff] [review]
Mitigating fix removing SM-unrelated sites

a=me for 2.36 and above (as far as I am aware 2.35 is unaffected)

Comment 13

[Ian Neal]

Comment on attachment 8642395 [details] [diff] [review]
Mitigating fix removing SM-unrelated sites

[Triage Comment]
a=me for 2.36 too, wrong item selected

Comment 14

[rsx11m]

Thanks, push for all default channels please.

Comment 15

[Ian Neal]

a=me for 2.35 as pointed out the original patch landed on 2.35

Comment 16

[Philip Chee]

comm-central (2.40)
http://hg.mozilla.org/comm-central/rev/8b7a22fcff5c
comm-aurora (2.39)
http://hg.mozilla.org/releases/comm-aurora/rev/46921622f2f1
comm-beta (2.38)
http://hg.mozilla.org/releases/comm-beta/rev/f51ce4cdc40d
comm-release (2.37)
http://hg.mozilla.org/releases/comm-release/rev/788a65a99efe
SEAMONKEY_2_35_RELEASE_BRANCH
http://hg.mozilla.org/releases/comm-release/rev/77a191044190

Comment 17

[Philip Chee]

SEAMONKEY_2_36_RELEASE_BRANCH
http://hg.mozilla.org/releases/comm-release/rev/e809326bfcb4

Comment 18

[rsx11m]

Ratty: Thanks for the heavy branch work!  :-)

kevink/barbaz: This bug has been closed after the patch has been checked into all branches. If you think that anything from your list in the opening description should be considered and implemented, please open a follow-up bug. Given that (1) has been implemented here with reducing the whitelist to match effectively what was allowed in 2.33.1 (with the exception of mozdev having been added), note that both (2) and (3) from your list require string changes, thus won't be able to land on the branches (and thus in time for when the change from bug 1072751 affects the user).

Comment 19

[kevink9876543]

(In reply to rsx11m from comment #18)
> kevink/barbaz: This bug has been closed after the patch has been checked
> into all branches. If you think that anything from your list in the opening
> description should be considered and implemented, please open a follow-up
> bug. Given that (1) has been implemented here with reducing the whitelist to
> match effectively what was allowed in 2.33.1 (with the exception of mozdev
> having been added), note that both (2) and (3) from your list require string
> changes, thus won't be able to land on the branches (and thus in time for
> when the change from bug 1072751 affects the user).
With the change that was committed, implementing (2) or (3) is far from urgent atm IMO.

Thanks all for taking care of this. :)