Bugzilla

(In reply to Dominik Kugelmann from comment #5)
> I tend to disagree.  
> 
> # Issue one: Principle
> A profile should only be used for internal management of company "owned" browsers and never for "normal" installation of an extension.

I guess with our removing the ability to sideload add-ons, there might not be another way of doing this, other than asking users to do it (e.g. by opening a website with a big "click here to finish installation" button or whatever).

> Which also won't allow the user to uninstall the extension as they can only turn it off. 

I don't understand this. Did you test this on Firefox? Mike claims it is not true:

(In reply to Mike Kaply [:mkaply] from comment #4)
> And they are using a normal policy install which means the user is free to uninstall it from the addons manager.

(needinfo for this)

(In reply to Dominik Kugelmann from comment #5)
> users clicked and allowed admin rights, but they do this for worse malware too...

Sure, but there aren't that many ways application A can protect itself from application B that has admin rights.

> # Issue two: Multiple Profiles
> I have no direct experience with managing Firefox but I do with Chrome.
> I do not know if a device can have multiple profiles for Firefox and which would take precedence if there is only one possible. In Chrome I can have 3 layers of Management [1] (Device, Cloud, User). I primarily manage our devices via the Cloud Token [2].  As soon as this profile is being installed it will overwrite all of the other cloud and user management policies for extensions.  I don't know how Firefox handles this but on the Chrome side this is rightfully seen as a malicious use of policies. 

Firefox supports multiple local user profiles (try opening about:profiles). I defer to Mike but AIUI our enterprise policy support would affect all Firefox profiles on the machine, and there aren't any further layers to it. It sounds like the installer might overwrite other enterprise policy stuff already present on the local machine (but someone would need to test / inspect the installer to check). That seems problematic from a "actor A shouldn't overwrite stuff from actor B willy-nilly" perspective, but with admin rights on the machine and thus write access to the registry and the entire disk, I don't see how Firefox could protect the existing enterprise policy. 

t is not in our gift to somehow prevent the installer from running, and blocking the add-on will not fix things, it'll just make the Estonian ID card system not work. It might feel like "punishing" the eID folks but mostly it'll be punishing the users and forcing them to switch browsers.

I'm also confused about the overwriting - on locked down machines with enterprise policy, I would not expect users to have admin rights (or they could already remove the enterprise policy if they wanted)... Can you elaborate on why users are allowed admin access to overwrite these cloud/user management policies in your situation? (needinfo for this too)

> # Issue three:  Supply Chain Attack / future additional policies
> Currently the .exe / .dmg's only install this one policy but that won't stop them or a potentially malicious attacker to install additional extensions or other potentially harmful additional policies.  

This is a slippery slope argument. Chrome's installer could start uninstalling Firefox (or vice versa) automatically, but that doesn't mean we should stop users downloading the Chrome installer in our own browser... ;-)

> I don't know what you can do to prevent them to do so other than reaching out yourself but I believe this is an issue that should be addressed.  

Have you tried reaching out to the Estonian ID folks yourself? What do they think about this?

(In reply to Mike Kaply [:mkaply] from comment #4)
> I'm not sure whether I agree or disagree with the mechanism, but the reality is that they ask for admin privileges and the user gives it, they are free to do anything to the system. There's not much we could do here.

I would tend to agree.

(In reply to Dominik Kugelmann from comment #5)
> I tend to disagree.  
> 
> ### Issue one: Principle
> A profile should only be used for internal management of company "owned" browsers and never for "normal" installation of an extension.

I guess with our removing the ability to sideload add-ons, there might not be another way of doing this, other than asking users to do it (e.g. by opening a website with a big "click here to finish installation" button or whatever).

> Which also won't allow the user to uninstall the extension as they can only turn it off. 

I don't understand this. Did you test this on Firefox? Mike claims it is not true:

(In reply to Mike Kaply [:mkaply] from comment #4)
> And they are using a normal policy install which means the user is free to uninstall it from the addons manager.

(needinfo for this)

(In reply to Dominik Kugelmann from comment #5)
> users clicked and allowed admin rights, but they do this for worse malware too...

Sure, but there aren't that many ways application A can protect itself from application B that has admin rights.

> ### Issue two: Multiple Profiles
> I have no direct experience with managing Firefox but I do with Chrome.
> I do not know if a device can have multiple profiles for Firefox and which would take precedence if there is only one possible. In Chrome I can have 3 layers of Management [1] (Device, Cloud, User). I primarily manage our devices via the Cloud Token [2].  As soon as this profile is being installed it will overwrite all of the other cloud and user management policies for extensions.  I don't know how Firefox handles this but on the Chrome side this is rightfully seen as a malicious use of policies. 

Firefox supports multiple local user profiles (try opening about:profiles). I defer to Mike but AIUI our enterprise policy support would affect all Firefox profiles on the machine, and there aren't any further layers to it. It sounds like the installer might overwrite other enterprise policy stuff already present on the local machine (but someone would need to test / inspect the installer to check). That seems problematic from a "actor A shouldn't overwrite stuff from actor B willy-nilly" perspective, but with admin rights on the machine and thus write access to the registry and the entire disk, I don't see how Firefox could protect the existing enterprise policy. 

t is not in our gift to somehow prevent the installer from running, and blocking the add-on will not fix things, it'll just make the Estonian ID card system not work. It might feel like "punishing" the eID folks but mostly it'll be punishing the users and forcing them to switch browsers.

I'm also confused about the overwriting - on locked down machines with enterprise policy, I would not expect users to have admin rights (or they could already remove the enterprise policy if they wanted)... Can you elaborate on why users are allowed admin access to overwrite these cloud/user management policies in your situation? (needinfo for this too)

> ### Issue three:  Supply Chain Attack / future additional policies
> Currently the .exe / .dmg's only install this one policy but that won't stop them or a potentially malicious attacker to install additional extensions or other potentially harmful additional policies.  

This is a slippery slope argument. Chrome's installer could start uninstalling Firefox (or vice versa) automatically, but that doesn't mean we should stop users downloading the Chrome installer in our own browser... ;-)

> I don't know what you can do to prevent them to do so other than reaching out yourself but I believe this is an issue that should be addressed.  

Have you tried reaching out to the Estonian ID folks yourself? What do they think about this?

(In reply to Mike Kaply [:mkaply] from comment #4)
> I'm not sure whether I agree or disagree with the mechanism, but the reality is that they ask for admin privileges and the user gives it, they are free to do anything to the system. There's not much we could do here.

I would tend to agree.