search

undergroundwires / privacy.sexy

Open-source tool to enforce privacy & security best-practices on Windows, macOS and Linux, because privacy is sexy
https://privacy.sexy
GNU Affero General Public License v3.0
4.09k stars 174 forks source link

To be able to know the enabled state of a feature on the OS #307

Open marcello-pietrobon opened 9 months ago

marcello-pietrobon commented 9 months ago

Problem description

Privacy.sexy is very well done. Each category shows in a tree view the features that we want to apply, or revert.

The only thing is that at the moment we don't have a way to know if a feature has been disabled or not. And I don't think is humanly possible to remember for a user what he has previously tweaked or not

Proposed solution

It would be great if for example the checkboxes would be able to signal the enabled state of its related feature.

I have no idea how this could be implemented, and I'm afraid this could be an overkill for the privacy.sexy app.

Still, I would like to know if someone has thought about this and if they do exist some possible solution to it.

Alternatives considered

Additional information

marcello-pietrobon commented 9 months ago

Related

undergroundwires commented 9 months ago

Hi @marcello-pietrobon, thank you for your great idea and nice words. Your suggestion is valuable.

Implementing this feature is quite doable. Most scripts in privacy.sexy are built on shared functions, visible in the collection files. Introducing an audit (check: script..) for one of the functions would give the status indication for many scripts, making the feature easily achievable.

One challenge is the requirement for higher privileges for some checks. privacy.sexy is designed to run without administrative privileges, see "Privilege Management" in SECURITY.md. A practical solution could involve asking for administrative rights only for these specific checks, perhaps through a separate, specialized process. Starting with checks that don't need elevated privileges seems like a good first step.

As the sole developer and maintainer, doing this in free time without funding to cover costs, I have limited resources. Even though not so fun, I focus on the app's stability and reliability, a major goal for the past year. While there are some quick win features to address (you already linked some of them), your suggestion is on my list for future updates, though I can't promise a timeline.

We should refine the UI for this. How do we display the OK/NEEDED status on tree items without cluttering the interface? The goal is to keep it clean and user-friendly.

marcello-pietrobon commented 9 months ago

To work on a project like this demands a lot from personal life and it's something each one of us can sustain only for a limited amount of years. After that we hope for other people take over. I can't thank you enough for that, and I'll consider a donation in the future, I really cannot these days. (I think there should be a line to https://github.com/sponsors/undergroundwires in the 'privacy' dialog that we see on the very bottom right of the privacy.sexy application).

marcello-pietrobon commented 9 months ago

A practical solution could involve asking for administrative rights only for these specific checks, perhaps through a separate, specialized process. Starting with checks that don't need elevated privileges seems like a good first step.

I agree.

We should refine the UI for this. How do we display the OK/NEEDED status on tree items without cluttering the interface? The goal is to keep it clean and user-friendly.

I need to let my mind flow few days about this. I'll get back to this,

marcello-pietrobon commented 8 months ago

I finally got to think better about this. It's simple and probably the same idea everyone would think, which is simply to give a lighter blue color to the lines of the options that Privacy.Sexy already has successfully acted to.

(*) What the user chooses with the checkbox and what has been already applied are very much independent information and if we would merge them in one single color in the checkbox we would end up having too many color possibilities in order to represent all combined cases.


The lines representing each item in the list would have three possible colors, all of them with just a luminosity variation of the same hue of blue:

  1. The current blue: not applied yet
  2. The lighter blue: successfully applied
  3. An intermediate light blue: not implemented yet.


Of course you don't have to follow this idea. Others may be better.