[Privoxy-devel] Future of Privoxy and comparison to mitmproxy

[Lee]

Yes, the license is a problem.  I have absolutely no desire to work for free on a MIT licensed project.

It seems like mitmproxy is not a service.  Not entirely a deal-breaker ... I used to start tor & vidalia, edit the privoxy config file and =then= start FF to browse the web using tor.  But still.. having it as an always-on service would be better.

It's not clear how easy it would be to convert a host file to something mitmproxy would block.  I'm not planning on using mitmproxy, so I didn't look into it all that much, but if I was seriously thinking about using mitmproxy a hostfile => mitmproxy block (file? rules?) would be an absolute requirement.

Lee


------- Original Message -------
On Tuesday, August 1st, 2023 at 3:00 PM, Ian Silvester wrote:

> Hi Frank,
> 
> I can see the benefits of the idea - it would free the Privoxy project from dealing with the transmission protocol to allow focus on the core filtering and blocking functionality - however I can see two issues:
> 
> - licence incompatibility - Privoxy is GPL whilst mitmproxy is MIT. The MIT license allows downstream proprietary use whilst Privoxy cleaves to the 'free software' path of expecting downstream usage to also be free.
> - mitmproxy add-ons are written in Python whilst Privoxy is C - wouldn't such a move imply rewriting Privoxy?
> 
> Despite these potential issues I am very interested to hear what other developers think of this proposal.
> 
> Ian
> 
> 
> On Mon, 31 Jul 2023, at 18:55, Frank Herbrand wrote:
> 
> > Dear developers,
> > 
> > Privoxy has been available for a very long time now and is constantly
> > being developed. I would venture to guess that the developers, as well
> > as the users, are on average as old as I am. For the last few years,
> > almost all WWW communication has been encrypted via https. Privoxy has
> > launched https inspection for this purpose. The necessary transfer of
> > the "certificate authority" into the client applications is likely to be
> > an increasing problem, since it is precisely this hacker trick that is
> > taken into account as a risk in the clients.
> > 
> > The team around mitmproxy, as the integration of a proxy as a
> > man-in-the-middle, has put a lot of effort into their project to meet
> > this challenge.
> > 
> > Wouldn't it make sense for Privoxy to be "merged" into a mitmproxy
> > plugin in the future that makes the previous extensive filtering and
> > blocking features "crisis-proof" in this way with regard to current and
> > future browser security standardisations?
> > 
> > What do you think about the feature development and use cases of Privoxy
> > in comparisopn to mitmproxy?
> > 
> > Best regards,
> > 
> > Frank
> > 
> > _______________________________________________
> > Privoxy-devel mailing list
> > Privoxy-devel at lists.privoxy.org
> > https://lists.privoxy.org/mailman/listinfo/privoxy-devel
> 
> _______________________________________________
> Privoxy-devel mailing list
> Privoxy-devel at lists.privoxy.org
> https://lists.privoxy.org/mailman/listinfo/privoxy-devel