Small nitpick change, using internal rather than external links. (Don’t worry about such small issues.)
Thank you so much for your tip, Patrick! One advantage of using internal links is that when users are browsing from .onion wiki, they do not have to jump out to clearnet.
I agree with you. The case you mentioned happens a lot. People are often not aware of the censorship when the environment is “so free” or too unfree.
No problem! I will make the anon-connection-wizard based on the UX paper and try to ask the UX teams opinions on how to provide the support of third-party censorship circumvention tools in the wizard.
I have tried to contact the UX team through the ticket. But I have not gotten response. Do you have any suggested place I can jump to? Maybe tbb-dev@ ? I have tried to mention the issue on several places, so do you think it will be rude to mention it again, Patrick?
Talking on some Tor IRC channels would be very much worth trying. Maybe you’re lucky and even Linda is there. Please tell me how that goes.
Thank you so much for your suggestion! I will let you know the result very soon!
Thank you for informing me this, Patrick! I have read all the discussion in the tickets.
I have not looked at the latest implementation of torrc.d yet, so I assume what has been implemented is the same as what Hans proposed:
Weasel and I (aka Hans) sketched out how we would use it in the Debian package, closely following the Apache pattern but with naming that is more appropriate in Tor:
These dirs are present for the actual snippet files:
These dirs include relative symlinks to *-available:
/etc/tor/services-enabled/sparkleshare.torrc --> …/services-available/sparkleshare.torrc
The sparkleshare package would include:
The davical package would include:
Please correct me if I am wrong, the
/etc/tor/services-instances/anon-connection-wizard.torrc are the two files that are expected to be generated by the anon-connection-wizard.
Still, I am not sure how the Tor will actually handle the priorities of and potential conflicts between different .torrc files.
It seems that the priority of anon-connection-wizard.torrc should be lower than
/etc/tor/torrc so that we can still suggest users who want to configure the Tor manually editing the
Or we can suggest users who want to configure the Tor manually editing a .torrc file that has very high priority instead.
I don’t know if we still need the edit marker approach for a transitional period. Depends on when the Tor version supporting that feature will enter deb.torproject.org stretch repository. Could you find that out please?
I don’t know that. Could you please ask in that ticket?
Sure thing! Done!
I don’t know how long it will take to get an answer so I will work on other implementation first (like UI implementation based on Linda’s paper).
Also, the edit marker approach seems not to be a large amount of work (just a file IO), so it is fine for me to take it as a transitional approach if we still do not get the response back.
Could you create a Whonix phabricator please?
Please check this out.
Would you like to write a Whonix blog post announcing your GSoC anon-connection-wizard project? Just very briefly to announce it with references. You could reuse some other announcement text used elsewhere already.
Please check out https://phabricator.whonix.org/T676 as well.
@iry Please keep me updated on your progress! (So I can provide feedback on writing & usability).
A small discussion related to the anon-connection-wizard happened at #tor-dev on May 30.
The benefits of adopting anon-connection-wizard as new generation of the Tor launcher is better compatibility with future sandboxing wirk.
Full chat log can be seen here.
18:32:07 A related issue is something I was discussing with Yawning a couple of days ago, as a result of his email thread on tbb-dev.
18:32:31 He’s wondering how the tor-launcher automation fits in with sandboxing.
18:32:53 That is, his sandbox approach probably requires a separate-process tor-launcher.
18:33:51 So the question is whether the new UI should be developed in the same JS extension or as a new separate program using QT or similar.
18:34:57 Or possibly iry’s python-based project would be a way to do it.
18:35:54 Anyway I don’t have an opinion, but it seems like a valid question.
18:36:26 hm. so the ui for tor launcher won’t be radically different with the automation
18:36:46 there will be some dialogs moved/adapted but that’s probably it
18:37:29 I think sandboxing may drive us to a different (non XUL) solution but we do not understand all of the requirements yet (basically what GeKo said in that tbb-dev email thread).
18:37:32 And where will the code for the automation itself live? Inside tor-launcher JS or in tor?
18:37:38 there will be more effort needed under the hood to get the automation part going properly
18:38:56 i think the main part will live in tor-launcher for the time being
18:39:32 i doubt we will have the pieces for the new archtiecture ready to start with that one and get the deliverables done until later this year
18:39:58 oh, “until” is probably wwrong
18:40:18 what i meant was we have deliverables to do and the automation is part of those
18:40:29 and we have time to november
18:40:48 If we also try to re-write in QT we will probably fail to deliver on time (that’s my guess anyway).
18:40:55 (nit that I like QT)
18:41:15 yeah, that’s what i meant
18:41:30 Right. I think Yawning’s concern was about duplicated effort. And also maybe delaying adoption of the sandbox.
18:42:03 well, yes, but this kind of duplicated effort can’t be avoided it seems to me, alas
18:42:20 Because of the deliverables schedule?
18:42:52 the adoption of the sandbox is probably not delayed due to the automation effort
18:43:11 i mean we don’t have anybody working on the sandboxing stuff right now
18:43:30 nor do we have the money for that at the moment i think
18:43:56 so what we need is a plan first, then break that one down to pieces
18:44:08 we can use to apply for money with
18:44:28 at least that’s how i see it currently
18:44:42 I think we should try to find time to work on the plan (and then ask for money or shift priorities or whatever). I think that is what everyone is saying.
The tbb team has already had a work around solution to the drop of support of XUL/XPCOM-based extensions. So anon-connection-wizard is not an essential/competitive candidate in that case.
18:29:19 and it seems mozilla will drop the support of the Tor launcher
18:29:35 so I am wondering what’s the plan for TBB team?
18:29:53 iry: Do you mean because of WebExtensions?
18:30:26 we can work around that for the time being
18:30:49 let me find you the comment and the ticket
18:31:25 #17248, comment 16
Sure! It is a great honor to me to post on the Whonix blog!
Hi Patrick! I have done two pull requests related to the issue in the ticket.
Hi @JasonJAyalaP ! Thank you so much for offering me feedback!
This is my fork of anon-connection-wizard:
Currently, I has been working on the “edit mark approach”. And hopefully I can push the commit to my repository in 24h.
Looking forward to further discussion with you!
I joined the #tor-dev irc meeting for tbb today, the following is some log related to anon-connection-wizard:
<arthuredelstein> We're interested in sandboxing on Linux, Mac, and Windows. <arthuredelstein> And one of the things we might want is a new tor-launcher in a separate process. <arthuredelstein> So if your python implementation is going to fit the bill, it would need to work on all 3 platforms <arthuredelstein> (Sorry if I'm just repeating what you already know!) <arthuredelstein> And, if you're interested in getting feedback on it, I'd be happy to take a look at it. <arthuredelstein> (I'm a Tor Browser dev)
As @Patrick said, anon-connection-wizard should be general purpose that can run in many platform. Currently, it is Whonix support only. It even doesn’t work in debian, since it lack the
guimessage module and
I am lack of knowledge on how to make the dependency available in debian or other linux distribution? Do we need to submit it to the upstream or can we include it in our own debian package? A better case is someone who is interested in anon-connection-wizard can test it by doing a
git clone and installing some dependencies available in debian repository.
Link to tor launcher automation irc meeting on 06/02/2017:
https://github.com/Whonix/whonix-setup-wizard/blob/master/usr/lib/python3/dist-packages/whonix_setup_wizard/tor_status.py - just move it to anon-connection-wizard. It won’t be required anymore in whonix-setup-wizard once anon-connection-wizard replaces that functionality.
guimessage - It does have its own package already. https://github.com/Whonix/python-guimessages
True. That would simplify some things. Curenty it has two dependencies not in Debian:
- genmkfile - https://github.com/Whonix/genmkfile
To run anon-connection-wizard on Debian, one has to install these two dependencies first.
guimessages could be removed by figuring out another way to show messages and to provide a mechanism to later get anon-connection-wizard translated.
genmkfile is used for packaging, but could be removed by moving to imo more complicated packaging using the python setup framework. If necessary, do it. It would be a pity. All Whonix packages are currently packages using genmkfile. Changing this would require changes to the build system. I would hope to get genmkfile uploaded to Debian one day.
Perhaps you can find a DD (debian developer) that would be willing to upload these dependencies to Debian? These packages are lintian --pedenatic clean, stable for a long time and Whonix, and generally shouldn’t create a lot work to maintain in Debian, I hope.
(Whenever I say something in public like in Whonix forums you can of course quote me on that.)