Subject:
stackable wrappers
Draft:
https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt
TODO:
- improve draft
- send to debian-devel mailing list
- discuss on debian-devel
Subject:
stackable wrappers
Draft:
https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt
TODO:
I am done editing for now. Any things in the draft unclear? Any suggestions. Please post them here or edit the ticket.
Well written. I made a small change to make it clear that none of the options we have now are any good.
amend PATH environment variable by package would be a good solution from my point of view.
They did not like my /etc/environment.d feature request.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704054
And this might require modifying similar packages and long standing implementations.
Can you think of good general use cases / combinations as show cases?
Your real-world example is a good one. Also your scurl script to enforce HTTPS (good selling point even if effectiveness debatable) also apt wrapper scripts for special purposes?
scurl is a separate command because enforcing that always would break things. A wrapper but not one of the kind like the uwt/torsocks wrappers that get used on every invocation.
apt-get wrappers are also separate scripts. apt-get-wrapper currently only supports apt-get update. It's not applied on every manual invocation by the user (or system). That could break some things.
This is a great idea!
One thought I had that is not too related to the actual "wrapping", but might be important: my concern here is how this will be presented/documented to Tor users which gives the idea that "wrapping" an app with, for example, torsocks makes it "Tor-ready". As it is discussed in the Torify HOWTO [0], there are quite a few aspects to be taken into account in order to torify an application. One silly example would be having an app that for some reason adds your real IP to its headers and once it is wrapped it now anonymously transmits your real IP.
(I know you guys know this and there are certainly lots of references to this in Whonix' docs, but thought it wouldn't hurt to mention)
Thanks!
[0]: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO
dau (Felipe Dau):
dau added a comment.
This is a great idea!
Thanks for the feedback!
One thought I had that is not too related to the actual "wrapping", but might be important: my concern here is how this will be presented/documented to Tor users which gives the idea that "wrapping" an app with, for example, `torsocks` makes it "Tor-ready". As it is discussed in the Torify HOWTO [0], there are quite a few aspects to be taken into account in order to torify an application. One silly example would be having an app that for some reason adds your real IP to its headers and once it is wrapped it now anonymously transmits your real IP.
I'd say it's out of scope here. torsocks only serves as one example
among others here on how one might like to use multiple wrappers at once
by stacking them. The decision to use/not use torsocks on a non-Whonix
system is up the user. Any and torsocks leak issues are torsocks' bugs.
I'd like to focus this proposal on stackable wrappers generally and
avoid anything Tor specific with the goal for getter better feedback on
the proposal.
Actually, if there was a good answer to this, then there would be much
less need for Whonix. In Whonix we use torsocks only on a best effort
basis for stream isolation. However, in Whonix, if torsocks leaks
something, it's not catastrophic, since it leaks through Tor, not clear.net
I believe it is not torsocks' fault, but the app's for "not knowing how to be anonymous". In the end, it is really the user's fault for not knowing what they were doing.
Actually, if there was a good answer to this, then there would be much
less need for Whonix. In Whonix we use torsocks only on a best effort
basis for stream isolation. However, in Whonix, if torsocks leaks
something, it's not catastrophic, since it leaks through Tor, not clear.net
Right. Although I think that leaking identifying information through Tor is just as bad.
Going a bit more off-topic:
I'd like to focus this proposal on stackable wrappers generally and
avoid anything Tor specific with the goal for getter better feedback on
the proposal.
Whoops.
Regarding the proposal:
It is not clear to me how to actually specify the wrapping. For example:
Thanks!
Right. torsocks is somewhere in between. It's useful for experts who know what they are doing or for users where it does not matter so much if DNS leaks or so. By simply prepending torsocks one can never get the same quality and assurances compared to more and more Tor/privacy-aware-by-default applications nowadays.
Going a bit more off-topic:
- It's surprising that there is not a single warning in torsocks' docs/manual about how dangerous it can be to torify an app when you don't know how it works
Right. (Feel free to report a bug against http://trac.torproject.org torsocks component.)
- Is there documentation on "how to torify/make apps Whonix friendly/compliant"?
Just now created a discussion https://forums.whonix.org/t/best-practices-on-how-to-make-your-application-anonymity-privacy-whonix-friendly for it.
Regarding the proposal:
It is not clear to me how to actually specify the wrapping. For example:
- What should be the contents of /etc/wrapper.d/30_usr.bin.gpg_torsocks.conf? Something like torsocks * ?
- What about /etc/wrapper.d/30_usr.bin.zeronet_tor.conf? * --tor?
Good question. Undecided. Indeed, this draft is not as well specified as the convention in T635. Perhaps similar to T635 wrt include and config folder locations. The goal I had in mind when posting this is to have an open discussion on debian-devel and get some pointers which of the multiple suggested implementation paths are favored.
Good idea. Thanks!
Just now created a discussion https://forums.whonix.org/t/best-practices-on-how-to-make-your-application-anonymity-privacy-whonix-friendly for it.
Great!
Good question. Undecided. Indeed, this draft is not as well specified as the convention in T635. Perhaps similar to T635 wrt include and config folder locations. The goal I had in mind when posting this is to have an open discussion on debian-devel and get some pointers which of the multiple suggested implementation paths are favored.
I see. Then I think it would be useful to have a note there asking "how exactly should the wrapping be specified by the .conf files?" or something like that. What do you think?
Thanks!
Added How the wrappers would be specified in the config language is yet to be invented, which will be done if this implementation path looks favorable. does that sound alright to you?
I noticed the link in the description needs to be updated. Would you change to https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt?