Re: [tor-dev] Apple App Store Redux
On Sat, Nov 16, 2013 at 3:58 PM, Erinn Clark wrote: > ... > I tried to get the licensing agreements earlier this year and they are, as far > as I can tell, not available until you actually sign up. If someone reading > this has put something in the app store (which may or may not be different > from > the app store the iPhone uses? does anyone know?) please send us a copy of any > agreements you may have! checked #6540 and did not see any docs. attached mac_program_agreement_20130610.pdf and ios_program_standard_agreement_20130610.pdf to https://trac.torproject.org/projects/tor/attachment/ticket/6540/ best regards, ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] InjectSOCKS: 2nd try
Hi! On 06 Dec (18:59:33), t...@herr-der-mails.de wrote: > Hello, > > I've first sent this e-mail to h...@rt.torproject.org and the answer > was to send a copy of it to the "tor-dev mailing list". So that's > what I do: > > I just wanted to let you know that I've created a small new tool for > Windows called InjectSOCKS that can force other Windows software to > do TCP connections via SOCKS. This way software not supporting SOCKS > can be used together with Tor. You don't need any additional HTTP > proxy or other proxies. As an example it works for passive FTP, too. > Additionally it handles the DNS requests of that other software in a > way that while creating the SOCKS connection, Tor gets the textual > address - so the exit node can resolve it (which is the way favored > by the Tor developers). This way Tor hidden services work as well. > And it works per Windows process, so it doesn't influence the whole > operating system. This is really great. I didn't look at the code but getting Windows support in torsocks would be awesome! Not sure yet how much work it would require but definitely having it would be amazing. > In case you're interested in my software, I've put it on sourceforge > to make it open source: > http://sourceforge.net/projects/injectsocks > The tool is far from being perfect yet, but I think some of the ideas > are interesting. Do you think you can put your code into a git repository (github, gitourious, ...). That would be *very* helpful to review/contribute and track changes. Thanks! David > > By the way, I've also created DNS2SOCKS, which is already listed on > Tor's Wiki: > http://sourceforge.net/projects/dns2socks > It seems like several people like it, so I hope that some people > will also like InjectSOCKS. > > Regards, > ghostmaker > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-reports] Damian's Status Report - November 2013
> Well, what do you suggest? Add to metrics-tasks or not? Personally I don't think it would be worthwhile, but if you'd like to then the script is on the ticket. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Statistics on fraction of connections used uni-/bidirectionally
Björn, Florian, a few years back (in 2010, to be precise) we added statistics to little-t-tor reporting what fraction of connections is used uni-/bidirectionally. Quoting dir-spec.txt: "conn-bi-direct" -MM-DD HH:MM:SS (NSEC s) BELOW,READ,WRITE,BOTH NL [At most once] Number of connections, split into 10-second intervals, that are used uni-directionally or bi-directionally as observed in the NSEC seconds (usually 86400 seconds) before -MM-DD HH:MM:SS. Every 10 seconds, we determine for every connection whether we read and wrote less than a threshold of 20 KiB (BELOW), read at least 10 times more than we wrote (READ), wrote at least 10 times more than we read (WRITE), or read and wrote more than the threshold, but not 10 times more in either direction (BOTH). After classifying a connection, read and write counters are reset for the next 10-second interval. These statistics are disabled by default, but when they are enabled, relays publish them in their extra-info descriptors. And quite a few relays do that. Here's a (bad) visualization (that used to be slightly less bad when fewer relays published these statistics): https://metrics.torproject.org/performance.html#connbidirect Here's the question: Is there still value in having these statistics? I recall that they were useful in 2010, but will that still be the case in 2013? If the answer is "yes", never mind. If the answer is "no", I'd create a ticket and submit a patch to remove code parts from little-t-tor, and I'd remove the not-really-useful graph from the metrics website. Cc'ing Rob, Aaron, and Roger as the people who typically have an interest in these kinds of statistics. If other tor-dev@ people have an opinion on this, please raise your voice! All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-reports] Damian's Status Report - November 2013
On 12/9/13 5:45 PM, Damian Johnson wrote: >> Hi Damian, >> >> do you want to add the code produced for this analysis to >> metrics-tasks.git? This could happen now or when all analysis for this >> ticket is done. I'm aware that it may take a bit of time to clean up >> code (though I haven't looked at your code). But the advantage is that >> people who're planning to do a similar analysis can `git grep foo` >> metrics-tasks.git and find your code. If the code is only on a Trac >> ticket, it's very likely lost once the ticket is closed. >> >> https://gitweb.torproject.org/metrics-tasks.git/blob/HEAD:/README > > You're certainly welcome to. My conclusion from writing it was > actually that Stem needs some helper methods to better handle the > prefixed 'private' exit policy... > > https://trac.torproject.org/projects/tor/ticket/10107 > > If we had that then the script would have been pretty trivial. Well, what do you suggest? Add to metrics-tasks or not? If you think we should add something, would you mind sending me a metrics-tasks patch, or a link to your metrics-tasks branch? I wouldn't know what files to add and how to describe it accurately in a short README file. Thanks! All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-reports] Damian's Status Report - November 2013
> Hi Damian, > > do you want to add the code produced for this analysis to > metrics-tasks.git? This could happen now or when all analysis for this > ticket is done. I'm aware that it may take a bit of time to clean up > code (though I haven't looked at your code). But the advantage is that > people who're planning to do a similar analysis can `git grep foo` > metrics-tasks.git and find your code. If the code is only on a Trac > ticket, it's very likely lost once the ticket is closed. > > https://gitweb.torproject.org/metrics-tasks.git/blob/HEAD:/README You're certainly welcome to. My conclusion from writing it was actually that Stem needs some helper methods to better handle the prefixed 'private' exit policy... https://trac.torproject.org/projects/tor/ticket/10107 If we had that then the script would have been pretty trivial. Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
Hi Nicolas, some remarks are below. Nicolas Vigier: > In order to help me doing that, I'm very interested to receive from > developers of any tor components : > > - a description or ticket number of bugs that you wish could have been > detected earlier with automated tests https://trac.torproject.org/projects/tor/ticket/8143 comes to mind here. > - any wish or specific needs that you may have You write: "Tor Browser includes some patches to make the build reproducible. We could have a test that check the reproducibility of the build by building the browser twice." While this is indeed a good idea, it won't be enough as we had bugs in the past that were only visible when builds on different machines got compared. So, what I'd like to have (in addition to running browser builds twice? on different machines?) are tests that cover specific bugs we avoided (see: the "Remaining Build Reproducibility Issues" in Mike's blog post covering the technical details of the Gitian build) or tracked down. See: https://trac.torproject.org/projects/tor/ticket/10159 for an example for the latter. (There, one could write a test that automates the creation of the browser.manifest which would eventually (i.e. if run a couple of times) show whether this bug still exists or whether not).) > - anything else that you think might be useful for me to know You write: "We can produce some packages for Tor Browser, to make testing of the browser easier." In which regard is it easier to test the browser if you have packages? And how should that look like outside of the Tor Browser Bundle? I fear we create extra bugs if we move the browser outside the environment it will be used in (i.e. the TBB) just for testing purposes. Even if we won't create extra bugs this way we might miss some. To be clear, running the tests you call "Usablility tests" and "Reproducible build test" outside the bundle, seems fine to me, while my concerns apply to the fingerprinting and privacy tests. The test helpers are a good idea. You might want to rename "Cookies tool" to something like "Identifier tool" matching the Tor Browser specification more closely (especially as you actually mean "Identifier tool" as "Later versions could be extended to also use other techniques for storing informations in the browser" indicates). Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
