[tor-dev] Damian's Status Report - March 2015
Guten tag world! Time again for another status report... Arm Graph Panel Rewrite Really? Has it actually been four months? Dusted off my work from November and finished rewriting arm's graph panel. Besides untangling a mess of code that would make my family disown me, this leverages 'GETINFO bw-event-cache' to greatly improve graph prepopulation. Thanks, Nick, for adding that! Coding aside, real challenge this month has been finding a better name. Thanks everyone who has helped (especially Mike!)... https://lists.torproject.org/pipermail/tor-dev/2015-March/008398.html I'm now strongly leaning toward Nyx. Brevity aside, Nyx is the primordial goddess of the night with a description that's positively delightful... "Her appearances are sparse in surviving mythology, but reveal her as a figure of such exceptional power and beauty, that she is feared by Zeus himself. She is found in the shadows of the world and only ever seen in glimpses." Very curious to hear what the community thinks. New Development Blog Five years now I've dumped my status reports onto a single page. While this worked, clearly it lacked a certain... elegance. Moved to a proper blog... * before: https://www.atagar.com/log.php * after: http://blog.atagar.com/ Personally I found it interesting how my style has evolved over the years. My current approach is to focus on a couple topics, followed by a brief list of additional things I've been up to. This is much easier to skim than the walls of text I once wrote. Few other noteworthy things were... * Stem can now read encrypted hidden service introduction-points. (#15004) * Support for the consensus' new packages field and new HS extrainfo stats. * You can now specify just a single test to run, rather than a whole module. (#14944) * clv expanded our tests to check if tor has capabilities Stem lacks. (#8250) * Sebastian sped up our integ tests by making them use trigger-able events. (#14943) Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] #14995: systemd unit files - review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. thanks, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14 [2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24 https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor%40.service https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor.service -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4 +fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX 76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0 dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7 2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5 Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo qFDT5Y0Fnhezh5DVnRp+ =mtYl -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] maintenance status of atlas or globe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, is globe or atlas actively maintained? Does it make sense to create trac entries? (I just want to avoid doing worthless things.) thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVFqYBAAoJEFv7XvVCELh0u1QQAKSai+lYibASpYdqUFnfka7E APq5zGYnkR1I9KGTR8aL9+Z/dlEzl2fCCztwyfFZPYFudh/qzPtSPDUInLvDE/za 3X25hbCHwyW9Q7jQKAYWYuYWACE1S4F62e6TFzoT20gga1EhldBO+FqL943D7DuV 4FPT6lkWuPtZKF5X3gb0tkS6d48o5NYSp3RhFsowX2Y3SfdoRnTa86QbQ+2k9g7K R2W6f53c6jxwUU8MC4W3Tqc2JykojFbZADvwi8QxJ+4KlxWimG6PDshuJoY+sdsX R0n5o0L986uAn9CA5K5s/ANLkl9cYgt/oxptsY4HWSFKAh6xjdQBSYt5qjXI+KxL d1PDPdGXjolePsjUv/md+hnoRVjo4FCjx+5aQw23QhGaCi9Np0E87rF2xuUNmszs y9F/niXvNJMp1OIhVDeTinLm18lkOVCoGz/UkHdbiBj5md/5GTfql3zp2Nssku30 O+hUOEuvTJ0mousMglFeWRiO2UiliU55qTEbIUV5o4YVCK4uWA11v06so6dI4FNh bRwqUTsnzU/PqLdvgDUP3fiZXizVoxQB+KMzwnmroV+QmL+cnAR7ac8hU/PfPH/F nC/lONV5ZiXnmBZXvHTnIUBeHRwtQi48rDWtNLnSQmRN3i8jwP1NiUmuyKXZgA2a 6+cGVMKBA+Xy2sBciw9y =2YsQ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Browser 4.5a5 will change circuit expiry to 2hrs
On 3/28/2015 4:34 AM, A. Johnson wrote: >>> Would you still set a max lifetime for a circuit to accept new streams of 2 >>> hours, or would the circuit potentially persist forever? >> >> Nick set a max lifetime in his updated version of the patch that also >> deals with non-Tor Browser activity, but I am not convinced that a max >> is a great idea yet. He also randomized the per-circuit max from >> [0,max], which seemed not great for usability. > > Regardless of whether you use a maximum, I think it is an obvious improvement > to randomize the “typical” circuit switch time (use a new randomly-selected > time with each new circuit). A deterministic time makes it possible to > predict when a client should switch circuits and thereby facilitates > tracking. This is a recommendation from Hutha and Danezis’s “Linking Tor > Circuits” (Sec. 5.3) [0]. > Indeed, that is a paper I have marked as interesting and more interesting is Paul Syverson's mitigation solution: https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html This should be implemented everywhere, not just in Tor Browser. So far we didn't research how much additional load such a change will put on the network. >>> In fact, I think it would be great for TorBrowser to treat each >>> tab/window as a separate identity and send *all* streams in a >>> given tab/window over the same path (i.e. sequence of relays). >> >> The 4.5 series of Tor Browser actually already does a form of this, but >> instead of per tab, we do per URL bar domain. If you have two tabs open >> to Facebook, all of those content elements will use the same circuit, >> but Facebook like buttons on cnn.com will use the cnn.com circuit. > >> In addition to being a more sane way of handling web browsing, it also >> enables a very simple circuit status UI. The Torbutton menu now tells >> you the current circuit for the site in the URL bar in a compact display >> that is no larger than the dropdown menu itself. > > Interesting - I did not know this! An adversarial destinations could still > observe new circuits by including resources from other domains that he > controls, which would be prevented by per-tab circuits, but this does seem > like very good feature. > > Cheers, > Aaron per-tab circuits would help in other aspects too. Take for example the providers who offer multiple different services (hosted on their subdomains) for the same user account. Simple example, google: fist you have to login on accounts.google.com, you are then redirected to mail.google.com and you can also access drive.google.com. maps, calendar, etc. At this moment TBB 4.5a4 will use different circuits for each, regardless all pages are opened in the same tab. At current moment it works, you are not logged out but some providers to kill the session if the IP address changes during the session. Of course such circuits can also be linked. What if all pages opened in a tab would use the same circuit, and if other new links will be opened in a new tab but request came from a previously opened tab (Open link in new tab clicked by client or target="_blank" on link source or other way to open links from a page in a new browser tab) would use the same circuit as the initial tab, where the request came from? This could be useful. > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo-announces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/03/15 00:20, Nusenu wrote: > Hi Karsten, Hi Nusenu, > the latest onionoo update 2.3 triggered a bug in my onionoo > "client" (charset encoding). Even though it is a bug on my side, > would you mind announcing future releases/deployments on > onionoo-announce [1] including a short changelog? Oh, I didn't expect the 2.3 update to break anything. The change to 2.3 was just that we added optional "flags" field to uptime documents on March 22, 2015. The charset encoding things were bugfixes which still happened as part of 2.2.1 (which numbers being major protocol version, minor protocol version, and implementation version). I had no idea these fixes would break clients. Oops. In theory, only a major protocol update would break clients. That's why there's the "next_major_version_scheduled" field that gives you hints about upcoming changes, and that's what onionoo-announce@ is for. I'm not sure if it's a good idea to announce implementation changes there, mostly because there are so many of them. One thing I have been thinking about: should I move announcements to the tor-dev@ mailing list, rather than having the special-purpose mailing list onionoo-announce@? It's only been four messages in the past six monts, and maybe more people would notice. (I noticed when arguing against a special-purpose tor-bridges@ mailing list, because we already have tor-relays@.) By the way, I should indeed start a changelog for implementation changes. There's already the protocol version log on the protocol page (https://onionoo.torproject.org/protocol.html#general), but I should also put a more detailed log into the source repository. Thanks for the feedback! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVFlTwAAoJEJD5dJfVqbCrjQAH/1Hw3il3J2lJB4js4EgeLZi/ BevLLCgcrsDnylfYBvs7kyBh2affmtp98EfOEhDmJpjXMIDgHH2t1243/lqtHg1a HWFSIptwMZPWh5ExFAppoEefiN5hKL/V8O+ImlpiTsJuf8ZQTwpNNtnv434Pd98N FQDSnf5yOqZDPWwlSiI4ppLEmOsQUDkz7n1Rb3R8LTw2HmiQHy9hbPmOS7Tqc4b/ 64x6gh64+2YnVESWuWSpVYlyXhbYYnCfUmea3e0MRwShblO3U4rZWDQ1ACbvivAG Gu8FXLouDVUjg9yWeenVR/WS56d6jQeu13thvvLwaZCCnfyrlLzAdydUb7VTYOI= =wP/6 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Measurement of the amount of discrimination by website operators on Tor users?
On Fri, Mar 27, 2015 at 3:07 PM, Rishab Nithyanand wrote: > https://blog.torproject.org/blog/call-arms-helping-internet-services-accept-anonymous-users > >Step one is to enumerate the set of ... services that handle Tor connections >differently > > I think it's an important step to help make more informed decisions about > how the usability of Tor can be improved (by reducing discrimination). I've > got a measurement platform in place, some ideas of how I'd like the study to > be done, and an awesome mentor to help me with it. But I'd like to know if > it's already been accomplished by someone else before investing time into > it. Afaik no formal work, only some early framing and manual collection exists, most of which is linked within that blog post and its wiki pages therein. Feel free to float your ideas here as a means to further develop / doc that framing and go for it. Tor-talk might also be able to provide input / volunteers, particularly about how services handle tor differently during actual use, such as how user accounts are treated. (Any scanner can detect frontpage blockage, which is useful project info itself.) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
