On Sun, May 30, 2010 at 9:48 PM, Fabian Keil <fk@...> wrote:
> The GUI should only be visible to the user if the Privoxy service
> doesn't have its own userid or if it has been granted access to
> the user's desktop.
I would not rely on that. In my opinion, since the resources for the
GUI are created at launch time, it's a matter of patience and good
skills for a hacker to bring the GUI out!
> I agree that the GUI code should be separated from the rest of Privoxy.
> In fact I think the current GUI code should be thrown away and replaced
> with a GUI application that works cross-platform. However as far as I'm
> concerned this has nothing to do with the proposed patch.
Well, I think it does. I have also thought of the security. About the
binary executable GUI, I think it may be dropped entirely since there
is one when connecting via the web browser! As far as I could see,
this GUI is used mainly to watch the logs and to launch some
applications in order to edit the configuration files. Watching the
logs may also be done in the command line by launching privoxy with a
debug flag. Editing the configuration files may be done directly, with
a text editor, because privoxy has the nice feature of watching them
and reloading if necessary. They may also be edited via the web
> If by "portable apps" you mean an application that is run without
> being installed first, then I don't think that's true. Separating
> Privoxy from the "Privoxy GUI" should be sufficient.
The things as I see them now are quite simple and they should be kept
that way if we want a greater degree of portability (between OSes).
Privoxy should have 3 running modes: a service/daemon one, an user
application one and a debug one. Each one should be triggered with
command line parameters. On the security side, maybe a password
restriction should be implemented on the web interface.