Manual install: move preserves owner and permissions (?) #48

doomedguppy commented 2025年01月23日 04:58:50 +01:00

The manual install instructs several sudo mv operations. IIUC mv will maintain the original owner and permissions. This would mean that the policy and configuration files, when properly installed, are still owned by the user instead of e.g. root. Thus there is access to and room for malicious changes. (And depending on umask, might also not be accessible to other users on the system even though placed in system-wide paths.)

The manual install instructs several `sudo mv` operations. IIUC `mv` will maintain the original owner and permissions. This would mean that the policy and configuration files, when properly installed, are still owned by the user instead of e.g. `root`. Thus there is access to and room for malicious changes. (And depending on umask, might also not be accessible to other users on the system even though placed in system-wide paths.)

Gnu1 commented 2025年01月23日 05:21:24 +01:00

OOOOOOOOHHHHHHH
This is a security buggggggggg.

#49

OOOOOOOOHHHHHHH This is a security buggggggggg. #49

celenity commented 2025年01月23日 10:29:08 +01:00

@doomedguppy Thank you for catching this!!!

@Gnu1 Thanks for the PR, just merged.

I'll make an announcement on Matrix/Discord for users with manual installations to re-install.

@doomedguppy Thank you for catching this!!! @Gnu1 Thanks for the PR, just merged. I'll make an announcement on Matrix/Discord for users with manual installations to re-install.

Gnu1 commented 2025年01月23日 10:30:51 +01:00

I forgot that I should merge the PR to dev not main.
You can reset the PR then I'll change the PR

I forgot that I should merge the PR to dev not main. You can reset the PR then I'll change the PR

celenity commented 2025年01月23日 10:34:04 +01:00

No worries - I can just merge it with the dev branch. Probably best this got merged directly to main the quickest anyways.

No worries - I can just merge it with the dev branch. Probably best this got merged directly to main the quickest anyways.

Gnu1 commented 2025年01月23日 14:35:42 +01:00

@GW72 If you tried manually install, please remove files that installed with manually install.

@GW72 If you tried manually install, please remove files that installed with manually install.

celenity commented 2025年01月23日 15:03:02 +01:00

Indeed @GW72 - If you performed your manual installation with the sudo mv commands from the README, please make sure to reinstall with the updated steps. Apologies for any inconvenience, this was definitely a regretable oversight. I'm glad @doomedguppy noticed this and filed the issue, and I'm also glad @Gnu1 was able to respond and fix it so promptly.

I've made announcements in Phoenix's Matrix space & Discord server, as well as on my Mastodon and Bluesky, so hopefully people impacted will be aware and able to take the necessary action by reinstalling.

Indeed @GW72 - If you performed your manual installation with the `sudo mv` commands from the `README`, please make sure to reinstall with the updated steps. Apologies for any inconvenience, this was definitely a regretable oversight. I'm glad @doomedguppy noticed this and filed the issue, and I'm also glad @Gnu1 was able to respond **and** fix it so promptly. I've made announcements in Phoenix's Matrix space & Discord server, as well as on my Mastodon and Bluesky, so hopefully people impacted will be aware and able to take the necessary action by reinstalling.

GW72 commented 2025年01月23日 17:25:30 +01:00

Thanks for the heads up, much appreciated. I always used cp as in sudo cp -a phoenix.cfg /usr/lib/firefox/phoenix.cfg. The -a is by habit (keeps the file attributes). In this case, I am the owner, not root.

Thanks for the heads up, much appreciated. I always used `cp` as in `sudo cp -a phoenix.cfg /usr/lib/firefox/phoenix.cfg`. The `-a` is by habit (keeps the file attributes). In this case, I am the owner, not `root`.

GW72 commented 2025年01月23日 20:41:08 +01:00

The -a is by habit (keeps the file attributes).

Actually, this might be confusing. Use of -a (similar to -p) does allow a copied file to keep its original ownership in the new directory. Therefore, copying a file from root using -a would endow the file with an ownership of root in the new directory (IIRC).

So, don't use cp -a if you copy a file from rootunless you want that file to continue to be owned by root.

> The `-a` is by habit (keeps the file attributes). Actually, this might be confusing. Use of `-a` (similar to `-p`) does allow a copied file to keep its original ownership in the new directory. Therefore, copying a file from `root` using `-a` would endow the file with an ownership of `root` in the new directory (IIRC). So, don't use `cp -a` if you copy a file from `root`unless you want that file to continue to be owned by `root`.

doomedguppy commented 2025年01月24日 00:01:41 +01:00

@GW72 wrote in #48 (comment):

Thanks for the heads up, much appreciated. I always used cp as in sudo cp -a phoenix.cfg /usr/lib/firefox/phoenix.cfg. The -a is by habit (keeps the file attributes). In this case, I am the owner, not root.

I think you misunderstand. These files are installed in system-wide paths. You want something else, e.g. root to be owner, instead of your regular user. No malicious process running locally as the user should be able to manipulate the various tweaks and protections.

@celenity @Gnu1 you're welcome. Great to see the speedy response.

@GW72 wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2613800: > Thanks for the heads up, much appreciated. I always used `cp` as in `sudo cp -a phoenix.cfg /usr/lib/firefox/phoenix.cfg`. The `-a` is by habit (keeps the file attributes). In this case, I am the owner, not `root`. I think you misunderstand. These files are installed in system-wide paths. You want something else, e.g. `root` to be owner, instead of your regular user. No malicious process running locally as the user should be able to manipulate the various tweaks and protections. @celenity @Gnu1 you're welcome. Great to see the speedy response.

GW72 commented 2025年01月24日 05:40:00 +01:00

@doomedguppy wrote in #48 (comment):

I think you misunderstand. These files are installed in system-wide paths. You want something else, e.g. root to be owner, instead of your regular user. No malicious process running locally as the user should be able to manipulate the various tweaks and protections.

Yeah, I did misunderstand.

I think I am also conflating root "ownership" and root "installed or running as". I do not want to run Phoenix as root. So any clarification there would be great.

Phoenix config files do themselves connect/read directly to the internet, via Firefox, correct? I am not saying anything from Phoenix is malicious, but if it were (say some script is smuggled in), would not giving root ownership, actually introduce a worse security issue? I would rather only have to give up a regular user account over completely re-installing the OS.

Also, I only run Firefox as firejail --apparmor --caps.drop=all --private-cache firefox AND while not impossible, how likely is it, that someone develops malicious code, specifically for use with Phoenix (at least in these early days)?

Again, I am NOT saying anything with Phoenix is untoward (I wouldn't use it if I thought it was), I'm really not. And for the record, I really want this project to succeed, since it is finally a solution that actually does what it claims to on the tin.

And obviously, I have a lot to learn, so, I am very happy to be corrected (it is how I learn) so, don't hold back!

@doomedguppy wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2614682: > I think you misunderstand. These files are installed in system-wide paths. You want something else, e.g. `root` to be owner, instead of your regular user. No malicious process running locally as the user should be able to manipulate the various tweaks and protections. > Yeah, I did misunderstand. I think I am also conflating `root` "ownership" and `root` "installed or running as". I do not want to run Phoenix as `root`. So any clarification there would be great. Phoenix `config` files do themselves connect/read directly to the internet, via Firefox, correct? I am not saying anything from Phoenix is malicious, but if it were (say some `script` is smuggled in), would not giving `root` ownership, actually introduce a worse security issue? I would rather only have to give up a regular user account over completely re-installing the OS. Also, I only run Firefox as `firejail --apparmor --caps.drop=all --private-cache firefox` AND while not impossible, how likely is it, that someone develops malicious code, specifically for use with Phoenix (at least in these early days)? Again, I am NOT saying anything with Phoenix is untoward (I wouldn't use it if I thought it was), I'm really not. And for the record, I really want this project to succeed, since it is finally a solution that actually does what it claims to on the tin. And obviously, I have a lot to learn, so, I am very happy to be corrected (it is how I learn) so, don't hold back!

gallegonovato commented 2025年01月24日 12:12:05 +01:00

Good afternoon @celenity

One question, the cfg could be used to put in Mozilla on Windows if I am not mistaken...¿.

It would be copying it to home/USER/.var/app/org.mozilla.firefox/.mozilla/firefox/FIREFOX-PROFILE

And a question, I don't know if you are planning to create an .exe to install it in Windows (this question is asked me several times by a friend).

Best regards

Good afternoon @celenity One question, the `cfg` could be used to put in Mozilla on Windows if I am not mistaken...¿. It would be copying it to home/USER/.var/app/org.mozilla.firefox/.mozilla/firefox/FIREFOX-PROFILE And a question, I don't know if you are planning to create an `.exe` to install it in Windows (this question is asked me several times by a friend). Best regards

doomedguppy commented 2025年01月24日 17:38:09 +01:00

@GW72 wrote in #48 (comment):

@doomedguppy wrote in #48 (comment):

[..]
I think I am also conflating root "ownership" and root "installed or running as". I do not want to run Phoenix as root. So any clarification there would be great.

These files are not executed directly. They're firefox's way to express configuration of the firefox browser. The Phoenix config-files are readable but not executable. They're handled by firefox as you start firefox, and you'll typically start firefox as regular user. The config files are thus read as a regular user. My impression (though nothing more at this point) is that the files influence firefox's behavior, thus are restricted within those bounds.

@celenity will most likely be able to explain in a lot more detail.

Phoenix config files do themselves connect/read directly to the internet, via Firefox, correct? I am not saying anything from Phoenix is malicious, but if it were (say some script is smuggled in), would not giving root ownership, actually introduce a worse security issue? I would rather only have to give up a regular user account over completely re-installing the OS.

Referring to my answer above, the files are not themselves executable. If malicious content would be present, it would run as the regular user that is running firefox. The ownership is for the user managing access to the file, which is different from what it content means. I would prefer leaving extensions as an extra, but at the same time they are inspectable zip-files and you can check whether they have malicious content. Note that none of these files are executable themselves, and you don't set them executable with the file permissions. Owning them as root simply means that the regular user only has limited access to them.

Given that the files you "install", i.e. copy to their intended destination, are only config(-like) files, they'd have to come from the sources used for bootstrapping. You can inspect the files yourself. The overwhelming majority is setting (and locking) preferences.

If there are malicious intentions, they might be the haystack and you'll have to look for the needle. :-)

Also, I only run Firefox as firejail --apparmor --caps.drop=all --private-cache firefox AND while not impossible, how likely is it, that someone develops malicious code, specifically for use with Phoenix (at least in these early days)?

I think these comments are made with the assumption that 'Phoenix' scripts are executed as root. (See comments above.)
edit: I am not criticizing your choice to run within firejail. I simply point out, to the limits of my understanding, the meaning of the files.

Again, I am NOT saying anything with Phoenix is untoward (I wouldn't use it if I thought it was), I'm really not. And for the record, I really want this project to succeed, since it is finally a solution that actually does what it claims to on the tin.

Maybe you can ask @celenity .. though I doubt he'll give you an honest answer if he is hacking user's systems. :-P

And obviously, I have a lot to learn, so, I am very happy to be corrected (it is how I learn) so, don't hold back!

--

Note: I only share my first impressions. I would prefer to leave out the extensions if they turn out to be the predominant source of potential risk, exactly because that would (IMO) be able to severely reduce doubt for adoption.

@GW72 wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2614997: > @doomedguppy wrote in #48 (comment): > > [..] > I think I am also conflating `root` "ownership" and `root` "installed or running as". I do not want to run Phoenix as `root`. So any clarification there would be great. These files are not executed directly. They're firefox's way to express configuration of the firefox browser. The _Phoenix_ config-files are readable but not executable. They're handled by firefox as you start firefox, and you'll typically start firefox as regular user. The config files are thus read as a regular user. My _impression_ (though nothing more at this point) is that the files influence firefox's behavior, thus are restricted within those bounds. @celenity will most likely be able to explain in a lot more detail. > Phoenix `config` files do themselves connect/read directly to the internet, via Firefox, correct? I am not saying anything from Phoenix is malicious, but if it were (say some `script` is smuggled in), would not giving `root` ownership, actually introduce a worse security issue? I would rather only have to give up a regular user account over completely re-installing the OS. Referring to my answer above, the files are not themselves executable. If malicious content would be present, it would run as the regular user that is running firefox. The ownership is for the user managing _access to_ the file, which is different from what it content means. I would prefer leaving extensions as an extra, but at the same time they are inspectable zip-files and you can check whether they have malicious content. Note that none of these files are executable _themselves_, and you don't set them executable with the file permissions. Owning them as `root` simply means that the regular user only has limited access to them. Given that the files you "install", i.e. copy to their intended destination, are only config(-like) files, they'd have to come from the sources used for bootstrapping. You can inspect the files yourself. The overwhelming majority is setting (and locking) preferences. If there are malicious intentions, they might be the haystack and you'll have to look for the needle. :-) > Also, I only run Firefox as `firejail --apparmor --caps.drop=all --private-cache firefox` AND while not impossible, how likely is it, that someone develops malicious code, specifically for use with Phoenix (at least in these early days)? I think these comments are made with the assumption that 'Phoenix' scripts are executed as root. (See comments above.) edit: I am not criticizing your choice to run within `firejail`. I simply point out, to the limits of my understanding, the meaning of the files. > Again, I am NOT saying anything with Phoenix is untoward (I wouldn't use it if I thought it was), I'm really not. And for the record, I really want this project to succeed, since it is finally a solution that actually does what it claims to on the tin. Maybe you can ask @celenity .. though I doubt he'll give you an honest answer if he is hacking user's systems. :-P > And obviously, I have a lot to learn, so, I am very happy to be corrected (it is how I learn) so, don't hold back! -- Note: I only share my first impressions. I would prefer to leave out the extensions if they turn out to be the predominant source of potential risk, exactly because that would (IMO) be able to severely reduce doubt for adoption.

celenity commented 2025年01月25日 02:59:56 +01:00

My impression (though nothing more at this point) is that the files influence firefox's behavior, thus are restricted within those bounds.

Indeed. phoenix.cfg, phoenix-desktop.js, & policies.json are restricted within Firefox's bounds. Like you highlighted, these files aren't executable, they're handled by Firefox (which should be ran as a normal user), and they can't do anything Firefox doesn't explicitly allow them to (which is generally just configuring policies and preferences...).

I would prefer leaving extensions as an extra, but at the same time they are inspectable zip-files and you can check whether they have malicious content.

So, for extensions, we currently include uBlock Origin and Firefox Multi-Account Containers (which is developed by Mozilla...). We may remove Multi-Account Containers and leave that up to the user to install if they wish to, but uBlock Origin will always be included (unless we replace it with another content blocker, which is highly unlikely - or if Mozilla builds in content blocking that is just as effective...), due to the significant privacy, safety, and usability benefits.

I assume here that you're mainly referring to the search 'extensions' we include. You can find more details here on what they do, why they're added, etc. I'll specifically note that the extensions are signed, meaning that they're reviewed by Mozilla for ex. malicious content.

FYI: Mozilla is considering support for the SearchEngines policy on non-ESR releases, which would allow us to get rid of the search 'extensions' entirely. Why they allow installing and configuring extensions, yet consider configuring search engines too much of a privacy/security risk is beyond me... so I'm glad they're finally reconsidering their position on this.

It's also important to note that you can disable any extensions included by Phoenix, at any time.

Given that the files you "install", i.e. copy to their intended destination, are only config(-like) files, they'd have to come from the sources used for bootstrapping. You can inspect the files yourself. The overwhelming majority is setting (and locking) preferences.

If there are malicious intentions, they might be the haystack and you'll have to look for the needle. :-)

Indeed. The great thing is that the files are easy to examine and understand, even for folks who aren't technical. As we're using Phoenix configs in IronFox now as well, there are also a lot more eyes on our configs and Phoenix as a whole... meaning it'd be more difficult to sneak in anything malicious.

I am not criticizing your choice to run within firejail. I simply point out, to the limits of my understanding, the meaning of the files.

AFAICT your understanding is exactly correct, and I appreciate you taking the time to explain it so well. I also definitely recommend using some kind of sandboxing (Like Firejail) for Phoenix/Firefox (as well as your system in general...), and this is something we want to push more users to use if possible in the future, likely via some kind of onboarding or post-installation steps.

> My impression (though nothing more at this point) is that the files influence firefox's behavior, thus are restricted within those bounds. Indeed. `phoenix.cfg`, `phoenix-desktop.js`, & `policies.json` are restricted within Firefox's bounds. Like you highlighted, these files aren't executable, they're handled by Firefox *(which should be ran as a normal user)*, and they can't do anything Firefox doesn't explicitly allow them to *(which is generally just configuring policies and preferences...)*. > I would prefer leaving extensions as an extra, but at the same time they are inspectable zip-files and you can check whether they have malicious content. So, for extensions, we currently include uBlock Origin and Firefox Multi-Account Containers *(which is developed by Mozilla...)*. We may remove Multi-Account Containers and leave that up to the user to install if they wish to, but uBlock Origin will always be included *(unless we replace it with another content blocker, which is highly unlikely - or if Mozilla builds in content blocking that is just as effective...)*, due to the significant privacy, safety, and usability benefits. I assume here that you're mainly referring to the search 'extensions' we include. You can find more details [here](https://codeberg.org/celenity/Phoenix/wiki/Search.md) on what they do, why they're added, etc. I'll specifically note that the extensions are signed, meaning that they're reviewed by Mozilla for ex. malicious content. FYI: Mozilla [is considering](https://github.com/mozilla/policy-templates/issues/1132#issuecomment-2587999656) support for the `SearchEngines` policy on non-ESR releases, which would allow us to get rid of the search 'extensions' entirely. Why they allow installing and configuring extensions, yet consider configuring search engines too much of a privacy/security risk is beyond me... so I'm glad they're finally reconsidering their position on this. It's also important to note that you can disable any extensions included by Phoenix, at any time. > Given that the files you "install", i.e. copy to their intended destination, are only config(-like) files, they'd have to come from the sources used for bootstrapping. You can inspect the files yourself. The overwhelming majority is setting (and locking) preferences. > > If there are malicious intentions, they might be the haystack and you'll have to look for the needle. :-) Indeed. The great thing is that the files are easy to examine and understand, even for folks who aren't technical. As we're using Phoenix configs in [IronFox](https://ironfoxoss.org/) now as well, there are also a lot more eyes on our configs and Phoenix as a whole... meaning it'd be more difficult to sneak in anything malicious. > I am not criticizing your choice to run within firejail. I simply point out, to the limits of my understanding, the meaning of the files. AFAICT your understanding is exactly correct, and I appreciate you taking the time to explain it so well. I also definitely recommend using some kind of sandboxing *(Like Firejail)* for Phoenix/Firefox *(as well as your system in general...)*, and this *is* something we want to push more users to use if possible in the future, likely via some kind of onboarding or post-installation steps.

doomedguppy commented 2025年01月25日 03:50:34 +01:00

@celenity wrote in #48 (comment):

[..]

So, for extensions, we currently include uBlock Origin and Firefox Multi-Account Containers (which is developed by Mozilla...). We may remove Multi-Account Containers and leave that up to the user to install if they wish to, but uBlock Origin will always be included (unless we replace it with another content blocker, which is highly unlikely - or if Mozilla builds in content blocking that is just as effective...), due to the significant privacy, safety, and usability benefits.

uBlock origin is a great extension and highly valuable. Something like it is crucial.

I assume here that you're mainly referring to the search 'extensions' we include. You can find more details here on what they do, why they're added, etc. I'll specifically note that the extensions are signed, meaning that they're reviewed by Mozilla for ex. malicious content.

Ah, they're reviewed. That wasn't immediately obvious to me. (In retrospect, I did see indicators in the XPI-packages.) I think a small section "Why trust?" or something like it, early in the README, to highlight these points might well inspire trust, e.g.: (maybe with links to your information pages as "quick-start")

- uses Firefox's built-in mechanisms for managing configuration, (user) preferences, and application policies.
- installs extensions uBlock origin and Multi-account containers with pinned public keys.
- Offers an extensive list of blocklists.
- Consists only of configuration-files and mentioned extensions and assets.
You might want to consider running Firefox within firejail as security sandbox.

It's just an idea.

FYI: Mozilla is considering support for the SearchEngines policy on non-ESR releases, which would allow us to get rid of the search 'extensions' entirely. Why they allow installing and configuring extensions, yet consider configuring search engines too much of a privacy/security risk is beyond me... so I'm glad they're finally reconsidering their position on this.

Those are the first things I would disable for my personal use.

[..]

Indeed. The great thing is that the files are easy to examine and understand, even for folks who aren't technical. As we're using Phoenix configs in IronFox now as well, there are also a lot more eyes on our configs and Phoenix as a whole... meaning it'd be more difficult to sneak in anything malicious.

Sure, but don't underestimate how many preferences you're managing. There are a lot already. I knew about Arkenfox, but not all the rest of the preferences and policies you're working with.

[..]

AFAICT your understanding is exactly correct, and I appreciate you taking the time to explain it so well. I also definitely recommend using some kind of sandboxing (Like Firejail) for Phoenix/Firefox (as well as your system in general...), and this is something we want to push more users to use if possible in the future, likely via some kind of onboarding or post-installation steps.

Mentioning (something like) firejail in the section "Why trust?" that I suggested above, would also cover that concern. I think firejail is a good addition.

@celenity wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2617740: > [..] > > So, for extensions, we currently include uBlock Origin and Firefox Multi-Account Containers _(which is developed by Mozilla...)_. We may remove Multi-Account Containers and leave that up to the user to install if they wish to, but uBlock Origin will always be included _(unless we replace it with another content blocker, which is highly unlikely - or if Mozilla builds in content blocking that is just as effective...)_, due to the significant privacy, safety, and usability benefits. _uBlock origin_ is a great extension and highly valuable. Something like it is crucial. > I assume here that you're mainly referring to the search 'extensions' we include. You can find more details [here](https://codeberg.org/celenity/Phoenix/wiki/Search.md) on what they do, why they're added, etc. I'll specifically note that the extensions are signed, meaning that they're reviewed by Mozilla for ex. malicious content. Ah, they're reviewed. That wasn't immediately obvious to me. (In retrospect, I did see indicators in the XPI-packages.) I think a small section "_Why trust?_" or something like it, early in the README, to highlight these points might well inspire trust, e.g.: (maybe with links to your information pages as "quick-start") ``` - uses Firefox's built-in mechanisms for managing configuration, (user) preferences, and application policies. - installs extensions uBlock origin and Multi-account containers with pinned public keys. - Offers an extensive list of blocklists. - Consists only of configuration-files and mentioned extensions and assets. You might want to consider running Firefox within firejail as security sandbox. ``` It's just an idea. > FYI: Mozilla [is considering](https://github.com/mozilla/policy-templates/issues/1132#issuecomment-2587999656) support for the `SearchEngines` policy on non-ESR releases, which would allow us to get rid of the search 'extensions' entirely. Why they allow installing and configuring extensions, yet consider configuring search engines too much of a privacy/security risk is beyond me... so I'm glad they're finally reconsidering their position on this. Those are the first things I would disable for my personal use. > [..] > > Indeed. The great thing is that the files are easy to examine and understand, even for folks who aren't technical. As we're using Phoenix configs in [IronFox](https://ironfoxoss.org/) now as well, there are also a lot more eyes on our configs and Phoenix as a whole... meaning it'd be more difficult to sneak in anything malicious. Sure, but don't underestimate how many preferences you're managing. There are a lot already. I knew about Arkenfox, but not all the rest of the preferences and policies you're working with. > [..] > > AFAICT your understanding is exactly correct, and I appreciate you taking the time to explain it so well. I also definitely recommend using some kind of sandboxing _(Like Firejail)_ for Phoenix/Firefox _(as well as your system in general...)_, and this _is_ something we want to push more users to use if possible in the future, likely via some kind of onboarding or post-installation steps. Mentioning (something like) `firejail` in the section "Why trust?" that I suggested above, would also cover that concern. I think `firejail` is a good addition.

celenity commented 2025年01月25日 04:50:05 +01:00

I think including some sort of Why Trust? section in the README is a great idea, thank you for the suggestion! (as well as your other great feedback and much-appreciated insight here...)

I think including some sort of `Why Trust?` section in the `README` is a great idea, thank you for the suggestion! *(as well as your other great feedback and much-appreciated insight here...)*

GW72 commented 2025年01月25日 05:55:21 +01:00

@doomedguppy thanks very much for your contributions. What you wrote makes clear sense.

So, for the record, I have changed how I copy the config files phoenix.cfg, phoenix-desktop.js, & policies.json with the following (notice the -a has been dropped):

sudo cp phoenix.cfg /usr/lib/firefox/phoenix.cfg

sudo cp phoenix-desktop.js /usr/lib/firefox/defaults/pref/phoenix-desktop.js

sudo cp policies.json /usr/lib/firefox/distribution/policies.json

This way, the files are owned by root. It is the smartest move, as far as I can see, from reading everything above.

I appreciate the discussion, even if it clearly demonstrates I don't know what I'm doing(!) in some respects. When it comes to many things "internet", I am nothing more than a caveman looking at fire for the first time (it is in some ways a very apt depiction)!! I didn't know how to view the files (i.e. config vs executable) and so erroneously viewed the configs in the same way as executables. And that is an important distinction to keep clear, even if Phoenix directly connects to files beyond my box (yes, anyone can look what it contains, and yes, worst case, if fiddled with, it could mess with uBO, but I would say it is low risk with small hazard potential, at worst):

defaultPref("librewolf.uBO.assetsBootstrapLocation", "https://phoenix.celenity.dev/uBlock/assets.json")

As for trust, well, that is a tough one. I can only say, the internet is a very strange place. @celenity has however, taken every issue presented with consideration and clarity and even made changes to improve upon the way in which Phoenix delivers its functionality. @doomedguppy do have a look in these issues threads, since in the not too distant past, some very interesting explanations were provided by @celenity after being challenged with various concerns. This person seems to have a real belief in what they do, and also a deep understanding of all the moving parts. In my (weak) experience here, @celenity has been extremely patient and very, very, helpful.

@doomedguppy thanks very much for your contributions. What you wrote makes clear sense. So, for the record, I have changed how I copy the config files `phoenix.cfg`, `phoenix-desktop.js`, & `policies.json` with the following (notice the `-a` has been dropped): `sudo cp phoenix.cfg /usr/lib/firefox/phoenix.cfg` `sudo cp phoenix-desktop.js /usr/lib/firefox/defaults/pref/phoenix-desktop.js` `sudo cp policies.json /usr/lib/firefox/distribution/policies.json` This way, the files are owned by `root`. It is the smartest move, as far as I can see, from reading everything above. I appreciate the discussion, even if it clearly demonstrates I don't know what I'm doing(!) in some respects. When it comes to many things "internet", I am nothing more than a caveman looking at fire for the first time (it is in some ways a very apt depiction)!! I didn't know how to view the files (i.e. config vs executable) and so erroneously viewed the configs in the same way as executables. And that is an important distinction to keep clear, even if Phoenix directly connects to files beyond my box (yes, anyone can look what it contains, and yes, worst case, if fiddled with, it could mess with uBO, but I would say it is low risk with small hazard potential, at worst): `defaultPref("librewolf.uBO.assetsBootstrapLocation", "https://phoenix.celenity.dev/uBlock/assets.json")` As for trust, well, that is a tough one. I can only say, the internet is a very strange place. @celenity has however, taken every `issue` presented with consideration and clarity and even made changes to improve upon the way in which Phoenix delivers its functionality. @doomedguppy do have a look in these `issues` threads, since in the not too distant past, some very interesting explanations were provided by @celenity after being challenged with various concerns. This person seems to have a real belief in what they do, and also a deep understanding of all the moving parts. In my (weak) experience here, @celenity has been extremely patient and very, very, helpful.

doomedguppy commented 2025年01月25日 21:00:41 +01:00

@GW72 wrote in #48 (comment):

@doomedguppy thanks very much for your contributions. What you wrote makes clear sense.

[..]

This way, the files are owned by root. It is the smartest move, as far as I can see, from reading everything above.

It is. Ownership means who primarily controls (access to) the file. When root is owner and others can only read, then any malware can discover all the ways firefox is a problem, but not make any changes to remove the problem.

I appreciate the discussion, even if it clearly demonstrates I don't know what I'm doing(!) in some respects. When it comes to many things "internet", I am nothing more than a caveman looking at fire for the first time (it is in some ways a very apt depiction)!! I didn't know how to view the files (i.e. config vs executable) and so erroneously viewed the configs in the same way as executables. And that is an important distinction to keep clear, even if Phoenix directly connects to files beyond my box (yes, anyone can look what it contains, and yes, worst case, if fiddled with, it could mess with uBO, but I would say it is low risk with small hazard potential, at worst):

defaultPref("librewolf.uBO.assetsBootstrapLocation", "https://phoenix.celenity.dev/uBlock/assets.json")

The worst here, is provide a bunch of ineffective lists or lists that block sites you care about, so you'll notice.

If you want to be more cautious, then disable "cosmetic changes". Those tweak web-page content. That way, a blocklist only stops you from accessing resources, but is not able to manipulate pages.

As for trust, well, that is a tough one. I can only say, the internet is a very strange place. @celenity has however, taken every issue presented with consideration and clarity and even made changes to improve upon the way in which Phoenix delivers its functionality. @doomedguppy do have a look in these issues threads, since in the not too distant past, some very interesting explanations were provided by @celenity after being challenged with various concerns. This person seems to have a real belief in what they do, and also a deep understanding of all the moving parts. In my (weak) experience here, @celenity has been extremely patient and very, very, helpful.

Sure, I see things I like. That's why I spend some time to contribute. I like the approach of locking settings that are dangerous, counter-productive or misleading, outdated for example.

@GW72 wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2623526: > @doomedguppy thanks very much for your contributions. What you wrote makes clear sense. > > [..] > > This way, the files are owned by `root`. It is the smartest move, as far as I can see, from reading everything above. It is. Ownership means who primarily controls (access to) the file. When `root` is owner and others can only read, then any malware can discover all the ways firefox is a problem, but not make any changes to remove the problem. > I appreciate the discussion, even if it clearly demonstrates I don't know what I'm doing(!) in some respects. When it comes to many things "internet", I am nothing more than a caveman looking at fire for the first time (it is in some ways a very apt depiction)!! I didn't know how to view the files (i.e. config vs executable) and so erroneously viewed the configs in the same way as executables. And that is an important distinction to keep clear, even if Phoenix directly connects to files beyond my box (yes, anyone can look what it contains, and yes, worst case, if fiddled with, it could mess with uBO, but I would say it is low risk with small hazard potential, at worst): > > `defaultPref("librewolf.uBO.assetsBootstrapLocation", "https://phoenix.celenity.dev/uBlock/assets.json")` The worst here, is provide a bunch of ineffective lists or lists that block sites you care about, so you'll notice. If you want to be more cautious, then disable "cosmetic changes". Those tweak web-page content. That way, a blocklist only stops you from accessing resources, but is not able to manipulate pages. > As for trust, well, that is a tough one. I can only say, the internet is a very strange place. @celenity has however, taken every `issue` presented with consideration and clarity and even made changes to improve upon the way in which Phoenix delivers its functionality. @doomedguppy do have a look in these `issues` threads, since in the not too distant past, some very interesting explanations were provided by @celenity after being challenged with various concerns. This person seems to have a real belief in what they do, and also a deep understanding of all the moving parts. In my (weak) experience here, @celenity has been extremely patient and very, very, helpful. Sure, I see things I like. That's why I spend some time to contribute. I like the approach of locking settings that are dangerous, counter-productive or misleading, outdated for example.

celenity commented 2025年01月31日 20:01:27 +01:00

FYI: I believe I've come up with a solution that should address the concerns described above for our assets.json & search 'extensions'. @doomedguppy Curious to hear your thoughts...

From: https://github.com/celenityy/Phoenix/issues/4#issuecomment-2627740229

I understand your point, and I believe I have a solution for this. This would apply to both the assets.json & our search 'extensions'.

What we can probably do is still grab the files off Codeberg (or possibly GitLab if it's better suited), but we could probably specify a specific commit instead of just grabbing the latest version. For instance, with the assets.json, instead of using https://phoenix.celenity.dev/uBlock/assets.json (or https://codeberg.org/celenity/Phoenix/raw/branch/pages/uBlock/assets.json - which imo would have the same risk...), we could use https://codeberg.org/celenity/Phoenix/raw/commit/08d147ee865c1d740540e8ec83c758d7a4df3e8b/uBlock/assets.json?

The downside with this approach would be that it's no longer possible to update these files out of band; meaning we'd have to push out full Phoenix updates for changes to these files. I don't think this is a big deal for the search 'extensions' - as they're just basic config files that only need to be updated on rare/special occasions, if ever. The assets.json file is different, but it likely doesn't need immediate, out of band updates either - with only minor changes on occasion. We also still include our own remote badlists filter anyways, so we could still protect users rapidly in the case of ex. malicious blocklists.

FYI: I believe I've come up with a solution that should address the concerns described above for our `assets.json` & search 'extensions'. @doomedguppy Curious to hear your thoughts... From: https://github.com/celenityy/Phoenix/issues/4#issuecomment-2627740229 > I understand your point, and I believe I have a solution for this. This would apply to both the `assets.json` & our search 'extensions'. > > What we can probably do is still grab the files off Codeberg *(or possibly GitLab if it's better suited)*, but we could probably specify a specific commit instead of just grabbing the latest version. For instance, with the `assets.json`, instead of using `https://phoenix.celenity.dev/uBlock/assets.json` *(or `https://codeberg.org/celenity/Phoenix/raw/branch/pages/uBlock/assets.json` - which imo would have the same risk...)*, we could use `https://codeberg.org/celenity/Phoenix/raw/commit/08d147ee865c1d740540e8ec83c758d7a4df3e8b/uBlock/assets.json`? > > The downside with this approach would be that it's no longer possible to update these files out of band; meaning we'd have to push out full Phoenix updates for changes to these files. I don't think this is a big deal for the search 'extensions' - as they're just basic config files that only need to be updated on rare/special occasions, if ever. The `assets.json` file is different, but it likely doesn't need immediate, out of band updates either - with only minor changes on occasion. We also still include our own remote [badlists](https://phoenix.celenity.dev/uBlock/badlists.txt) filter anyways, so we could still protect users rapidly in the case of ex. malicious blocklists.

doomedguppy commented 2025年01月31日 22:01:19 +01:00

@celenity wrote in #48 (comment):

FYI: I believe I've come up with a solution that should address the concerns described above for our assets.json & search 'extensions'. @doomedguppy Curious to hear your thoughts...

From: https://github.com/celenityy/Phoenix/issues/4#issuecomment-2627740229

I understand your point, and I believe I have a solution for this. This would apply to both the assets.json & our search 'extensions'.
What we can probably do is still grab the files off Codeberg (or possibly GitLab if it's better suited), but we could probably specify a specific commit instead of just grabbing the latest version. For instance, with the assets.json, instead of using https://phoenix.celenity.dev/uBlock/assets.json (or https://codeberg.org/celenity/Phoenix/raw/branch/pages/uBlock/assets.json - which imo would have the same risk...), we could use https://codeberg.org/celenity/Phoenix/raw/commit/08d147ee865c1d740540e8ec83c758d7a4df3e8b/uBlock/assets.json?

I would definitely prefer this. It makes each installation (more) predictable. In case of updates to assets, you can always make a new commit/release, and the assets and extensions are one-shot installations anyways. It makes it possible to track which (version of) files would've been downloaded. Others who do the installation can with some confidence claim that it worked for them and/or they checked it, so offers a (larger) basis of trust.

The downside with this approach would be that it's no longer possible to update these files out of band; meaning we'd have to push out full Phoenix updates for changes to these files. I don't think this is a big deal for the search 'extensions' - as they're just basic config files that only need to be updated on rare/special occasions, if ever. The assets.json file is different, but it likely doesn't need immediate, out of band updates either - with only minor changes on occasion. We also still include our own remote badlists filter anyways, so we could still protect users rapidly in the case of ex. malicious blocklists.

The asset-file is for bootstrapping. I think it's only downloaded once, to get uBlock Origin started with an initial set? I don't see a big problem, but I don't maintain the assets.

Maybe ask yourself if that's where you want to provide your value? I would think offering the selection of preferences and policies in a package that is trustworthy, offers more value than (having to) maintain the assets-file. (Note that, you will always still have a problem that you cannot really guarantee the quality of any of the block-lists in the assets-file. You can at best add promising blocklists and remove disappointing blocklists. It makes sense to do that in a release, right?)

How often are those assets changes urgent? Otherwise, just ship them when the next iteration comes around.

@celenity wrote in https://codeberg.org/celenity/Phoenix/issues/48#issuecomment-2665313: > FYI: I believe I've come up with a solution that should address the concerns described above for our `assets.json` & search 'extensions'. @doomedguppy Curious to hear your thoughts... > > From: https://github.com/celenityy/Phoenix/issues/4#issuecomment-2627740229 > > > I understand your point, and I believe I have a solution for this. This would apply to both the `assets.json` & our search 'extensions'. > > What we can probably do is still grab the files off Codeberg _(or possibly GitLab if it's better suited)_, but we could probably specify a specific commit instead of just grabbing the latest version. For instance, with the `assets.json`, instead of using `https://phoenix.celenity.dev/uBlock/assets.json` _(or `https://codeberg.org/celenity/Phoenix/raw/branch/pages/uBlock/assets.json` - which imo would have the same risk...)_, we could use `https://codeberg.org/celenity/Phoenix/raw/commit/08d147ee865c1d740540e8ec83c758d7a4df3e8b/uBlock/assets.json`? I would definitely prefer this. It makes each installation (more) predictable. In case of updates to assets, you can always make a new commit/release, and the assets and extensions are one-shot installations anyways. It makes it possible to track which (version of) files would've been downloaded. Others who do the installation can with some confidence claim that it worked for them and/or they checked it, so offers a (larger) basis of trust. > > The downside with this approach would be that it's no longer possible to update these files out of band; meaning we'd have to push out full Phoenix updates for changes to these files. I don't think this is a big deal for the search 'extensions' - as they're just basic config files that only need to be updated on rare/special occasions, if ever. The `assets.json` file is different, but it likely doesn't need immediate, out of band updates either - with only minor changes on occasion. We also still include our own remote [badlists](https://phoenix.celenity.dev/uBlock/badlists.txt) filter anyways, so we could still protect users rapidly in the case of ex. malicious blocklists. The asset-file is for bootstrapping. I think it's only downloaded once, to get uBlock Origin started with an initial set? I don't see a big problem, but I don't maintain the assets. Maybe ask yourself if that's where you want to provide your value? I would think offering the selection of preferences and policies in a package that is trustworthy, offers more value than (having to) maintain the assets-file. (Note that, you will always still have a problem that you cannot really guarantee the quality of any of the block-lists in the assets-file. You can at best add promising blocklists and remove disappointing blocklists. It makes sense to do that in a release, right?) How often are those assets changes _urgent_? Otherwise, just ship them when the next iteration comes around.

celenity commented 2025年01月31日 22:14:28 +01:00

Thanks for the feedback @doomedguppy, 100% agreed.

Thanks for the feedback @doomedguppy, 100% agreed.